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

3
votes

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! :)

1
.netazure.net-corewindbgsos
Why do you have .NET Framework enabled for your application when it is unnecesary? – Lex Li
He has no dependency on .net Framework when running the app in local. But once deployed on azure, the clr.dll is loaded. When he does a full dump on dotnet.exe he can see that the clr module is loaded – Steven Muhr
Just for curiosity reason, could you try to open this dump in JetBrains dotMemory? I'm interested if there will be the error too. – Ed Pavlov
Using JetBrains dotMemory I got the exception: This runtime is not initialized and contains no data. Using SciTech .Net Memory Profiler I can open the dump but all object instances related to .NET Core framework are not visible whereas all objet instances related to .NET Framwork are visible. – Jerome Thievent
@JeromeThievent, and is there a chance that you can upload your dump along with corresponding mscordaccore.dll/mscordacwks.dll to uploads.services.jetbrains.com ? We are curious to investigate dotMemory behaviour in this case but the issue doesn't seem to reproduce in our test environment. Thanks in advance! – Ruslan Isakiev

1 Answers

6
votes

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