fix(win): resolve correct symbol names in client-side stack traces for multi-module apps#156
Merged
mujacica merged 1 commit intoJun 22, 2026
Conversation
…r multi-module apps
mujacica
approved these changes
Jun 22, 2026
JoshuaMoelans
approved these changes
Jun 22, 2026
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.
This PR fixes incorrect or irrelevant function names in client-side stack traces (
CRASHPAD_ENABLE_STACKTRACE) on Windows for applications composed of many modules.Problem
When the snapshot walks a crashed thread's stack (
ProcessReaderWin::ReadThreadData → DoStackWalk), it resolves frame addresses to function names viadbghelp, initialized with a NULL symbol search path. Without a search path,dbghelpcannot locate each module’s PDB and falls back to the module’s export table, mislabeling internal (non-exported) functions with the nearest exported symbol.This issue is mostly invisible in monolithic applications but breaks down in multi-module setups where code is split across many DLLs in different directories. In those cases,
dbghelpcannot locate most PDB files, so frames resolve to unrelated or misleading symbols even though the underlying stack addresses are correct (x64/ARM64 unwinding still works via module unwind metadata and does not require PDBs).A concrete example is the Unreal Engine Editor, where functionality is distributed across many
UnrealEditor-*.dllmodules and plugins located in separateBinaries/directories. In these cases, crash reports showed misleading callstacks, while packaged monolithic game builds were unaffected.Proposed fix
Build a symbol search path from the directories of all loaded modules (
process_info_.Modules()) and pass it todbghelpviaSymInitializeW, allowing it to locate PDBs alongside their corresponding DLLs (equivalent tocdb -y <dirs>).;-separated directory list (case-insensitive deduplication).SYMOPT_FAIL_CRITICAL_ERRORS | SYMOPT_NO_PROMPTSto prevent dbghelp from blocking on dialogs in unattended environments, while keepingSYMOPT_DEFERRED_LOADSso symbol loading remains lazy and efficient across many modules.Scoped to
CLIENT_STACKTRACES_ENABLEDon Windows only. No behavior changes when the feature is disabled. Single-file change with no API or public interface modifications.Related items
CRASHPAD_ENABLE_STACKTRACEis Enabled sentry-unreal#1422