So you’re plugging along in SQL Server Management Studio (SSMS) when it suddenly goes belly up. Now you’re staring at various dialog boxes telling you that SSMS crashed. Usually the first dialog box you get will ask you if you’d like to close OR the program. If you choose to close the program, you’ll be presented with the opportunity to recover your lost SQL scripts once you reopen SSMS, as shown above. (Image above courtesy of Aalam Rangi).
But let’s say that closing the program represents a big issue for you due to lost time, productivity, etc. You want to go the other route – you want to DEBUG! So, what’s the easiest way to get a crash dump or to debug SSMS from this state?
In my personal experience, the natural choice and the only choice I’m ever presented is to debug in Visual Studio. But I’m not really a Visual Studio guy. And I find that those times I’ve attempted to follow the debug route have left me with very little useful information.
But it turns out that, with a little earlier preparation, you can get a postmortem crash dump using a very nicely detailed set of steps detailed at at http://www.codeproject.com/KB/debug/automemorydump.aspx. In a nutshell, you’ll use the Microsoft debugger WinDBG and, along with a few setting changes, configure your workstation to automatically take a memory dump when SSMS crashes.
Once you’ve got your workstation set up to automatically grab a memory dump upon a crash, you have to interpret the results. I’m not going to duplicate excellent guidance provided by Microsoft at the CSS SQL Server Engineering Blog. So be sure to give that post a read to flesh out your understanding of taking and reading memory dumps.
Equipped with this information and a few steps of preparatory work, and you’re now ready to conquer SQL Server memory dumps!
Have you every had a crash in SSMS? How did you troubleshoot and resolve the problem? Let me know what you think.