It seems you're not very familiar with WinDbg, so I'll be a bit more verbose than necessary.
WinDbg - x86 is the version that can open this dump file
Any version and bitness of WinDbg will be able to open the dump. Even the 32 Bit WinDbg can open a 64 bit .dmp file. This does not mean that you use the correct version to do what you want to achieve.
This doesn't give an error, but no other output, either.
That's ok. It means that the extension was loaded successfully. That's good to know, because it means you're using the correct bitness of WinDbg. If it's really the x86 WinDbg you use, this indicates you have a 32 bit SOS DLL.
If the bitness is incorrect, you get an error message, the same as if you try loading a 32 bit DLL into a 64 bit process or vice versa (aka. BadImageFormatException in .NET)
Extension commands need clr.dll in order to have something to do.
The SOS extension is for .NET, so SOS is looking for a .NET framework loaded into the process. This may be
clr.dll for .NET 4 / 4.5 and maybe highermscorwks.dll for .NET 2 / 3 / 3.5coreclr.dll for Silverlight and .NET Core
From the message, we can derive that you have a SOS.dll for .NET 4, which is why it's looking for clr.dll instead of something else. Sounds reasonable for an Azure webservice, since Azure is newer than .NET 2.
To see whether .NET was actually loaded into the process, use the following commands:
lm m clr
lm m mscorwks
lm m coreclr
If any of these commands produces some output, you'll know which version was loaded. Note that .NET 4 and .NET 2 may occur in parallel (both versions used in the process).
I have tried .load directly on mscordacwks.dll, renaming it to clr.dll.
Here's a huge misunderstanding:
.load loads something into the WinDbg process. Even if you manage to load it there, SOS will still search for it in the dump file instead.mscordacwks is not the .NET framework. Do not confuse it with mscorwks. The dac part is for data access control. It's a DLL to manage access to the .NET structures in memory, since .NET has its own memory management.
However, renaming it, might be needed. That's a difficult story. It seems you already found Google results for it...
renaming it to mscordaccore_X86_X86_4.6.24628.01.dll
It goes into the right direction, but I don't think that's the correct name. Would you mind linking the original advice, so I can do some research before complaining about something I might have old knowledge about?
IMHO the name should be
mscordacwks_x86_x86_4.6.24628.01.dll
(if the version number is correct).
As mentioned by @Lieven Keersmaekers in the comments already, having a correct symbol path pointing to Microsoft and then doing a
!analyze -v
should download the necessary mscordacwks files from Microsoft. That way it will automatically have the correct name and be located in the correct folder.
I've also tried running the DebugDiag 2 analysis tool
For DebugDiag to work correctly, it also needs mscordacwks. The easiest way would be to also use the Microsoft symbol server, so that it can download the file itself.
I just want to know why my App Service gets stuck at 100% CPU
Analyzing that from a single crash dump file is erroneous. The process might just have been doing something "normal" when you captured the crash dump file.
If you have many crash dumps with the same call stack, that might indicate that this method is in an endless or at long running loop. To get many crash dumps automatically at high CPU, try ProcDump, see how to take a good crash dump for .NET
What else might have gone wrong?
You said you were supplied with those files. From the naming of the files, I assume they were taken from the machine where the crash happened. That's basically a good idea. Be aware that there are many such files on a PC.
If you run my tool mscordacwks Collector, you'll see what I mean. That tool by the way will detect the versions and rename the files accordingly. Perhaps you can try it, it the machine is still available.
