0

I am trying to figure out what is causing exceptions for “.NET CLR Exceptions# of Exceps Thrown / sec“ I am following the instructions in How to figure out cause of high number of exceptions.

I was able to get the dump but I am getting error while trying to execute WindDg

!dumpheap -stat -type Exception

Failed to find runtime DLL (mscorwks.dll), 0x80004005

The machine I took the dump was a windows 2012R2 64bit the I took a dump of w3wp process. I used procdump64.exe to take the dump. For symbol package I used Windows RT 8.1 ARM, Windows 8.1 and Windows Server 2012 R2

I am running WinDbg on my Windows 10 Desktop

Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\kumar\Desktop\w3wp.exe_161122_083122\w3wp.exe_161122_083122.dmp]
User Mini Dump File with Full Memory: Only application data is available

Comment: '
*** procdump64.exe  2348 -ma -s 5 -p "\.NET CLR Exceptions(w3wp)\# of Exceps Thrown / sec" 100
*** Counter "# of Exceps Thrown / sec" exceeded 100 for 5 seconds. Value: 220'

************* Symbol Path validation summary **************
Response                         Time (ms)     Location
OK                                             E:\Symbols
Symbol search path is: E:\Symbols
Executable search path is: 
Windows 8.1 Version 9600 MP (2 procs) Free x64
Product: Server, suite: TerminalServer DataCenter SingleUserTS
Built by: 6.3.9600.17031 (winblue_gdr.140221-1952)
Machine Name:
Debug session time: Tue Nov 22 14:01:23.000 2016 (UTC + 5:30)
System Uptime: 13 days 23:42:27.204
Process Uptime: 0 days 16:40:05.000
................................................................
................................................................
................................................................
....................................................
Loading unloaded module list
.....................................
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for KERNELBASE.dll - 
ntdll!ZwWaitForSingleObject+0xa:
00007ffe`f39206fa c3              ret
0:000> .load C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.dll
The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.dll) failed, Win32 error 0n193
    "%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.
0:000> .load C:\Windows\Microsoft.NET\Framework64\v2.0.50727\sos.dll
0:000> !dumpheap -stat -type Exception
Failed to find runtime DLL (mscorwks.dll), 0x80004005
Extension commands need mscorwks.dll in order to have something to do.
0:000> .loadby sos mscorwks
Unable to find module 'mscorwks'
0:000> .loadby sos clr
The call to LoadLibrary(D:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos) failed, Win32 error 0n126
    "The specified module could not be found."
Please check your debugger configuration and/or network access.
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
kumar
  • 8,207
  • 20
  • 85
  • 176
  • That's a likely outcome on Win10, it no longer has the v2.0.50272 version of the .NET runtime installed. So no sos.dll and no mscorwks.dll. 6 years is a lot of dog lives in free software. Use Control Panel > Programs and Features > Turn Windows features on or off > tick the ".NET Framework 3.5" checkbox to get it installed. Hopefully the DAC version is a match, if not then tell you user to keep his machine updated. – Hans Passant Nov 23 '16 at 11:07
  • 1
    @HansPassant: I'd say the dump contains .NET 4, since the `.loadby sos clr` command almost succeeded. So this is likely not a .NET 2 issue. – Thomas Weller Nov 23 '16 at 15:48

2 Answers2

1

There are a few issues in your setup:

  1. even basic symbols like ntdll cannot be found. Something with the symbols you downloaded does not work as expected. This will make all your results doubtful. See How to set up symbols in Windbg

  2. Your process is not using .NET2, it's using .NET 4. You can see this from the fact that it found a path where it was looking for SOS

    D:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos

    The problem is likely that you don't have Windows installed on D:. Use the full path to load the SOS extension for .NET 4 instead.

    Use lm m clr and lm m mscorwks and lm m coreclr to find out which .NET version was loaded, before you load an arbitrary extension.

  3. Regarding DAC files: After setting up the symbols, use !analyze -v. I have seen this download the necessary mscordacwks files.

    • if this does not work, get the files from the original machine. You can use mscordacwks collector (disclaimer: a tool that I wrote exactly for this purpose)

    • if this is not possible, you can look up the mscordacwks and sos archive (disclaimer: a collection of such files made by me)

  4. If the debugging DLL cannot be loaded (%1 is not a valid Win32 application), this is due to a bitness mismatch. Use the 64 bit version of WinDbg to analyze a 64 bit crash dump and the 32 bit version of WinDbg for 32 bit crash dumps. Use 64 bit extensions in 64 bit WinDbg and 32 bit extensions in 32 Bit WinDbg.

Community
  • 1
  • 1
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
-2

When using WinDBG with .NET/SOS, it's recommended that you do the analysis on the same server that generated the dump, or as close to a reproduction of it as possible (eg. from an image).

Even different framework patch levels will cause things to fail, so it's not really worth the effort to fight the recommendation, based on my experience.

Richard Szalay
  • 83,269
  • 19
  • 178
  • 237
  • Fun fact: the "SOS" debugging extension drives it's name from a codename for .net before it's original release. At that time .net was known as "Lightning" and the internal debugging tool was called "Strike". When the team build a public version of the extension based on the original, they called it SOS: Son of Strike. – Richard Szalay Nov 23 '16 at 10:46