Invalid Handle exception 0xC0000008 with 4.2.2 #12329
Comments
|
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....... |
|
With a new instance of qBittorrent running have had a hit again with also now a break instruction exception encountered too. |
|
@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. |
Does it matter? Just curious. |
no, just curious myself... |
|
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 @sledgehammer999 is it possible that this is a |
Yes! It should be reported to boost asio or libtorrent. There is nothing qbt can do. |
|
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. |
|
Opened an issue now with asio #473 |
|
Anyone know how I can go about what to do from below comment? I'm still experiencing this issue with
chriskohlhoff/asio#473 (comment) |
|
I may have found a cause for this issue - testing ongoing & will report back with my results. |
|
@xavier2k6 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? |
application verifier only brought the issue to the forefront along with the use of debug diag. 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.... |
|
@milgradesec since you experienced this too, anything you could add to this would be very much appreciated, testing/findings etc etc |
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
But only the implementer of 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. |
|
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..... |
xavier2k6
changed the title
|
It seems and invalid handle to a socket is given to WinSock select(), maybe some socket is closed and its handle still kept |
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? |
|
This seems to suggest; "yes, the exception causes the process to terminate" |
|
@xavier2k6 What's the status on this one? Can you still reproduce with 4.3.0.1? |
It was still happening with |
|
It's still there with 4.3.0.1/Boost 1.74, anything we can do about suggestion from chriskohlhoff/asio#473 (comment)? |
|
@xavier2k6 ping, still reproducible in latest master + latest RC_1_2 + boost 1.75? |
I haven't the time currently to build/test... EDIT: #13203 is basically a dupe of this. |
|
Got around to testing this with 4.3.3 & it still happens! |
|
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 |
|
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; |
|
@rugabunda thanks for the suggestion.......will re-test/look in to this when free-time permits. |
|
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 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? |
|
@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 The
This also seems to suggest it's still crashing & user has provided The only thing that I can find in said (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
I carried out these steps on You may need to run a virus/malware scan. Can you provide more details about version of |
|
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. |
|
@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: chriskohlhoff/asio@4b37bdb It 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). |
|
@xavier2k6 can you weigh-in here when you get a chance? |
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 https://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 |
|
Looks like Qt are also using 2.0 for winsock initialization/startup in certain places. |
Changes have been made/merged upstream & Winsock will be initialized with 2.2 as of Qt 6.9 |
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.
The text was updated successfully, but these errors were encountered: