New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 133 link

Starred by 7 users

Issue metadata

Status: Assigned
vslow; not on Chrome

Sign in to add a comment

Consider experimenting with WerRegisterRuntimeExceptionModule

Project Member Reported by, Sep 23 2016

Issue description


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.
Project Member

Comment 1 by, Sep 26 2016

We should definitely investigate to see if we can make this work for us. Fully out-of-process would be great!
Project Member

Comment 2 by, 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 .
Project Member

Comment 3 by, 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.
Project Member

Comment 4 by, Nov 23 2016

(I put my hack code here for reference.)
Project Member

Comment 5 by, Jun 27 2017

Project Member

Comment 6 by, Oct 19 2017

On Thu, Oct 12, 2017 at 8:59 PM Will Harris <> 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

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?
Project Member

Comment 8 by, Jul 23

__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. if you want to test this stuff.

Sign in to add a comment