In Recovery...

I just had to figure out how to do this so I figured a quick blog post is in order to save other people time in future.

If you ever need to use windbg to debug a SQL Server crash dump, or you want to capture call stacks using extended events (e.g. when debugging excessive spinlock contention), you’ll need the correct symbol file (sqlservr.pdb) to go with sqlservr.exe of the instance you’re interested in.

[Edit: May 2016] Download and install the Windows debugging tools from the Windows SDK here. This works on Windows Vista through 10 and Windows Server through 2016.

Now you’ll have a tool called symchk in the folder where windbg resides (for my laptop, “C:\Program Files (x86)\Windows Kits\10\Debuggers\x64”) – this is what will pull down sqlservr.pdb.

You need to point symchk at the executable you’re interested in, tell it where to put the sqlservr.pdb, and tell it the location of the Microsoft symbol server.

Then go to the c:\symbols directory, and find the directory called sqlservr.pdb. It will have one or more sub-directories with GUID names, so pick the one with today’s date and then copy the sqlservr.pdb from that directory into the \Binn directory.

Again, the command string to use once you’re in the SQL Server Binn directory is:

If you get an error “The filename, directory name, or volume label syntax is incorrect.”, the copy-paste inserted weird characters for the double-quotes so delete and reinsert them. Also make sure there’s a space between /s and SRV.

You’ll also need to do this for sqlos.dll, plus on SQL Server 2012+ you’ll need to do it for sqlmin.dll, sqldk.dll, sqllang.dll, sqlboot.dll, and on SQL Server 2014+ you’ll need to do qds.dll and sqltses.dll too otherwise call stacks won’t resolve properly. I usually just replace sqlservr.exe in the command above with *.dll and then I’ve got all the symbol files possible, but you can save time by only doing it for the strictly necessary files.

When you get to the analysis phase, if you don’t have all the correct symbols, your call stack will look something like this (an example where sqlmin.pdb and sqllang.pdb are missing:

I started using WinDbg for the first time ever this week and I stumbled upon this blog post.

I’m having trouble hammering my system to create a spinlock so that I get an extended event, so I can’t prove this myself, but if you were to set _NT_SYMBOL_PATH to symsrv*symsrv.dll*c:symbols2*http://msdl.microsoft.com/download/symbols for the sql server process, would sql server be able to use the pdb files in the symbol server cache as opposed to the directory itself to resolve the stack trace for extended events?

Even just having SQL Server sitting doing nothing, it’s taking spinlocks in the background. What event are you trying to hit? Check out my spinlocks category where I show how to catch SOS_SCHEDULER_YIELD in XEvents.

I have worked though a dozen or so posts relating to sqlservr.pdb availability for SQL 2008 R2 SP2 and SP3. I have been unable to download the sysmbolf files for for SQL 2008 R2 SP1. Can you provide any guidance? I always get the message

I did this but I am not getting all the correct symbol files. I did sqlos.dll, *.dll, sqlservr.exe and this is the result I get for IO_COMPLETION. I am really frustrated trying to figure what is causing this wait. What am I missing?