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;
}
}
}
}

Re: question for secondary dump data callback by Eliyas

Eliyas
Fri Mar 10 09:30:56 CST 2006

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;
> }
> }
> }
> }
>
>



Re: question for secondary dump data callback by Philip

Philip
Mon Mar 13 09:34:36 CST 2006

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;
> > }
> > }
> > }
> > }
> >
> >
>
>



Re: question for secondary dump data callback by Kamala

Kamala
Tue Apr 11 13:23:02 CDT 2006

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;
> > > }
> > > }
> > > }
> > > }
> > >
> > >
> >
> >
>
>
>

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;
> > > > }
> > > > }
> > > > }
> > > > }
> > > >
> > > >
> > >
> > >
> >
> >
> >