Recently I was debugging some workflow where it appeared quite slow. As part of debugging i saw it Visual Studio printed debugging information about first chance exceptions thrown.
Now that David Kline from MS has made it ample clear that FirstChance exceptions are normal exceptions just that debugger gets first chance at them- thus first chance. If debugger chooses not to do anything then application gets a chance to do something about it. If application does not handle it then debugger gets a second chance, thus second chance exceptions. you get the idea.
Now an application can throw as many exceptions it wants and catch it later. This is fine but exceptions are supposed to exceptional and cost quite a bit. (link1 & link2)
I have seen lexical_cast being the one that throws exceptions just to parse strings, with xml parsing this could be a big source of exceptions. One of the ways to speed up applications is now to fix or atleast reason about these exceptions being thrown, and having tracebacks makes life lot easier.
To generate tracebacks is you could use Vectored Exception Handling or windbg. Off course I chose windbg so I set out to generate tracebacks.
In my case I recorded 168K+ exceptions thrown out of which I believe ~165K could be filtered.
Anyway, as usual I started windbg with a log file option, as traces could get really large and I did not want to lose any.
windbg -pn testapp.exe -loga d:\tracebacks.txt
Once I had application running, next I ensured that I am listening to correct exception code. In my case it is C++ exception with code e06d7363, some details here and here.
(3770.35a0): Break instruction exception - code 80000003 (first chance)
ntdll!DbgBreakPoint:
00000000`779aafb0 cc int 3
0:008> g
ModLoad: 000007fe`dcb10000 000007fe`dcb17000 C:\windows\system32\SHFolder.dll
;
;
(3770.378c): C++ EH exception - code e06d7363 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
KERNELBASE!RaiseException+0x39:
000007fe`fd70a06d 4881c4c8000000 add rsp,0C8h
;
0:000> sxe -c "k;g;" e06d7363
0:000> g
(3770.378c): C++ EH exception - code e06d7363 (first chance)
# Child-SP RetAddr Call Site
00 00000000`0022cd80 000007fe`f65a4572 KERNELBASE!RaiseException+0x39
Here I am asking windbg to break whenever a C++ exception is thrown. At line#14 command is sxe -c "k;g;" e06d7363.
Which configures Exceptions and Events in windbg, see sxe for details.
The idea is to configure exceptions such that we break on error e06d7363 but execute command k;g;- print traceback in that particular thread, k, and continue g
That’s it. At the end of workflow I had traces for all 168K exceptions with a text file container ~500MB of tracebacks to dig thru.