Trying to Debug Windows Store App from Dump Files

How to debug memory leaks in Windows Store apps?

For the simplest approach - skip to the bottom to read about the description of doing that with Visual Studio 2013.

---

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

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.

---

You can download WinDbg as part of Windows SDK or as a standalone download of "Debugging Tools for Windows" from here.

To create a dump file - go to Task Manager, right click a proces and select "Create dump file".

---

Some more links:

http://blogs.microsoft.co.il/blogs/sasha/archive/2012/10/15/diagnosing-memory-leaks-in-managed-windows-store-apps.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

http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/f3a3faa3-f1b3-4348-944c-43f11c339423

http://msdn.microsoft.com/en-us/library/bb190764.aspx

http://blogs.msdn.com/b/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx

---

*EDIT

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.

---

*EDIT 2

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.

How to debug a Library using Windows Store App

Add the PCL to your Windows Store App's solution. You will be able to debug it just the same as your Windows Store App.

Inspect dump files from UWP app

You mention

[...] 0xC000027B [...]

[...] $stowedexception [...]

which are both indicators that there is a Stowed Exception inside the dump.

To analyze such exceptions, first watch Channel 9 Defrag Tools, episode 136 where Andrew Richards explains and then analyzes them (at 3:28).
Then download the PDE extension from the Defrag Tools OnDrive and analyze your dump in windbg instead of Visual Studio.

Regarding the symbols of kernelbase, they should be downloaded from the Microsoft symbol server. To set that up in WinDbg, use .symfix;.reload. If you want to give it another try in Visual Studio, go to Debug / Options and choose Debugging / Symbols, then check "Microsoft Symbol Servers".

Regarding the button to press in Visual Studio, choose "Managed only" when debugging the debug build, because your app will run on CoreCLR and choose "Native Only" when debugging the release build, because your app will use .NET native runtime support. (This applies if you didn't change the default settings; otherwise choose according to your compilation settings)

Windows 8 Store - Debug App Downloaded from store

Ok, it works if you follow these steps:

Debug->Debug Installed App Package

Make sure that "Debug this code type:" says "Mixed (Managed and Native)"

Once I checked that box, it worked fine, but of course debugging was pretty slow.

PS - You also have to include the symbol files in the original build uploaded to the store. This is a good reason to always do this.

---

Related Topics