Captured memory dump of MSIX packaged app, doesn't contain threads and call stack information (again)
维护者通常 1 天内回复
@tommcdon 已经在做这个了。
开始于 2026年5月5日。
评估
这个 Issue 还没有评估数据。
描述
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:
- Install and run a .NET MSIX packaged app
easy to reproduce: download WinUI 3 Gallery app from Microsoft Store
otherwise: 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.
- 主要语言
- C++
- 星标
- 1.3k
- 派生
- 407
- 平均合并
- 21 小时 5 分钟
- 30 天内合并 PR
- 78
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
dotnet/diagnostics 的其他 Issue
-
Fix StackAndOtherTests.script line number verification for .NET 11 and Windows x64可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 2/5 1-3 小时 新手友好度 65/100
dotnet/diagnostics#5884 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 25/100
dotnet/diagnostics#6225 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
dotnet/diagnostics#6213 ·
维护者通常 1 天内回复
-
Isolate SOS hosting from other debugger extensions that use managed code可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭bug
难度 5/5 一周以上 新手友好度 25/100
dotnet/diagnostics#6207 ·
维护者通常 1 天内回复
-
Known Build Error
难度 4/5 3-5 天 新手友好度 49/100
dotnet/diagnostics#6190 ·
维护者通常 1 天内回复
查看 dotnet/diagnostics 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 79/100
维护者通常 1 天内回复
-
just: test-quest-combat exits 1 without the combat script libraries after every host test passed未关闭backlog bug
难度 2/5 1-3 小时 新手友好度 76/100
EchoTools/nevr-runtime#2665 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
AutoHotkey/AutoHotkey#380 ·
-
documentation
难度 1/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 69/100
grumpycoders/pcsx-redux#2667 ·