mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Windows: Invalid Handle exception 0xC0000008 with 4.2.2 #10015
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#10015
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @xavier2k6 on GitHub (Mar 29, 2020).
Please provide the following information
qBittorrent version and Operating System
qBittorrent 4.2.2 (Official) - Windows 10 Pro x64 Version 1909 Build 18363.752
10.0.18363
If on linux, libtorrent-rasterbar and Qt version
N/A
What is the problem
Unhandled exception 0xC0000008
What is the expected behavior
Not to have a Unhandled exception 0xC0000008
Steps to reproduce
EDIT: Enable Handle Checking in Application Verifier
Just started up the program & was waiting for it to fully load up for a few minutes.
All torrents were in paused state before opening the program - so no download/uploading/seeding/checking etc.
See partial stacktrace below - boost asio problem?!
Extra info(if any)
It did not crash per se, in fact the same instance of qBittorrent is currently running, have debugdiag attached as always & have added 0xC0000008 to my rules now for hopefully a full stacktrace if it happens again.
@xavier2k6 commented on GitHub (Mar 31, 2020):
Kept logging them throughout the night while having about 5 torrents active, Have stopped qBittorrent running now & going to restart to see if it happens again.......
@xavier2k6 commented on GitHub (Mar 31, 2020):
With a new instance of qBittorrent running have had a hit again with also now a break instruction exception encountered too.
@xavier2k6 commented on GitHub (Mar 31, 2020):
@sledgehammer999 thoughts? BTW do you use latest b2 when compiling or the one that comes with the boost 1.xx source? just as a matter of interest.
@FranciscoPombal commented on GitHub (Mar 31, 2020):
Does it matter? Just curious.
@xavier2k6 commented on GitHub (Mar 31, 2020):
no, just curious myself...
@xavier2k6 commented on GitHub (Apr 2, 2020):
This exception is still happening on 4.2.3 (haven't checked earlier versions than 4.2.2 [when first attached], so this exception could always have been there or it may very well be expected too.)
Only noticed this exception when I attached
microsofts application verifierto my debugger that's attached to qBittorrent.@sledgehammer999 is it possible that this is a
thread safeissue or something else entirely?@Chocobo1 commented on GitHub (Apr 3, 2020):
Yes! It should be reported to boost asio or libtorrent. There is nothing qbt can do.
@xavier2k6 commented on GitHub (Apr 3, 2020):
@Chocobo1 thanks, boost 1.73 should be out next week so (it won't be fixed by then as code freeze) will wait & see if that has any effect.....unsure if there's any changes to
asio(must look through notes).@arvidn any thoughts?
@arvidn commented on GitHub (Apr 3, 2020):
I think it's might be reasonable to file a ticket with asio for this.
Also, not all structured exceptions are fatal, or even a problem (as long as they are handled near where they were thrown). Does this structured exception actually cause termination of the program or the thread? or some other ill-effect? It's not obvious that just the fact that a structured exception is raised is a problem in and of itself, only if it leaks into libtorrent or qbt, causing threads or the process to shut down.
@xavier2k6 commented on GitHub (Apr 4, 2020):
Opened an issue now with asio #473
@xavier2k6 commented on GitHub (Apr 30, 2020):
Anyone know how I can go about what to do from below comment?
I'm still experiencing this issue with
Boost 1.73which now usesasio 1.16.1https://github.com/chriskohlhoff/asio/issues/473#issuecomment-609100793
socket_ops.ipp#L1798
select_reactor.ipp#L238
select_reactor.ipp#L285
win_thread.ipp#L127
@xavier2k6 commented on GitHub (May 5, 2020):
I may have found a cause for this issue - testing ongoing & will report back with my results.
@arvidn commented on GitHub (May 5, 2020):
@xavier2k6
if this only happens when attaching application verifier, is there any reason to believe this is an actual problem?
my recollection (but I haven't used application verifier in almost 10 years now) is that there are a lot of structured exceptions (not C++ exceptions) happening internally when using various win32 facilities, but they are always caught and doesn't leak to the user.
If you catch one of these in application verifier, do you have a reason to believe it's not handled by anyone?
If you don't set your debugger to stop on SEH, do you still see a problem?
@xavier2k6 commented on GitHub (May 6, 2020):
application verifier only brought the issue to the forefront along with the use of debug diag.
I believe now that the issue is possibly related to the way the GeoIP database file is loaded/handled
(Unfortunatley, there now seems to be issues with downloading of the database - so I can't confirm/continue my testing)
I don't believe this was an issue prior to qBittorrent 4.2.2 as my testing couldn't reproduce it (prior to 4.2.2 - qBittorrent was using a different GeoIP database)
That may be so.....
It's not caught by application verifier per se but with the debugger tool debug diag - I haven't been able to confirm if now only debug diag catches it on it's own.
I haven't set it to stop & it continues but it can reach 162 instances of this error, that to me is excessive even if it is expected.
I haven't seen anything that says "ok, this is expected & can be ignored" etc
It could very well be a false positive so to speak or it could very well be a genuine issue & until there's a definitive answer then obviously the issue will have to remain open & further testing/debugging will be ongoing....
@xavier2k6 commented on GitHub (May 6, 2020):
@milgradesec since you experienced this too, anything you could add to this would be very much appreciated, testing/findings etc etc
@arvidn commented on GitHub (May 6, 2020):
I don't think it's reasonable to make assumptions about what a "normal" number of structured exceptions will be raised during a program. This is an implementation detail (until the exception leaks out of
select()), does it?But only the implementer of
select()could tell you that, more importantly, if this exception doesn't leak out of the call toselect(), it does not matter. The fact that a structured exception is raised isn't a problem in and of itself. No more so than some functions returning non-zero sometimes.I haven't seen anything in this ticket explaining what the actual problem is, other than a structure exception happens. Although, it does say "Unhandled exception" in a few places. Is it unhandled? If you continue the process after this happens, does it terminate?
If so, that would definitely be a problem; qBT crashing.
@xavier2k6 commented on GitHub (May 8, 2020):
I set the application verifier to stop in conjunction with my debugger & received a C0000008 followed by a C0000421 & qBittorrent crashed/created a minidump..
All along it was set to continue.......
@arvidn I may be wrong in my terminology of C0000008 being an unhandled exception since it's more of an invalid handle
I'll be honest with you - this is above my pay grade as the saying goes.....
Can you explain? (If you have the time, thanks)
@milgradesec commented on GitHub (May 9, 2020):
It seems and invalid handle to a socket is given to WinSock select(), maybe some socket is closed and its handle still kept
@arvidn commented on GitHub (May 9, 2020):
I just mean that (at least in my experience); the debugger detecting that a SEH is raised is not necessarily a sign of a problem, because those are raised as part of normal operations. Only if a structured exception actually causes the program to terminate/crash is it a problem.
I might be wrong here, but from your description it sounds like you found this only in the debugger. But, again, I'm not sure.
When you run qBT without a debugger, does it crash?
@arvidn commented on GitHub (May 9, 2020):
This seems to suggest; "yes, the exception causes the process to terminate"
@FranciscoPombal commented on GitHub (Oct 22, 2020):
@xavier2k6 What's the status on this one? Can you still reproduce with 4.3.0.1?
@xavier2k6 commented on GitHub (Oct 22, 2020):
It was still happening with
master- however, I've updated to20H2& theappverifierwon't actually open......will have to test on another machine when I get a chance.@xavier2k6 commented on GitHub (Nov 21, 2020):
It's still there with 4.3.0.1/Boost 1.74, anything we can do about suggestion from https://github.com/chriskohlhoff/asio/issues/473#issuecomment-609100793?
@FranciscoPombal commented on GitHub (Dec 18, 2020):
@xavier2k6 ping, still reproducible in latest master + latest RC_1_2 + boost 1.75?
@xavier2k6 commented on GitHub (Dec 18, 2020):
I haven't the time currently to build/test...
EDIT: #13203 is basically a dupe of this.
@xavier2k6 commented on GitHub (Mar 3, 2021):
Got around to testing this with 4.3.3 & it still happens!
@xavier2k6 commented on GitHub (Mar 3, 2021):
To maybe shed some light on this issue - checking the logs for around that time (I had run out of space)
I was torrenting normally but I was also force rechecking torrents.....
EDIT: pre-allocate disk space for all files enabled
@rugabunda commented on GitHub (Apr 16, 2022):
Exception is still occurring in v4.4.2; if you cant use appverifier, it can be simply tested by enabling "validate handle usage" for qbittorrent.exe in windows exploit protection settings. It happens far more frequently if you have many torrents in seeding mode. The exception used to cause qbit to crash every so many hours, now happens for me within 20-30 seconds after force enabling more seeds. This is without re-checking files and all torrents already downloaded. Looks like it has to do with sending invalid handles to winsock;
@xavier2k6 commented on GitHub (Apr 17, 2022):
@rugabunda thanks for the suggestion.......will re-test/look in to this when free-time permits.
@arvidn commented on GitHub (Apr 17, 2022):
I think there's a fundamental issue with this ticket. It's failing to communicate what the problem is. The original report says the expected behavior is to not have an unhandled exception. But none of the evidence presented suggests that there is an unhandled exception. Only that there is and exception, inside
select(), which presumably is handled byselect()and turned into aWSAENOSOCKerror.It seem the premise is that when enabling a debugging feature that stops on all windows exceptions (SEH), the program should never break into the debugger. I don't think that's a reasonable expectation, and I haven't heard an argument why that would be a reasonable expectation.
Does anyone not enabling these debug functions have a problem with this?
@xavier2k6 commented on GitHub (Apr 18, 2022):
@arvidn The original issue was discovered when I was trying to figure out why some users were experiencing crashes but there was no stack trace provided as
qbittorrentjust seemed to disappear/CTD. (if I recall correctly)The
invalid handlewould in some cases eventually lead to a crash ref.: https://github.com/qbittorrent/qBittorrent/issues/12329#issuecomment-626124927This also seems to suggest it's still crashing & user has provided
crash dumpsin tickets they opened.The only thing that I can find in said
crash dumpsis the0xC0000008but nothing else to go on in them.(1x of the dumps won't actually download as it keeps getting flagged as a virus! - so this could be where the users problem lies or it could also be that from the dumps it seems they're running the
32-bitversion)I carried out these steps on
masterbuild & so far haven't been able to re-produce0xC0000008??@rugabunda
You may need to run a virus/malware scan.
Can you provide more details about version of
4.4.2you are using? (Qt5orQt6/ libtorrent1.2.15or2.0.5){
Boost 1.78} is being used in4.4.2@UnknownzD commented on GitHub (May 30, 2022):
Sorry, I can still produce the whole issue on Windows Server 2022, running 4.4.3.1 with QT6 & libtorrent 2.X branch.
Please see below image for your reference.
It seems that the crash started very soon once the thread is created, but I am not sure what invalidated handle was being re-used.
In addition, I can confirm that I have following security mitigation / exploit guard in place which resulted in the crash, but I would rather choose not to disable it at the moment.
Set-ProcessMitigation -System -Enable StrictHandle -Force On
Please see if there is any reason why an invalid handle is being re-used by the program once a new thread is created.
@arvidn The above security mitigation setting is to prevent the program re-using the handle that has already be freed or invalidated, which is a correct measurement to reduce the attack surface on Windows.
@arvidn commented on GitHub (May 30, 2022):
@UnknownzD what does that screenshot illustrate?
Are you referring to the internal asio thread for the select interrupter?
there are legitimate reasons for those sockets to become invalid. When they do, they need to be re-created. For example, if the system hibernates, sockets may be closed behind the process' back.
See this commit to asio:
github.com/chriskohlhoff/asio@4b37bdbe3eIt doesn't sound like this happens to you when your system goes to sleep though. Do you have any other hints of what might cause the interrupter socket to be closed? (it's a long-lived socket bound to loopback).
@luzpaz commented on GitHub (Sep 2, 2024):
@xavier2k6 can you weigh-in here when you get a chance?
@xavier2k6 commented on GitHub (Sep 2, 2024):
I haven't used app verifier in a while or looked in to this further, it may or may not have relevance to #17082
I do know though that
asiowhich is apart of Boost & used by libtorrent to initilaize thewinsockwas using a DRAFT version of 2.0 for Boost <=1.84.0, it was changed to 2.2 in Boost 1.85.0 via https://github.com/chriskohlhoff/asio/pull/1436https://www.boost.org/doc/libs/1_84_0/boost/asio/detail/winsock_init.hpp
https://www.boost.org/doc/libs/1_85_0/boost/asio/detail/winsock_init.hpp
@xavier2k6 commented on GitHub (Sep 2, 2024):
#16407 & #16618 are related/duplicate.
@xavier2k6 commented on GitHub (Oct 15, 2024):
Looks like Qt are also using 2.0 for winsock initialization/startup in certain places.
@xavier2k6 commented on GitHub (Dec 10, 2024):
Changes have been made/merged upstream & Winsock will be initialized with 2.2 as of Qt 6.9
@xavier2k6 commented on GitHub (Jun 9, 2025):
Closing.....Will re-test at later stage with latest release.