Better Windows dump-based StackOverflow diagnostics #4944
Labels
enhancement
New feature or request
Milestone
Comments
noahfalk
added a commit
to noahfalk/docs
that referenced
this issue
Sep 20, 2024
Added some debugging instructions for debugging a StackOverflow on Windows and made some minor improvements to the pre-existing text. Unfortunately the Windows and Linux instructions remain asymmetric because the dump debugging experience for StackOverflow on Windows isn't good (dotnet/diagnostics#4944). In the future we might also want to add instructions for using VSCode on Linux or add more to the lldb debugging instructions but I didn't want to expand the scope too much for now.
noahfalk
added a commit
to dotnet/docs
that referenced
this issue
Sep 23, 2024
* StackOverflow debug improvements Added some debugging instructions for debugging a StackOverflow on Windows and made some minor improvements to the pre-existing text. Unfortunately the Windows and Linux instructions remain asymmetric because the dump debugging experience for StackOverflow on Windows isn't good (dotnet/diagnostics#4944). In the future we might also want to add instructions for using VSCode on Linux or add more to the lldb debugging instructions but I didn't want to expand the scope too much for now. Co-authored-by: Tom McDonald <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On Windows if an application crashes with a stack overflow and a dump is collected, looking at it in both Visual Studio and windbg gives little clue about the callstack which caused the overflow.
For repro and observed behavior, see #3506. #3506 tracks improving the documentation, this issue tracks improving the actual product experience.
The desired behavior is that both VS and windbg should prominently show that a StackOverflow occured and show the callstack frames that ran recursively to cause the overflow.
The text was updated successfully, but these errors were encountered: