0

One of the drivers I'm developing has caused a BSOD. Unfortunately a dump file was not created since it was not configured / low resources. I was trying to reproduce this crash but no luck so far.

Is there any way to get some info using WinDbg or any other tool? I have this information:

  • A screenshot of the BSOD
  • The .sys file.
  • Its pdb
  • The source code
  • The machine it was crashed on

I have everything except the dump itself.

Your help will be much appreciated.

As I said above, no dump (/minidump) exists. This is the actual problem.

For this specific crash, I know I won't be able to get the stack. Just getting the specific line of code will be good enough. Because the BSOD contains the module's address, it seems like there should be a way to detect which line exactly is it. As I mentioned above, I do have the .sys file, the pdb and the source code.

This is the specific code taken from MSDN: SYSTEM_SERVICE_EXCEPTION. How can I know from there what was the specific line? and/or the specific exception raised?

ThiefMaster
  • 310,957
  • 84
  • 592
  • 636
eeoo2555
  • 3
  • 1
  • As I understand you got SYSTEM_SERVICE_EXCEPTION. Parameters 2 and 3 of this exception will give you more info line, function, address which caused this. Moreover this seems indirect crash (some system service crash), so will need memory dump to analyse such issue. – Rohan Jul 02 '12 at 09:15
  • You mentioned parameters 2 and 3 will give me info line, function, address. That's exactly my question - how can I use it? – eeoo2555 Jul 02 '12 at 09:18
  • Those are __memory address__ for exception record and context record. So you will need dump to make use of them. Also, that is not actually function address/line number but pointer to some record/info which may have the info. BTW, on BSOD screen you will never get source code line where its crashed. – Rohan Jul 02 '12 at 09:29
  • (Previous comment): Thanks, as I said above, no dump (/minidump) exists. This is the actual problem. For this specific crash, just getting the specific line of code will be good enough (no stack trace). Because the BSOD contains the module's address, it seems like there is a way to detect which line exactly is it. I do have the .sys file, the pdb and the source code. The error code: [SYSTEM_SERVICE_EXCEPTION](http://msdn.microsoft.com/en-us/library/windows/hardware/ff558949(v=vs.85).aspx). How can I know from there what was the specific line? and/or the specific exception raised? – eeoo2555 Jul 02 '12 at 09:30
  • Rohan, thanks once again. I just taught there might be a way getting the module's address offset where the crash happened and get it from there. But I guess it is not possible. Is it possible to know what was "the exception that caused the bug" (MSDN)? Mine was **0x00000000C0000005** – eeoo2555 Jul 02 '12 at 09:39
  • 1
    __0x00000000C0000005__ is the exception, indicating some invalid memory read/write. – Rohan Jul 02 '12 at 09:57

2 Answers2

1

You have the crash address, want to know the source line?

Fire up kd or windbg, disasm that address and code before it. Find the function entry point (where it adjust the stack) and you can now lookup the symbol table. From there you disasm again and compare the source.

Sorry, I guess you need to read some asm. I know no better way.

J-16 SDiZ
  • 26,473
  • 4
  • 65
  • 84
  • It is a good idea. Your compiler might also have options to produce an assembly file (text file) with source code as comments interleaved with the assembly it produced. Searching for raw instructions bytes in the text brough will bring only a few matches, and from the context of the crash you will be able to locate the source line. – ixe013 Jul 03 '12 at 03:22
  • Thank you both for the answers. This is actually what I did eventually: Opened the .sys file as crash dump in WinDbg and used **"u !my_driver+offset"**. This gave me the exact assembly that crash. Looking at the disassembly window provided me the full picture of the code which lead me to find the exact line in source code. Thanks. – eeoo2555 Jul 03 '12 at 05:47
0

If you are lucky you will have minidump in C:\windows, so check if its there. If its available open it in Windbg and analyse. You don't need to configure for low resource to create dump, refer this link http://support.microsoft.com/kb/254649 on how to setup windows to create dump files. Create full dump if you want to debug your driver.

Coming back to your question to analyse issue:

But its not likely that you will reach to good conclusion with information you have. You will need dump file to really understand the issue.

Rohan
  • 52,392
  • 12
  • 90
  • 87