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?
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.
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 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.
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)
