Clarify that WER LocalDumps registry values are optional - #338
Open
daveplunkett wants to merge 1 commit into
Open
Clarify that WER LocalDumps registry values are optional#338daveplunkett wants to merge 1 commit into
daveplunkett wants to merge 1 commit into
Conversation
The upgrade guide claimed WER stops creating dumps after a few crashes of the same type and that DumpType=0 / DumpCount=0 were needed to disable this. That is not how these values work, and BugSplat does not consume the dumps WER writes: BugSplatMonitor writes its own minidump when WER hands a crash to BugSplatWer.dll. Reword the section to explain that only the RuntimeExceptionHelperModules entry is required, and that the LocalDumps values merely prevent WER from writing a duplicate dump when local dump collection is enabled. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hci8qhAhPSkzqFM7eWfKCM
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
Only minor documentation structure feedback remains, with no functional or high-risk changes introduced.
Pull request overview
This PR updates the BugSplat for Windows upgrade guide to clarify that WER LocalDumps registry settings are optional for BugSplat’s WER integration, and corrects the prior (inaccurate) rationale for those values.
Changes:
- Adds an “Optional: Suppressing WER Local Dumps” subsection explaining that only
RuntimeExceptionHelperModulesis required for BugSplat WER integration. - Reframes
DumpType/DumpCountas optional settings to suppress WER’s duplicate local dumps when local dump collection is enabled. - Updates references/links to Microsoft WER documentation.
File summaries
| File | Description |
|---|---|
| introduction/getting-started/integrations/desktop/cplusplus/bugsplat-for-windows-upgrade-guide.md | Clarifies optional WER LocalDumps behavior and updates guidance/linking around registry settings. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| <figure><img src="../../../../../.gitbook/assets/image (1) (1) (1).png" alt=""><figcaption></figcaption></figure> | ||
|
|
||
| By default, WER will stop creating crash dumps after it has seen a few of the same type. To disable this, create the following registry key:  | ||
| #### **Optional: Suppressing WER Local Dumps** |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The Registry Changes section of the BugSplat for Windows upgrade guide told users to create
LocalDumps\{Application Name}withDumpType=0andDumpCount=0, justified by the claim that "WER will stop creating crash dumps after it has seen a few of the same type." That justification is inaccurate, and a customer asked us to explain what the values actually do.What the SDK does: when WER hands a crash to
BugSplatWer.dll, the module claims ownership and signalsBugSplatMonitor.exe, which writes its own minidump directly from the crashed process using the type configured viaSetMiniDumpType. BugSplat never reads the dump WER writes, so theLocalDumpsvalues have no effect on what BugSplat captures or uploads. The only required registry entry for WER integration isRuntimeExceptionHelperModules.Per Microsoft's documentation,
LocalDumpsis "configured and controlled independently of the rest of the WER infrastructure";DumpCountis the maximum number of dump files WER keeps (default 10), andDumpType=0selects a custom dump driven byCustomDumpFlags. SettingDumpCount=0simply stops WER from retaining its own duplicate dump when local dump collection is enabled on the machine.Changes
RuntimeExceptionHelperModulesis required and that BugSplat writes its own minidump.DumpType/DumpCounttable as optional duplicate-dump suppression, with accurate descriptions of each value.🤖 Generated with Claude Code
https://claude.ai/code/session_01Hci8qhAhPSkzqFM7eWfKCM
Generated by Claude Code