In the last couple of weeks I have seen at least three colleagues ask about capturing memory dumps during stack overflow exceptions so I thought it was a great excuse to write a blog post in the middle of December.
Stack overflow, out of memory and execution engine exceptions are special class of exceptions in that they represent a condition that cannot be handled by user code. In the event of a stack overflow, for example, there is no more stack space to potentially use a “try-catch”. This is similar to the out of memory scenario, you simply do not have memory to handle the problem once detected.
In terms of capture I tend to rely on procdump (you can see several examples here) but in the case of a stack overflow exception the traditional option of –e (for exceptions) does not work in the way you would expect, in most cases you simply do not capture anything.
So here is the first example that I use to capture stack overflows:
procdump -e -f C00000FD.STACK_OVERFLOW -g -ma app.exe
The –f option represents an exception filter for procdump and it will capture a full dump (-ma) for app.exe. The following image represents the output we collect in this scenario.
One of my colleagues on the Azure App services team made me aware that this option may fail on Linux but he had some success by adding more filters (-f E053534F) as follows:
procdump -f E053534F -f C00000FD.STACK_OVERFLOW -ma app.exe
I personally like opening stack overflow dumps in Visual Studio as it is abundantly clear where your recursion is occurring. One weakness in Visual Studio (and WinDbg) is that while debugging a Stack overflow exception you generally blow through the Stack Frame limit. These limits are fairly conservative because traversing the entire call stack can be incredibly expensive. If you need to change the Stack Frame limit in Visual Studio try adjusting the MaxFrames property (always revert it back, it is a very expensive operation).
Comments are closed.