One of my students’ Sql Server 2000 SP4 crashed. I volunteered to see if I could get anything out of it by looking at the dump file with WinDbg.
A few notes:
1. The processor or Windows version that the dump file was created on does not need to match the platform on which WinDbg is being run. However, you do need to provide symbol files that match the Windows edition and version where the dump was from. You can have more than one symbol file path, just separate them by a semicolon.
Since the dump file was generated on Windows 2003 SP2, I downloaded symbol files for it and installed on my Windows XP SP2 laptop. Afterwards, I added it to the symbol path. So my symbols are from 2 sources: Microsoft symbol server and the local symbol I downloaded;
2. I did install Sql Server 2000 SP4 on my laptop to match the Sql Server instance on the server where the dump was from. Afterwards, I added C:\Program Files\Microsoft SQL Server\MSSQL$SQL2K\Binn to the Image File Path
WinDbg points to the direction of:
Not too sure how revealing this is, since we’ve already known it was an access violation. I suppose those kind of information is like bread crumbs that can be helpful to Microsoft support.
1. I thought that I got all the right symbol path, but I still got the message below in the command window, why?
Your debugger is not using the correct symbols
Type referenced: kernel32!pNlsUserInfo
2. It looks like viewing the memory content in the last call can be helpful (Alt + 5). Two questions related to this point:
a. Which display format is useful? To me, part of ASCII and Byte are meaningful to the naked eye.
b. How can I save the memory content in a text file? I can analyze text much faster in VI, but I haven’t found a good way to suck the text out of the memory viewer window?
Got to retire now. I have close to 20 students to teach tomorrow. It was a fun teaching day today.
By the way, X.T.X (谢天笑, 冷血动物), a Shandong boy like me, is not bad.
Any help regarding my WinDbg questions, dear reader?