Re: question for secondary dump data callback by Kamala
Kamala
Thu Apr 13 15:27:02 CDT 2006
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@online.microsoft.com> wrote in message
> > news:%23DqbceFRGHA.1688@TK2MSFTNGP11.phx.gbl...
> > > How large is your g_CrashLen? My be the system doesn't have enough space
> > to
> > > include your data in the dump file?
> > >
> > > -Eliyas
> > >
> > > "Philip Lukidis" <pleasedontemail@nowehere.net> wrote in message
> > > news:%23zvn3$3QGHA.1096@TK2MSFTNGP11.phx.gbl...
> > > > 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
> > the
> > > > kernel crash dump. I believe that the DDK mentions that my callback
> > > > should
> > > > be called twice: once for buffer length and address acquisition, and
> > then
> > > > again for actually copying the data. My callback code, which was
> > adapted
> > > > from 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
> > does
> > > > 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;
> > > > }
> > > > }
> > > > }
> > > > }
> > > >
> > > >
> > >
> > >
> >
> >
> >