You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are various single file issues that need to be fixed in SOS/dotnet-dump:
dotnet-dump doesn't work on Linux system generated single file core dumps (createdump doesn't work for single file yet). The problem is that the ELF reader in clrmd used by dotnet-dump returns the wrong base address for the single file module. See below for more details.
Windows single-file dumps (generated by createdump or dotnet-dump collect) do not work under windbg/SOS because the dbgeng doesn't find the DotNetRuntimeInfo export.
Windows dotnet-dump doesn't work for single-file dumps because the clrmd PE reader needs to implement the export symbol lookup.
Add Windows single-file support to the fallback runtime enumeration in platform/targetimpl.cpp. Need C++ to lookup PE exports.
!pe doesn't print any stack trace info for live Windows single-file under dbgeng. !clrstack does work/displays stack trace.
Add tests for single-file SOS support.
Remove generating full dumps in SOS test runner for single file apps when supported.
Enable single file dumps on overflow exception when the exception info is properly is captured in the Windows dump
The clrmd PE symbol export work should mitigate the need for the DOTNET_ENABLE_SOS_SINGLEFILE env var which was added because the dbgeng symbol lookup was so slow.
There are various single file issues that need to be fixed in SOS/dotnet-dump:
The clrmd PE symbol export work should mitigate the need for the DOTNET_ENABLE_SOS_SINGLEFILE env var which was added because the dbgeng symbol lookup was so slow.