It’s hard to say for sure without seeing a live repro, but I don’t
believe you are actually having a dump failure. When a non-mini dump
type is generated the system creates a minidump on the next boot by
conversion. The Windows XP conversion code did not preserve secondary
data. This has been fixed in newer OS versions.
From: xxxxx@comcast.net
[mailto:xxxxx@comcast.net]
Sent: Thursday, April 13, 2006 12:24 PM
To: Kernel Debugging Interest List; Kernel Debugging Interest List
Cc: Drew Bliss
Subject: RE: [windbg] Generating secondary dump data
Thanks much, Drew! Your question did get me going in the right
direction.
A few weeks back I switched my system to generate kernel memory dump and
I am assuming, because of resource constraint it was anyway generating
minidumps. I figured, I would leave the setting as is so that it would
generate kernel memory dump if it could but if it couldn’t I would at
least get a minidump. It turns out, in situations where it couldn’t
generate kernel memory dump, even if it can afford the space for
secondary dump data, atapi (or which ever component is responsible for
this) does not include the secondary dump data while choosing to go with
minidump. Once I switched back to minidump, secondary dump data was
written to disk successfully!
A couple of suggestions, if I may - 1) The code that falls back on
minidump in situations like the one described above should try to
accomodate secondary dump data if possible. 2) While I understand that
this is not a place for extensive error handling, a call to
InbvDisplayString to display a line about failure to persist secondary
dump data (in blue screen) would have saved hours of stepping into
kernel.
Thanks again for your help,
Kamala
-------------- Original message --------------
From: “Drew Bliss”
What kind of dump is your system set to generate? If it isn’t
set for a minidump, do things work when you do set it to generate a
minidump?
From: xxxxx@comcast.net
[mailto:xxxxx@comcast.net]
Sent: Thursday, April 13, 2006 10:10 AM
To: Kernel Debugging Interest List; Kernel Debugging Interest
List
Cc: Drew Bliss
Subject: RE: [windbg] Generating secondary dump data
I am using Windows XP SP2.
From the documentation I gather I need XP SP1 or above. So, I
made sure I have the right OS.
Thanks,
Kamala
-------------- Original message --------------
From: “Drew Bliss”
That all sounds fine. What OS are you working with?
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@comcast.net
Sent: Thursday, April 13, 2006 7:30 AM
To: Kernel Debugging Interest List
Subject: [windbg] Generating secondary dump data
Folks,
I am attempting to add secondary dump data to crash
dumps using KeRegisterBugCheckReasonCallback/
BugCheckSecondaryDumpDataCallback with no success so far. I am getting
the bugcheck callbacks twice as expected. I have also stepped into the
kernel and verified that IopInvokeSecondaryDumpDataCallbacks was calling
IopWriteToDisk as expected and IopWriteToDisk was returning
STATUS_SUCCESS. I also stepped into the atapi driver calls and verified
that atapi is calling hal’s WRITE_PORT_* routine to write the buffer (I
am attempting to write to crash dump) to port fe00. However, when I
open t he cr a sh dump file in WinDbg and run .enumtag command, I get
the following error -
“Unable to start enumeration, HRESULT 0x80004002”
When I open the crash dump in a hex editor, “TRGD” is at
the tail end. If I compare that with a crash dump that contains
secondary dump data, I see “DumpBlob” following “TRGD”. This proves
that my secondary dump data was never persisted to disk. Am I missing
something obvious?
Thanks,
Kamala
—
You are currently subscribed to windbg as:
xxxxx@winse.microsoft.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown
lmsubst tag argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com