Consider experimenting with WerRegisterRuntimeExceptionModule
Project Member Reported by email@example.com, Sep 23 2016
Ref: https://msdn.microsoft.com/en-us/library/windows/desktop/dd408167(v=vs.85).aspx It's Win7+, but that's almost OK these days (or perhaps it could be optional if we want to maintain <= Vista for a while longer). It would seem to allow us to do fully out-of-process exception handling, other than the initial registration. I don't know if there's any gotchas or limitations without doing some playing around though.
Sep 26 2016,
We should definitely investigate to see if we can make this work for us. Fully out-of-process would be great!
Nov 7 2016,
An internal user reported "no captured crashes" which turned out to be due to calling abort(). In Debug this works OK because it first does some stuff, and then int 3's. In Release however, if there's no SIGABRT handler, it uses __fastfail() which doesn't invoke exception handlers, so we don't see it. See also https://bugs.chromium.org/p/crashpad/issues/detail?id=57 .
Nov 23 2016,
As it seems most people are awol, likely gearing up for turkey and consumerism, I tried fiddling with this a bit today. Discoveries from a Win10 machine follow. Despite documentation semi-implying otherwise, the dll must be registered in HKLM. The key name specified in the documentation is incorrect (at least for Win10) so it's not overly surprising, I guess. If the correct registry key is not present, WerRegisterRuntimeExceptionModule() still returns S_OK. This is understandable, but makes it difficult to implement fallback behaviour, or report an error to the client code. When the DLL is registered properly, it's still the "port of last call", in the sense that the in-process signal handlers and UnhandledExceptionFilter() get first crack at exceptions, and the out-of-process one won't get any notification if it gets handled elsewhere. So we'd have to be very confident in our registry setup, or use this approach only as a fallback. But, the most aggravating thing is that __fastfail()s still go directly to the system reporter, and don't use the registered dll. Capturing these was the main reason I'd want to use this API. I have no idea what the rationale is for this, but it seems totally broken. RaiseFailFastException() does go through the WER DLL, but __fastfail() goes straight to the system. And since the CRT and other things call __fastfail(), it seems of very minor benefit to try to get everything set up for this API. Overall, disappointing.
Nov 23 2016,
(I put my hack code here https://chromium-review.googlesource.com/c/414432/ for reference.)
Jun 27 2017,
Oct 19 2017,
On Thu, Oct 12, 2017 at 8:59 PM Will Harris <firstname.lastname@example.org> wrote: OOM in Windows sandbox due to job object restrictions being exceeded (I.e. code 7012) never result in crash reports. This is because the OS terminates the process, and we get no chance to capture a crash. Perhaps that is what is happening here?
I would like to subscribe to your bug. I am working on https://chromium-review.googlesource.com/c/chromium/src/+/1129628 and noted difference in behavior between __fastfail and RaiseFailFastException. in particular when I do a __fastfail with an exception code, the code seems to be ignored and it always raises C0000005 - maybe this is an issue with clang's implemention of __fastfail?
__fastfail mapping to C0000005 sounds concerning, what is the corresponding machine code?
I ran more testing, wasn't able to get the C0000005 from my little test program, but was definitely seeing it in Chrome. I need to do more testing here. https://chromium-review.googlesource.com/c/chromium/src/+/1144411 if you want to test this stuff.
Sign in to add a comment