Letting crashpad handle the exception BUT additionally report it to windows reliability monitor / eventlog

[JanFellner]

We recently switched to sentry and are pretty happy about it.
One thing which currently is a but ugly, especially for the customer side: They are no longer aware about abnormal program terminations.
When checking for issue you start to dig in the windows reliability monitor (perfmon /rel)
This is gathering its information from the windows eventlog.

It looks like there is no builtin way to let the crasphad handler report issues to the windows eventlog or am i missing something?

Asking ChatGPT it tells me to implement custom handling for it but i wonder as this "Getting an event in windows eventlog" should be something everybody needs 🤔?

[supervacuus]

Hi @JanFellner.

We recently switched to sentry and are pretty happy about it.

Glad to hear!

One thing which currently is a but ugly, especially for the customer side: They are no longer aware about abnormal program terminations.
When checking for issue you start to dig in the windows reliability monitor (perfmon /rel)
This is gathering its information from the windows eventlog.

Yeah, that is a side-effect of how breakpad and crashpad operate. On Windows, crashpad uses the UnhandledExceptionFilter to register crashes in the client, but then defers the actual snapshot to the crashpad_handler, which terminates the application after generating the minidump.

This prevents the UEF from returning EXCEPTION_CONTINUE_SEARCH, allowing WerFault.exe to produce a crash report for an unhandled SEH exception (which would lead to the entry you want your customers to see).

This is also not an accident, but rather a deliberate choice. The two snapshotting mechanisms aren't easy to synchronize and potentially could leave the application in a state that prevents the other snapshotting mechanism from succeeding.

However, I see how this could be a problem, since the system owner is almost always different from the application developer and will also not have access to their logs, leaving the system owner without diagnostic feedback regarding application health.

It looks like there is no builtin way to let the crasphad handler report issues to the windows eventlog or am i missing something?

No, Google did not address this topic on Windows.

Asking ChatGPT it tells me to implement custom handling for it

The right approach is not writing something into the event log, but submitting a critical report to the WER queue. You could, for instance, do this inside the on_crash hook using not much more than WerReportCreate, WerReportSubmit, and WerReportCloseHandle.

but i wonder as this "Getting an event in windows eventlog" should be something everybody needs 🤔?

You are the first to have brought this to our attention. I suppose most application developers are not as close to system administrators as in your scenario (i.e., they rarely receive feedback that problem reports are missing or similar issues from a system management perspective, and if they do, they are likely to be really close to ops, i.e., in the same team, where they can share sentry reports).

This would be a feature that makes sense to provide out of the box. There is even an option sentry_options_set_system_crash_reporter_enabled, which could be used for this, but the crashpad parameter we set with this is currently ignored on Windows (and primarily used on macOS, where the entire handling chain is very different and running the OS reporter after the crashpad one is less of a problem).

I can explore how to integrate this generically into our handler flow.

[supervacuus]

I have created a corresponding issue. Let's continue the conversation there (#1296).

[JanFellner]

Yeah would absolutely make sense to me to let sentry native would offer an option to bubble such an issue also to the WER que.
In the end we have basically three different modes sentry native based our applications are running in:

• Windows Desktop client (Where the user very likely is not interested in any details, we collect those and fix them)
• Windows server side (Service based) Very likely responsible persons want to be aware about abnormalities
• Hosted as Windows docker in a K8S cluster. It should never crash 😂 and in case it does no one would look into any windows based logs, container is recycled anyway.

This wide range of modes and options leads to the amount questions/discussions i am starting here (and to the amount of beer i owe you) :)

Let´s followup that topic in the ticket.