BugCheckCallback calling before getting BSOD memory dump file

Hello everyone,

My driver calls KeRegisterBugCheckCallback and BugCheckCallback functions when Windows thrown the BSOD but also Windows generating memory dump before executing BugCheckCallback function body.

So my question is, how can I call BugCheckCallback function body before generating memory dump file?

Cheers

Excerpt from MSDN:

“… Use KeRegisterBugCheckReasonCallback to register a BugCheckDumpIoCallback routine. …”

“… The main purpose of a BugCheckDumpIoCallback routine is to allow system crash dump data to be written to devices other than the disk. For example, a device that monitors system state can use the callback to report that the system has issued a bug check, and to provide a crash dump for analysis. …”

Best,
Z

What underlying problem are you trying to solve that requires this?

  • S (Msft)

From: xxxxx@gmail.com
Sent: ?Friday?, ?March? ?29?, ?2013 ?4?:?33? ?AM
To: Windows System Software Devs Interest List

Hello everyone,

My driver calls KeRegisterBugCheckCallback and BugCheckCallback functions when Windows thrown the BSOD but also Windows generating memory dump before executing BugCheckCallback function body.

So my question is, how can I call BugCheckCallback function body before generating memory dump file?

Cheers


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Hi folks,

@Vijay
Thanks for suggestion Vijay, I missed that I’ll try next weekday.

@Ken,

When my driver catch bsod with BugCheckCallback firstly generate memory dump than after executes BugCheckCallback body. However, BugCheckCallback function body has another call via ioctl and that ioctl functions generates some messages for another OS. Memory dump file creation takes aprox. 20sec (hardware limitations) also message creation rases after 20sec later. For this reson I want to execute function body than after create memory dump file.

Btw, my windows driver knowledge is premature as you will guess :slight_smile:

Cheers

Why do you think that you need to be called first?

  • S (Msft)

From: xxxxx@gmail.com
Sent: ?Friday?, ?March? ?29?, ?2013 ?10?:?33? ?AM
To: Windows System Software Devs Interest List

Hi folks,

@Vijay
Thanks for suggestion Vijay, I missed that I’ll try next weekday.

@Ken,

When my driver catch bsod with BugCheckCallback firstly generate memory dump than after executes BugCheckCallback body. However, BugCheckCallback function body has another call via ioctl and that ioctl functions generates some messages for another OS. Memory dump file creation takes aprox. 20sec (hardware limitations) also message creation rases after 20sec later. For this reson I want to execute function body than after create memory dump file.

Btw, my windows driver knowledge is premature as you will guess :slight_smile:

Cheers


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

> Hello everyone,

My driver calls KeRegisterBugCheckCallback and BugCheckCallback functions
when Windows thrown the BSOD but also Windows generating memory
dump before executing BugCheckCallback function body.

So my question is, how can I call BugCheckCallback function body before
generating memory dump file?

KeRegisterBugCheckReasonCallback(KbCallbackDumpIo) will allow you to be called as Windows prepares to write the dump file. Just do what you need to do the first time your BugCheckDumpIoCallback is called then set a flag so you know it’s been done already.

Also, if your driver is a storage driver you can detect that a bug check has happened by first checking to see if the arguments to DriverEntry are NULL, and then by calling AuxKlibGetBugCheckData to see if a bug code has been set to tell if you are in hiber mode instead of dump. That may not be 100% reliable though as AuxKlibGetBugCheckData returns STATUS_SUCCESS even if a crash hasn’t occurred, and a bug check code of 0 may theoretically be possible I think. You could also detect IRQL - in my experience dump mode driver entry is called at HIGH_LEVEL while hiber is called at lower IRQL (DISPATCH_LEVEL?), but again that isn’t specifically documented anywhere AFAIK and may change with different versions/hotfixes of Windows. Those theoretical limitations won’t be a problem if you are just doing this for testing but you will want to consider them if this is a release product.

James