dotnet / dotnet/diagnostics

Captured memory dump of MSIX packaged app, doesn't contain threads and call stack information (again)

Open
#5,828 2 comments 0 reactions 1 assignee Claimed by @tommcdon View on GitHub
bug tracking-external-issue
Dominant language
C++
Stars
1.3k
Forks
404
Avg merge
2d 5h
Merged PRs (30d)
35

Description

_I am reproducing the same issue as https://github.com/dotnet/diagnostics/issues/4833 (cc @ekalchev):_

Mini memory dumps captured with different tools (CrashRpt, dotnet-dump.exe both using MiniDumpWriteDump WINAPI call) of a .NET self-contained MSIX packaged process doesn't have managed thread and managed callstack information, unless Full memory dump is captured.

My 5 cents: I fear this is due to a MSIX "security limitation" that disallows other packaged or unpackaged processes to `LoadLibrary` DLLs from the MSIX app directory. AFAIK `MiniDumpWriteDump` tries to load some "DAC DLL" from the app directory, which would normally enrich the dump with the necessary information. If that DLL cannot be loaded, the dump will not get any managed information etc. That's just my first guess, which I hope is not true, because it would mean that is a Windows limitation.

### Steps to reproduce:

1. Install and run a .NET MSIX packaged app
**easy to reproduce:** download [WinUI 3 Gallery app from Microsoft Store](https://apps.microsoft.com/detail/9P3JFPWWDZRC)
**otherwise:** Deploy the packaged application (do not run it from Visual Studio). It must be deployed in WindowsApp directory
2. Capture a memory dump with dotnet-dump.exe using any of the following commands
```
dotnet-dump collect -p --type mini
dotnet-dump collect -p --type triage
dotnet-dump collect -p --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 --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.`

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.