Cannot open Azure App Service .NET Core 2 dump file in WinDGB (2 runtimes present in dump file)

Question

I'm having some troubles opening a dump file of a .NET Core process in WinDBG. I used to debug .NET framework dumps using WinDBG, without any issues, but with a dump coming from an Azure App Service there is something weird: both the clr.dll and the coreclr.dll are loaded inside the process..

As a result, using the correct version of SOS from WinDBG (the one from the dotnet core sdk installation path on my Azure VM), shows the following error when running !dumpheap:

0:000> !dumpheap
Error requesting GC Heap data
Unable to build snapshot of the garbage collector state

I tried to publish my App Service locally, as self-contained or framework-dependent, and run the published binaries. There is ONLY the .NET Core Runtime (coreclr.dll) loaded in the process, as my project targets .NET Core 2.1.

Once deployed to Azure, the binaries are ran by IIS, using the w3wp process. Is this process injecting some dependencies in my app service that require .NET Framework? Why my .NET Core 2.1 app running on Azure has some dependency with .NET Framework?

When analyzing the dump file (using ClrMD), there is two runtimes present inside:

• .NET Core (mscordaccore_X86_X86_4.6.26212.01.dll)
• .NET Framework (mscordacwks_X86_X86_4.7.2563.00.dll)

Tested scenarios (that did not work):

• Opening 32bits dump of a framework-dependent deployed app on Azure using WinDBG v10 (from Win10 SDK)
• Opening 32bits dump of a framework-dependent deployed app on Azure using WinDBG Preview v1.0.1805.17002
• Opening 64bits dump of a self-contained depoyed app on Azure (from Win10 SDK) using WinDGB Preview v1.0.1805.17002

What is working (almost):

• DebugDiag can analyze the dump and show some information about the heap (so it 's able to read it somehow)
• I managed to read the dump with ClrMD using custom C# code, but not all objects seems present when I browse the heap (some objects shown by DebugDiag are not visible when I browse the heap manually).

Nevertheless, I need to be able to read the dump with WinDGB to find a potential memory leak. It's been hours that I'm working on it and can't find any solution.

Any help would be greatly appreciated! :)

Answer 1

Had a similar issue and fixed it by running these commands.

You are correct in that windbg is using the wrong CLR (wrong as in not the net core app). You can prove this by running command .cordll and seeing the runtime files used path.

Tell debugger what dotnet runtime to use

.cordll -I coreclr -lp "D:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\2.1.1"

Unload and reload CLR debugging modules

.cordll -ve -u -I coreclr -l