如何调试 Windows Store 应用程序中的内存泄漏? [英] How to debug memory leaks in Windows Store apps?
问题描述
所以我有一个 .NET Windows Store 应用程序正在泄漏内存.我能做些什么呢?我用于 jetBrains 或 Red-Gate/ANTS 桌面应用程序的分析器工具不支持 Metro 应用程序(或者现在支持吗?)
So I have a .NET Windows Store app that is leaking memory. What can I do about it? The profiler tools I used for desktop apps from jetBrains or Red-Gate/ANTS don't support Metro Apps (or do they now?)
推荐答案
对于最简单的方法 - 跳到底部阅读有关使用 Visual Studio 2013 执行此操作的说明.
For the simplest approach - skip to the bottom to read about the description of doing that with Visual Studio 2013.
现在可能会有一些新工具 - 可能是更新后的 Visual Studio 中的一些东西，我很想找到这些工具，但我之前尝试过 WinDbg 并取得了一些成功.这是我关于如何做到这一点的旧笔记:
Now there might be some new tools - perhaps something in the updated Visual Studio and I would love to find about these, but I tried WinDbg before with some success. Here are my old notes on how to do that:
1. Create dump file from process manager
2. Run WinDbg (X64)
3. File/Open Crash Dump… (Crtl+D)
4. Run following:
lm
.load C:windowsMicrosoft.NETFramework64v4.0.30319sos.dll
.sympath SRV*c:localsymbols*http://msdl.microsoft.com/download/symbols
.symfix
.reload
!dumpheap -stat
请注意，如果您的进程是 x86，尤其是如果您在 x64 版本的 Windows 上运行 - 您将需要使用 x86 版本的调试器(WinDbg 提供这两个版本)来保存转储.SOS 是 WinDbg 的托管内存调试扩展，不支持调试 x86 位进程的 x64 位转储.然后你还需要分别更新sos路径，如下所示:
Note that if your process if x86, especially if you are running on a x64 version of Windows - you will need to use an x86 version of the debugger (WinDbg ships both versions) to save the dump. SOS, which is a managed memory debugging extension for WinDbg does not support debugging x64 bit dumps of x86 bit processes. You will then also need to update the sos path respectively, so it looks like this:
.load C:windowsMicrosoft.NETFrameworkv4.0.30319sos.dll
可能并非所有这些命令都是必需的，但这对我有用.
Possibly not all of these commands are necessary, but this is what worked for me.
现在您可以找到似乎存在于太多实例中的对象的类型
Now you can find the type of the object that seems to exist in too many instances
!DumpHeap -type TypeName
其中 type name 只是类型的名称 - 不需要完全限定的命名空间.
where type name is just the name of the type - no fully qualified namespace necessary.
现在你可以检查是什么让这个对象在内存中:
Now you can check what keeps this object in memory:
!GCRoot Object_Address
<小时>
实时调试对我不起作用，因为当您附加调试器时应用似乎暂停了.我想我在某处看到了使应用程序留在内存中的选项，但我忘记了在哪里，但对于内存分析 - 查看静态转储文件可能就足够了.
Live debugging didn't work for me since the app seems to get suspended when you attach a debugger. I think I saw an option somewhere to make the app stay in memory, but I forgot where, but for memory profiling - looking at a static dump file might be enough.
您可以从 这里.
要创建转储文件 - 转到任务管理器，右键单击进程并选择创建转储文件".
To create a dump file - go to Task Manager, right click a proces and select "Create dump file".
更多链接:
http://msdn.microsoft.com/en-us/library/bb190764.aspx
*编辑
根据 .NET 内存分配分析与 Visual Studio 2012 由 Stephen Toub - PerfView 工具支持分析 .NET Windows Store 应用程序中的漏洞.查看 Vance Morrison 这里.
According to .NET Memory Allocation Profiling with Visual Studio 2012 by Stephen Toub - PerfView tool supports analyzing leaks in .NET Windows Store apps. Check an article and video walkthrough with Vance Morrison here.
*编辑 2
Visual Studio 2013 Preview 添加了一个新选项来分析转储文件中的托管内存堆.要做到这一点 - 只需在 Visual Studio 调试器中暂停您的应用程序，通过 Debug/Save Dump As 保存您当前的转储，然后恢复执行并使用您的应用程序，直到您怀疑发生泄漏并执行另一个转储.然后转到文件/打开/文件并打开第二个转储文件.在操作"面板中转储摘要的右侧，您将看到调试托管内存"操作.选择它，然后在选择基线"中选择您的第一个转储文件.您将看到托管堆上的对象列表，按类型分组，具有计数差异.请注意，您通常会首先查看具有低、非零计数差异的对象以跟踪单个泄漏源.您可以通过在 Reference Graph 视图中展开树来深入了解对象列表并查看将它们保留在内存中的内容.
Visual Studio 2013 Preview adds a new option to analyze managed memory heaps from dump files. To do it - simply pause your app in the Visual Studio debugger, save your current dump through Debug/Save Dump As, then resume execution and use your app until your suspected leak happens and do another dump. Then go to File/Open/File and open the second dump file. To the right of the Dump Summary in the "Actions" panel you'll see a "Debug Managed Memory" action. Select that and then in "Select Baseline" select your first dump file. You will see a list of objects on the managed heap, grouped by type, with count diffs. Note that you would typically first look at the objects with low, non-zero count differences to track a single leak source. You can drill into the list of objects and see what keeps them in memory by expanding the tree in the Reference Graph view.
这篇关于如何调试 Windows Store 应用程序中的内存泄漏?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
