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:windowsMicrosoft.NETFramework64v4.0.30319sos.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: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
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.
