Re: question for secondary dump data callback
- From: Kamala <Kamala@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 13 Apr 2006 13:27:02 -0700
Thought I would update on the actual cause of failure I encountered -
My machine was setup for kernel memory dump and because of resource
constraint it was falling back on minidump creation and in cases of this
kind, the secondary dump data didn't get preserved. Once I switched back to
mindump in my system settings, I was able to successfully generate secondary
dump data.
Kamala
"Kamala" wrote:
Hi,.
I am battling the same API and encountered the problem(s) you have mentioned
below. From the code snippet you have attached, it looks like you are
providing an output buffer. Is the output buffer you provide
(g_CRASH_STRING) page aligned?
After the first call to your TestBugCheckSecondaryDumpDataCallback method
returns, if you provide an output buffer, that buffer is checked for page
alignment and if that check fails, your TestBugCheckSecondaryDumpDataCallback
will not be called the second time. Though the documentation mentions page
alignment, I felt it could be made a bit more obvious (given that one has to
step into kernel to find such issues).
BTW, I have gone as far as getting the callback twice and I have confirmed
IopWriteToDisk call is made but I still don't see the secondary dump data in
my crash dump file. I was going to continue debugging to figure out the
problem. In the mean time, if someone out there has successfully generated
secondary dump data, any suggestion you have to get further is much
appreciated.
Thanks,
Kamala
"Philip Lukidis" wrote:
Hello Eliyas, sorry for the late reply; I hope you see this.
Actually, the length is quite small, smaller in fact than the system
supplied buffer. Something came up and I had to leave this aside, which
was, after all, only a very contrived test run.
I'll try again without a kernel debugger attached. Perhaps this was the
problem? If you have any other guesses, please reply should you have time.
This would not explain the case of .enumtag failing on the crash dump.
thanks,
Philip Lukidis
"Eliyas Yakub [MSFT]" <eliyasy@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23DqbceFRGHA.1688@xxxxxxxxxxxxxxxxxxxxxxx
How large is your g_CrashLen? My be the system doesn't have enough spaceto
include your data in the dump file?the
-Eliyas
"Philip Lukidis" <pleasedontemail@xxxxxxxxxxxx> wrote in message
news:%23zvn3$3QGHA.1096@xxxxxxxxxxxxxxxxxxxxxxx
Hello. I have problems with my bugcheck secondary callback (WinXP SP2).
My
callback is indeed called, but there are two issues:
a) My callback is called only once, and I cannot see my information in
thenkernel crash dump. I believe that the DDK mentions that my callback
should
be called twice: once for buffer length and address acquisition, and
adaptedagain for actually copying the data. My callback code, which was
doesfrom an archive, is shown below after this letter.
b) In some cases, when I tried the .enumtag command, I got a listing of
information (my GUID was not there). However, sometimes I got the
following
error:
1: kd> .enumtag
Unable to start enumeration, HRESULT 0x80004002 (E_NOINTERFACE, what
it
mean here, and did I cause it?)
Any ideas?
thanks,
Philip Lukidis
bugcheck callback:
// watch out, called at IRQL==HIGH_LEVEL
VOID TestBugCheckSecondaryDumpDataCallback(
IN KBUGCHECK_CALLBACK_REASON Reason,
IN PKBUGCHECK_REASON_CALLBACK_RECORD Record,
IN OUT PVOID ReasonSpecificData,
IN ULONG ReasonSpecificDataLength
)
{
UNREFERENCED_PARAMETER(Reason);
UNREFERENCED_PARAMETER(Record);
PKBUGCHECK_SECONDARY_DUMP_DATA pData;
pData = (PKBUGCHECK_SECONDARY_DUMP_DATA) ReasonSpecificData;
if(pData &&
(ReasonSpecificDataLength==sizeof(KBUGCHECK_SECONDARY_DUMP_DATA)))
{
pData->Guid = TEST_CRASH_GUID;
// this is for acquiring the address and buffer length
if(pData->OutBuffer == NULL)
{
pData->OutBuffer = (PVOID)g_CRASH_STRING;
pData->OutBufferLength = g_CrashLen;
}
// request to copy the data (we never get here, we're called only
once!)
if((pData->InBuffer == pData->OutBuffer) && pData->InBuffer)
{
if(g_CrashLen < pData->OutBufferLength)
{
RtlCopyMemory(pData->OutBuffer,g_CRASH_STRING,g_CrashLen);
pData->OutBufferLength = g_CrashLen;
}
}
}
}
- References:
- Re: question for secondary dump data callback
- From: Kamala
- Re: question for secondary dump data callback
- Prev by Date: WDM or WDF?
- Next by Date: Re: Using compression from kernel mode...
- Previous by thread: Re: question for secondary dump data callback
- Next by thread: USB Clarification
- Index(es):
Relevant Pages
|
