Sos.dll和windbg获取引发的异常

Question

I am using sos.dll and windbg to anayze a w3wp.exe dump. There is a high number of .Net CLR exceptions thrown per/sec shown in perfmon and i am trying to investigate this. I tried doing a !dumpheap -stat -type Exception. But does this show the exceptions that were thrown at the instance i took the dump or does this show all the exception object instances that were created? Exception object instances may be created without being thrown.

Is there a way to just get the exceptions that were thrown?

Answer 1

You use the wrong tools. Install Windows Performance Toolkit which is part of the Windows 10 SDK. The 1607 SDK can be used for Win8/10 systems, the older 1511 SDK can be used for Windows 7/2008R2.

Now use the WPRP profile that I posted here to capture the activity of your application by opening a cmd.exe as admin

"C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\wpr.exe" -start C:\DotNetRuntime.wprp

After captured some activity of your tool, run this command to stop the capturing:

"C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\wpr.exe" -stop C:\Result.etl

Now make a double click on the Result.etl to open it in Windows Performance Analyzer and load debug symbols .

Now drag & drop the Generic Event graph to the analysis pane, order the colums for Provider , process , Taskname , Field 1 , Time , Opcode Name and Stack . Now filter for the Microsoft-Windows-DotNETRuntime provider and expand your process name entry and next expand the entry for Taskname Exception :

Here in this demo, the VS Addon Resharper caused a JetBrains.Application.Progress.ProcessCancelledException . Check which excceptions you see for your process and check the stack where the exceptions are raised.

Answer 2

Exceptions that are thrown are first chance exceptions. Since your program does not crash, this means they are caught and handled.

In addition to @magicandre1981's approach , I see two other options:

ProcDump

ProcDump can create crash dumps on first chance exceptions with the -e 1 command line switch. Also define -n to specify the maximum number of dumps you want to take. Once you became aware of an exception and no longer want it to be reported, use -f to filter it.

Advantage: you do not only have the exception, you also have a call stack and all the heap information which you can analyze later.

Disadvantage: this will significantly slow down your process and take a lot of disk space.

WinDbg exception commands

You could attach WinDbg to a process and use the sxe command with the -c switch to analyze first chance exceptions. Include g in the command to continue execution. It's helpful to write all output into a log file (use .logopen ).

Example:

.symfix
.reload
.logopen c:\debug\logs\firstchance.log
.loadby sos clr
ld * 
sxe -c "!pe;!clrstack;g" clr
g

.symfix and .reload may not be necessary. Just make sure your symbols are correct , otherwise all the analysis may be useless. The ld * will just pre-load things to make the analysis faster later on.

Advantage: you can capture as many information as you want without creating huge crash dumps.

Disadvantage: The execution of commands may significantly slow down the process. WinDbg may become unstable when you do this with hundreds of exceptions. (I never did this for a long time, this warning is given based on my experience with WinDbg 6.12 somewhen in 2010)