Captured memory dump of MSIX packaged app, doesn't contain threads and call stack information
ekalchev opened this issue · 2 comments
Mini memory dumps captured with different tools (CrashRpt, dotnet-dump.exe both using MiniDumpWriteDump WINAPI call) of a .net 8 self-contained MSIX packaged process doesn't have managed thread and managed callstack information, unless Full memory dump is captured
Steps to reproduce:
- Create empty WPF application and package it as MSIX (with .wapproj in visual studio)
- Deploy the packaged application (do not run it from Visual Studio). It must be deployed in WindowsApp directory
- Capture a memory dump with dotnet-dump.exe using any of the following commands
dotnet-dump collect -p <pid> --type mini
dotnet-dump collect -p <pid> --type triage
dotnet-dump collect -p <pid> --type heap
Expected:
Generated memory dumps to show CLR threads and call stacks when loaded in Visual Studio or WinDbg
Actual:
Generated memory dumps doesn't show CLR threads and call stacks
Notes:
This problem is only present when the app is packaged as MSIX. I ran multiple test setups for the same app and the packing type is what triggers this issue. Same app packaged as MSI doesn't have those problems.
Also using dotnet-dump collect -p <pid> --type full
resolve the problem but it creates dumps, that are very big andunpractical to use for diagnostic for crashes from client machines.
When I run WinDbg command on one of the memory dumps that suffer from the bug i see this error
!clrthreads
Failed to request ThreadStore
Visual Studio show this error message in the console
The minidump has no heap. Managed minidump debugging will have limited data inspection.
The only issue i can find close to this one is #1425
but my issue is only for MSIX packaged apps and it seems to work fine for non-MSIX packaged apps.
We've updated dbghelp.dll that was part of the installation package (we had very old version from windows 7 SDK) with version from the latest Windows SDK and it is working now.
I don't understand how dbghelp.dll bundled with our code make dotnet-dump to fail to create usable memory dumps.
We've updated dbghelp.dll that was part of the installation package (we had very old version from windows 7 SDK) with version from the latest Windows SDK and it is working now.
I don't understand how dbghelp.dll bundled with our code make dotnet-dump to fail to create usable memory dumps.
On Windows dotnet-dump
uses MiniDumpWriteDump to collect a dump. This API exists on dbghelp.dll. Presumably there is some bug in that exists in the previous version that subsequently has been fixed.