#[Native SDK] Ensuring that on-crash is always called

4 messages · Page 1 of 1 (latest)

atomic canopy
#

Hi!

I'm trying to use Sentry to produce a log file each time a crash happens in my application, which runs in Windows 11 and uses C++. For this purpose I'm using the on-crash callback, which works perfectly for most errors (unhandled C++ exceptions, SEH exceptions, etc). I have tried to make my app crash with many different errors, and the only ones that can bypass the callback are signals (SIGFPE, SIGILL, etc, although instructions that supposedly raise them like __ud2() are actually handled OK) and fast fail errors.

I have seen in Sentry's documentation, that fast fail errors not being handled on Windows is a known issue, and I guess that I could handle signals by subscribing signal handlers after calling sentry_init() (though I have not tested it), but I would like to ask for guidance about a possible workaround for handling the fast fail errors. I know that Sentry generates reports for them, but it does not call on-crash, so I cannot get the execution logs if such an error happens. Maybe I could build Crashpad so that it can read the logs from shared memory, or subscribe a WER module to do something? I don't know what to do about it.

Also, I have considered using Breakpad or inproc instead, but since they are in-process handlers they cannot serve for my use case, as I want to cover as many errors as possible, right?

Thanks in advance!

image.png
vast sage
#

have tried to make my app crash with many different errors, and the only ones that can bypass the callback are signals (SIGFPE, SIGILL, etc, although instructions that supposedly raise them like __ud2() are actually handled OK)

The Windows kernel doesn't emit any signals on hard faults. So, if you execute a ud2 or create a floating-point error (or any other CPU-fault) then Window will create a SEH exception. The only signal-handler installed on Windows is the SIGABRT handler, since that is the most sensible handler mechanism for tracking abort() on Windows.

Also, I have considered using Breakpad or inproc instead, but since they are in-process handlers they cannot serve for my use case, as I want to cover as many errors as possible, right?

It really depends on what kind of errors you actually expect. But both of these backends will not track fastfail crashes, since those can only be recovered from a WER module. So, there is no real upside to using them if crashpad and its separate executable doesn't lead to any deployment issues.

fastfail crashes are typically used when security is a concern (for instance when you run your code with the CFG enabled and it detects meddling with indirect call targets) and any extension of the runtime of your application increases the attack surface, this is why they bypass any handlers inside the application because they are a security risk.

Maybe I could build Crashpad so that it can read the logs from shared memory, or subscribe a WER module to do something? I don't know what to do about it.

If you are willing to modify and maintain the the crashpad source and you absolutely must collect the logs for fastfail crashes then the right place would be in the crashpad WER module, where you can repeat the collection process of your on_crash routine. However, supporting you in your implementation goes beyond what Sentry can offer.

atomic canopy
#

I see. Still, if I could modify Crashpad's WER module, would I be able to use my Crashpad build with Sentry?

vast sage
#

I see. Still, if I could modify Crashpad's WER module, would I be able to use my Crashpad build with Sentry?
Absolutely. Since the entire SDK is open-source you are free to modify to your needs. However, Sentry can only provide support for what is officially released so if something doesn't work because of your modifications, you are on your own.