问题
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?
回答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.
回答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)
来源:https://stackoverflow.com/questions/41459241/sos-dll-and-windbg-get-exceptions-thrown