I wrote a blog post recently about how Visual Studio can be used to review memory dumps. In my example I introduced the idea of tracking down a Stack Overflow exception from the perspective of property get, however, I imagine most real instances of Stack Overflows occur in faulty method somewhere really deep in the stack.
Traversing the entire Call Stack would be an incredibly expensive process, that is why neither WinDbg nor Visual Studio do this automatically. In fact the Visual Studio Call Stack windows defaults to a maximum 5000 call frames. While WinDbg allows you to move deeper into the call stacks manually.
The problem with investigating a Stack Overflow Exception in Visual Studio is that you blow by that 5000 frames limit really quickly.
Modify the MaxFrames property
Thankfully you can change the viewable frames in the Call Stack window for Visual Studio by editing the package definition. You can find the package here (based on your own install path):
%VSINSTALLPATH%\Common7\IDE\CommonExtensions\Platform\Debugger\VSDebugEng_Impl_Engine.pkgdef
Find the MaxFrames property and note the hexadecimal value defaults 00001388 (which is 5000 in decimal). Change the value to a really high hexadecimal number of your choosing, close all VS instances and run devenv.exe /setup from the VS command line to ensure it gets picked up.
Please note again that Call stack checks are very expensive so after you are done I would recommend resetting the MaxFrames value back to its default.
Comments are closed.