wip(native): capture WER custom metadata#1760
Conversation
c9a7b1a to
c218239
Compare
Pre-generate the native crash event ID and register it as WER custom metadata so the crash daemon can identify the matching WERInternalMetadata.xml. Store the WER report ID provided by sentry-wer.dll in the shared crash context and add a wer context with the report ID and app-provided WER custom metadata.
c218239 to
b503ec0
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit d5dc747. Configure here.
| Sleep(SENTRY_CRASH_HANDLER_POLL_INTERVAL_MS); | ||
| } | ||
| TerminateProcess(exception_info->hProcess, | ||
| exception_info->exceptionRecord.ExceptionCode); |
There was a problem hiding this comment.
WER module no longer waits for daemon minidump capture
Medium Severity
The WER out-of-process module previously waited for the crash daemon to finish processing (including minidump capture via ReadProcessMemory/MiniDumpWriteDump) and then explicitly called TerminateProcess. That wait loop and TerminateProcess are now removed, so process_wer_exception signals the daemon and returns immediately. Meanwhile, the crash handler in the app process returns EXCEPTION_CONTINUE_SEARCH unconditionally (when WER is enabled), relying entirely on the WER module to notify the daemon. Without the wait, WER can proceed through its callback sequence, finish its report, and terminate the crashed process before the daemon completes minidump capture — resulting in an incomplete or failed minidump.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit d5dc747. Configure here.


App:
Context:
{ "contexts": { "wer": { "type": "wer", "report_id": "...", "metadata": { "foo": "ooo", "bar": "aaa", "baz": "zzz" } } } }Sentry:
