如何调试在Windows应用商店应用程序的内存泄漏？ [英] How to debug memory leaks in Windows Store apps?
问题描述
所以我有一个.NET Windows应用商店的应用程序，正在泄漏内存。我该怎么办呢？探查工具，我用从JetBrains公司或红门桌面应用程序/蚂蚁不支持地铁应用程序（或他们吗？）
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:\windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll
.sympath SRV*c:\localsymbols*http://msdl.microsoft.com/download/symbols
.symfix
.reload
!dumpheap -stat
请注意，如果你的过程中，如果86，特别是如果你在Windows的64位版本上运行 - 你需要使用调试器的x86版本（WinDbg的船只两个版本），以保存转储。 SOS，这是一个管理内存调试扩展WinDbg中不支持调试86位进程的64位转储。然后，您还需要分别更新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:\windows\Microsoft.NET\Framework\v4.0.30319\sos.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
其中，类型名称是该类型只是名字 - 没有完全限定的命名空间需要
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.
您可以下载的WinDbg与Windows SDK的一部分或作为Windows调试工具从的这里。
You can download WinDbg as part of Windows SDK or as a standalone download of "Debugging Tools for Windows" from here.
要创建转储文件 - 去任务管理器中，右键单击一个PROCES，选择创建转储文件
To create a dump file - go to Task Manager, right click a proces and select "Create dump file".
一些更多的链接：
<一个href="http://blogs.microsoft.co.il/blogs/sasha/archive/2012/10/15/diagnosing-memory-leaks-in-managed-windows-store-apps.aspx">http://blogs.microsoft.co.il/blogs/sasha/archive/2012/10/15/diagnosing-memory-leaks-in-managed-windows-store-apps.aspx
<一个href="http://blogs.msdn.com/b/delay/archive/2009/03/11/where-s-your-leak-at-using-windbg-sos-and-gcroot-to-diagnose-a-net-memory-leak.aspx">http://blogs.msdn.com/b/delay/archive/2009/03/11/where-s-your-leak-at-using-windbg-sos-and-gcroot-to-diagnose-a-net-memory-leak.aspx
<一个href="http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/f3a3faa3-f1b3-4348-944c-43f11c339423">http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/f3a3faa3-f1b3-4348-944c-43f11c339423
<一个href="http://msdn.microsoft.com/en-us/library/bb190764.aspx">http://msdn.microsoft.com/en-us/library/bb190764.aspx
<一个href="http://blogs.msdn.com/b/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx">http://blogs.msdn.com/b/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx
*编辑
据<一href="http://blogs.msdn.com/b/dotnet/archive/2013/04/04/net-memory-allocation-profiling-with-visual-studio-2012.aspx">.NET内存分配性能分析与Visual Studio 2012 通过斯蒂芬Toub - PerfView 工具支持在分析.NET Windows应用商店的应用程序泄漏。请与万斯·莫里森的文章和视频演练，<一个href="http://blogs.msdn.com/b/dotnet/archive/2012/10/09/improving-your-app-s-performance-with-perfview.aspx">here.
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调试，通过调试/保存保存当前转储转储为，然后继续执行，并使用你的应用程序，直到你怀疑发生泄漏，做一套转储。然后转到文件/打开/文件，然后打开第二个转储文件。要的转储摘要中的动作面板右边你会看到一个调试托管内存的行动。选择，然后在选择基线，选择你的第一个转储文件。你会看到在托管堆中的对象，按类型分组名单，以计数的diff。请注意，您通常会先看看有低，无零计数差异的对象跟踪单个泄漏源。您可以钻入对象列表，看看通过展开树中的引用图表视图保存在内存中。
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应用商店应用程序的内存泄漏？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
