如何调试 Windows Store 应用程序中的内存泄漏?应用程序、内存、Windows、Store

由网友(ン何以述情)分享简介:所以我有一个 .NET Windows Store 应用程序正在泄漏内存.我能做些什么呢?我用于 jetBrains 或 Red-Gate/ANTS 桌面应用程序的分析器工具不支持 Metro 应用程序(或者现在支持吗?)So I have a .NET Windows Store app that is leaki...

所以我有一个 .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.

您可以从

阅读全文

相关推荐

最新文章