Photograph: SQL Server Crash Dump Analysis
We can think about a process memory dump as a photograph of the process memory at a given point in time – usually when something very wrong has happened. They can be used to perform post-mortem debugging to get the exact details on the nature of the problem and avoid them in the future. They are really important, but often overlooked, so this session will try to shed a little bit of light on crash dump analysis and postmortem debugging.
A brief introduction to WinDbg and adplus.vbs, as well as general postmortem debugging, will lead to a series of examples where we will be able to determine the root cause of some SQL Server crashes (such as data corruption on a DBCC CHECKDB process) and SQL Server stability problems (such as the typical 17883 errors).
A discussion on how to debug common, but tricky, development problems will follow, with examples of debugging .NET applications failing to dispose the connections to the database properly, as well as other kind of database-related problems.
This session will be valuable both for DBAs who want to understand why their SQL Server instance - or cluster resource, etc - is crashing unexpectedly as well as for developers, who will add a new tool and skill set to improve their troubleshooting skills.
Speaker focus
I've been 'playing' with computers since I was a kid, so I've got a lot of background here: I've worked as a freelance, for my university, in several research projects, etc. Then I had the chance of join Microsoft's Premier GTSC, as SQL Server Support Engineer, where I learned to love SQL Server and a little tool called WinDbg ;)
Afterwards I joined Plain Concepts, where I served as Development Advisor and, currently, as the Team Lead of the Debugging & Optimization Team, where I'm happy hunting bugs, underperformant applications and performing post-mortem analysis of applications. Sounds cool, doesn't it? ;)