will BugCheckDumpIoCallback work if the dump device is unavailable?

NTDEV
1

The description I have read of the BugCheckDumpIoCallback routine is
that it gets called every time the dump information is written. What
happens if the write fails (eg in my case because the xen comms channel
that would support the dump device isn’t running yet during hibernate
resume)? Is there a way for me to say “don’t write to the dump device at
all, just call BugCheckDumpIoCallback”?

I can probably work around it by having the dump device driver fake it
if it knows that it’s not set up yet and just tell windows that the
write succeeded when really it didn’t, but that assumes that the crash
dump process is write-only, and I don’t know for sure if it is.

Thanks

James

2

As far as I can tell, unfortunately no. This would be a quite useful
feature for reliable dumps on unusual platforms, but there is no way
to say ‘don’t actually do the write’.

Mark Roddy

On Wed, Aug 19, 2009 at 3:52 AM, James
Harper wrote:
> The description I have read of the BugCheckDumpIoCallback routine is
> that it gets called every time the dump information is written. What
> happens if the write fails (eg in my case because the xen comms channel
> that would support the dump device isn’t running yet during hibernate
> resume)? Is there a way for me to say “don’t write to the dump device at
> all, just call BugCheckDumpIoCallback”?
>
> I can probably work around it by having the dump device driver fake it
> if it knows that it’s not set up yet and just tell windows that the
> write succeeded when really it didn’t, but that assumes that the crash
> dump process is write-only, and I don’t know for sure if it is.
>
> Thanks
>
> James
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

3

That’s what I can report as well, unfortunately.

mm