wip(native): capture WER custom metadata by jpnurmi · Pull Request #1760 · getsentry/sentry-native

jpnurmi · 2026-05-27T07:00:55Z

App:

WerRegisterCustomMetadata(L"foo", L"ooo");
WerRegisterCustomMetadata(L"bar", L"aaa");
WerRegisterCustomMetadata(L"baz", L"zzz");

Context:

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

Sentry:

linear-code · 2026-05-27T07:27:32Z

TGDX-58

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.

The crash handler's WER path returned EXCEPTION_CONTINUE_SEARCH without claiming the crash state or signaling the daemon, relying entirely on the sentry-wer DLL callback to do so via WER. On CI runners WER may not always invoke the registered callback, leaving the daemon waiting indefinitely. Fix by having the crash handler always claim the crash state and notify the daemon before returning, and having the sentry-wer DLL write the WER report ID and signal even when the crash handler already claimed the crash.

When the crash handler claims the crash in the WER path and notifies the daemon, it must set exception_pointers to NULL so the daemon uses the already-copied exception record/context from shared memory with ClientPointers=FALSE. Otherwise MiniDumpWriteDump tries to read from the crashed process's address space (ClientPointers=TRUE), but the process is already terminated because the crash handler returned EXCEPTION_CONTINUE_SEARCH without waiting.

…/wer-metadata # Conflicts: # CHANGELOG.md

sentry · 2026-05-29T11:37:36Z

+    }
+
+    sentry_value_t contexts = sentry_value_get_by_key(event, "contexts");
+    if (sentry_value_get_type(contexts) != SENTRY_VALUE_TYPE_OBJECT) {
+        contexts = sentry_value_new_object();
+        sentry_value_set_by_key(event, "contexts", contexts);
+    }
+    sentry_value_set_by_key(contexts, "wer", wer_context);
+    return true;
+}
+#endif


Bug: A race condition causes the daemon to look for WER metadata files before they are created, preventing their capture.
_{Severity: HIGH}

Suggested Fix

The order of operations must be changed. The lookup for WER metadata files should be performed only after the crashing process has returned EXCEPTION_CONTINUE_SEARCH, which allows the WER system time to generate the necessary files. This may require adjusting the inter-process communication logic to signal when the files are ready or moving the lookup to a later stage in the crash processing pipeline.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: src/backends/native/sentry_crash_daemon.c#L2124-L2157 Potential issue: A race condition exists in the Windows Error Reporting (WER) metadata capture logic. The Sentry daemon process calls `sentry__wer_report_lookup` to poll for WER metadata XML files. This occurs while the crashing application is paused, waiting for the daemon to complete its work in `wait_for_daemon_capture`. However, the WER system only generates the required metadata files after the crashing application's exception filter returns `EXCEPTION_CONTINUE_SEARCH`, which happens after the daemon has already finished its polling and timed out. As a result, the lookup for WER metadata will consistently fail, preventing its inclusion in the crash report.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 98a675c. Configure here.}

cursor · 2026-05-29T12:08:07Z

+    sentry_value_t wer_context = sentry__wer_report_lookup(ctx->crash_event_id);
+    if (sentry_value_is_null(wer_context)) {
+        if (sentry__string_empty(ctx->platform.wer_report_id)) {
+            return false;


Unnecessary 5-second blocking for SIGABRT with WER enabled

Medium Severity

When wer_enabled is true but the crash is STATUS_FATAL_APP_EXIT (SIGABRT/abort), the crash handler falls through to the non-WER path which waits for daemon completion via wait_for_daemon_capture. The daemon then calls add_wer_context, which invokes sentry__wer_report_lookup — polling the WER temp directory for up to 5 seconds (20 × 250ms Sleep). Since WER is never invoked for STATUS_FATAL_APP_EXIT, this metadata file will never exist, so the poll always exhausts all retries. This wastes 5 of the 10-second SENTRY_CRASH_HANDLER_WAIT_TIMEOUT_MS budget, leaving only 5 seconds for actual crash processing (minidump writing, event building, transport). On slower machines this could cause the crash handler to time out and the process to terminate before the daemon finishes writing the minidump.

Additional Locations (2)

src/backends/native/sentry_wer_report.c#L443-L454

src/backends/native/sentry_crash_handler.c#L1009-L1024

^{Reviewed by Cursor Bugbot for commit 98a675c. Configure here.}

sentry · 2026-05-29T12:27:34Z

+    }
+
+    // Always attempt to signal the daemon. If the crash handler claimed
+    // the crash first, it already SetEvent'd via sentry__crash_ipc_notify,
+    // but a redundant SetEvent on an auto-reset event is harmless.
+    if (SetEvent(event)) {
+        claimed = TRUE;
    }


Bug: The process_wer_exception callback returns without waiting for the daemon to capture the minidump, creating a race condition where the process may terminate before a crash report is generated.
_{Severity: HIGH}

Suggested Fix

Reintroduce a waiting mechanism in the process_wer_exception function. The function should wait for a signal from the daemon confirming that the minidump has been captured before returning. This could be done by restoring the previous polling loop that checks for the SENTRY_CRASH_STATE_CAPTURED state.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: src/backends/native/sentry_wer.c#L166-L173 Potential issue: In the Windows Error Reporting (WER) integration, the `process_wer_exception` callback function was modified to return immediately after notifying the crash-reporting daemon, removing a loop that previously waited for the daemon to confirm it had captured the minidump. This creates a race condition. If WER proceeds to terminate the crashed process immediately after the callback returns, the daemon may not have had sufficient time to write the minidump, which requires reading from the process's memory. This can result in failed or incomplete crash reports for applications running on systems with WER enabled.

cursor Bot reviewed May 27, 2026

View reviewed changes

Comment thread src/backends/native/sentry_crash_daemon.c

Comment thread src/backends/native/sentry_wer_report.c

jpnurmi force-pushed the jpnurmi/feat/native/wer-metadata branch from c9a7b1a to c218239 Compare May 27, 2026 07:27

jpnurmi changed the title ~~feat(native): capture WER custom metadata~~ wip(native): capture WER custom metadata May 27, 2026

jpnurmi added 6 commits May 27, 2026 16:31

changelog

114597a

review findings

b35e70e

make format

6d17135

re-remove wait-loop

206996e

sentry__value_to_json

b503ec0

jpnurmi force-pushed the jpnurmi/feat/native/wer-metadata branch from c218239 to b503ec0 Compare May 27, 2026 14:36

cursor Bot reviewed May 27, 2026

View reviewed changes

Comment thread src/backends/native/sentry_crash_daemon.c

jpnurmi added 2 commits May 27, 2026 16:53

fix test_native_abort

f92d6e4

fix review finding

d5dc747

cursor Bot reviewed May 27, 2026

View reviewed changes

Comment thread src/backends/native/sentry_wer.c

jpnurmi closed this May 28, 2026

jpnurmi deleted the jpnurmi/feat/native/wer-metadata branch May 28, 2026 06:56

jpnurmi added 4 commits May 29, 2026 08:22

DEBUG

a202369

++

da153d1

wait for daemon capture

cdef063

jpnurmi reopened this May 29, 2026

jpnurmi added 2 commits May 29, 2026 13:14

cleanup

45f6f13

Merge remote-tracking branch 'origin/master' into jpnurmi/feat/native…

fff064a

…/wer-metadata # Conflicts: # CHANGELOG.md

cursor Bot reviewed May 29, 2026

View reviewed changes

Comment thread src/backends/native/sentry_crash_daemon.c Outdated

cursor Bot reviewed May 29, 2026

View reviewed changes

Comment thread src/backends/native/sentry_crash_daemon.c

round-trip

3eba170

sentry Bot reviewed May 29, 2026

View reviewed changes

cursor Bot reviewed May 29, 2026

View reviewed changes

Comment thread src/backends/native/sentry_wer.c

Comment thread src/backends/native/sentry_wer_report.c

partial revert

98a675c

cursor Bot reviewed May 29, 2026

View reviewed changes

jpnurmi added 2 commits May 29, 2026 14:19

integration test

7c471ee

local wer_report_id

1979e99

sentry Bot reviewed May 29, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

wip(native): capture WER custom metadata#1760

wip(native): capture WER custom metadata#1760
jpnurmi wants to merge 19 commits into
masterfrom
jpnurmi/feat/native/wer-metadata

jpnurmi commented May 27, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

linear-code Bot commented May 27, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sentry Bot May 29, 2026

Uh oh!

Uh oh!

Uh oh!

cursor Bot left a comment

Uh oh!

cursor Bot May 29, 2026

Uh oh!

sentry Bot May 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

jpnurmi commented May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

linear-code Bot commented May 27, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sentry Bot May 29, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cursor Bot May 29, 2026

Choose a reason for hiding this comment

Unnecessary 5-second blocking for SIGABRT with WER enabled

Uh oh!

sentry Bot May 29, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

jpnurmi commented May 27, 2026 •

edited

Loading