MiniDumpWriteDump Error Code 0xD000000D

[Paul Arnold]

An application that I am working on uses the MiniDumpWriteDump function

from dbghelp.dll to create a process dump in the event of an unhandled
exception.


In the vast majority of cases the call to MiniDumpWriteDump succeeds.
However, occasionally a call to MiniDumpWriteDump returns an error
HRESULT of 0xD000000D as returned by calling GetLastError.


The top 4 bits (0xD, 1101) indicate this is an error (bits 31 and 30).
Bit 28 is also set which is reserved according to the Winerror.h in the

Platform SDK include files. If I make an assumption that the error
code is a Windows error then this corresponds to ERROR_INVALID_DATA.


I have a few questions:


1) Anyone know what bit 28 is being used for in this context?
2) Does anyone know if my interpretation of this error code is correct?

3) Finally, does anyone know what circumstances could cause the
function to fail this way?

Thanks in advance
Paul

[Drew Bliss [MSFT]]

Bit 28 is FACILITY_NT_BIT, as given in winerror.h. This code is an NTSTATUS
value wrapped up as an HRESULT. The code is an invalid-parameter error.
It's most likely not an invalid parameter to MDWD itself, it's most likely a
failure from an OS call that MDWD is making. Given your description of the
problem it sounds like some kind of timing problem, perhaps a thread exiting
before MDWD can query it, thus resulting in invalid-parameter failures for
an OS query. It could also be a garden-variety privilege failure, as some
routines return invalid-parameter for that situation.

It's impossible to narrow down without knowing exactly what's failing. Are
you using the 6.5.3.8 dbghelp? If not, update to that. Once you have
6.5.3.8, can you use the debugger's .dump command to capture dump files in
the same scenario? The debugger will show more information about any
internal failures. If you can run your program under a debugger you can
also try and catch the errors in your program by looking for calls to
dbghelp!NullStatusProvider::Status.

Post by Paul Arnold
An application that I am working on uses the MiniDumpWriteDump function
from dbghelp.dll to create a process dump in the event of an unhandled
exception.
In the vast majority of cases the call to MiniDumpWriteDump succeeds.
However, occasionally a call to MiniDumpWriteDump returns an error
HRESULT of 0xD000000D as returned by calling GetLastError.
The top 4 bits (0xD, 1101) indicate this is an error (bits 31 and 30).
Bit 28 is also set which is reserved according to the Winerror.h in the
Platform SDK include files. If I make an assumption that the error
code is a Windows error then this corresponds to ERROR_INVALID_DATA.
1) Anyone know what bit 28 is being used for in this context?
2) Does anyone know if my interpretation of this error code is correct?
3) Finally, does anyone know what circumstances could cause the
function to fail this way?
Thanks in advance
Paul

[Paul Arnold]

Hi Drew,

Thank you for your reply. It would appear that we are running an older
version of the dbghelp library so we will deploy a newer version and
see how it goes.

I don't think I am looking at a privilege issue because the same
handler runs successfully the vast majority of times. It is certainly
possible that a thread could occasionally be in the process of exiting.
If this as you suggest could cause problems with MDWD I'm not sure
what approach I could take to try to avoid this (suggestions welcome).

Due to the circumstances under which the problem happens; that is
(rarely and unpredictably) in the implementation of our Un-handled
Exception Handler on live systems. I don't think it will be possible
to compare the behaviour of the .dump command should the problem happen
again. On systems where we do run under the debugger (e.g. some test
scenarios) we usually debug the issue directly there and then.

I have seen occasional problems where running .dump with /ma is
unsuccessful and it is possible to run .dump with fewer options
selected (usually it is the full heap dump that doesn't work if this
happens). Under these circumstances I usually assume some form of heap
corruption and look for bugs using app verifier.

Thanks again for your reply.
Regards
Paul

[Drew Bliss [MSFT]]

If it's a thread timing issue you could try calling MDWD multiple times, as
it's unlikely that it would persist over two or three failures. However,
newer MDWD implementations have direct support for keeping around error
placeholder threads in this situation, so it's possible that the latest MDWD
will resolve your issue.

As for the full dump failure, capturing a full dump requires that the target
process's VM not change during the full dump. This is easily broken if
somebody injects threads into the process or performs some other
modification. The only option is to retry. Again, the latest MDWD has an
auto-retry loop in it.

Another possible failure for full dumps is if existing memory can no longer
be read, such as a file mapping based on a network file which is no longer
reachable. There is no way to get a valid full dump in that situation as
the debugger cannot retrieve full memory content, thus you have to fall back
on less-than-a-full-dump.

Post by Paul Arnold
Hi Drew,
Thank you for your reply. It would appear that we are running an older
version of the dbghelp library so we will deploy a newer version and
see how it goes.
I don't think I am looking at a privilege issue because the same
handler runs successfully the vast majority of times. It is certainly
possible that a thread could occasionally be in the process of exiting.
If this as you suggest could cause problems with MDWD I'm not sure
what approach I could take to try to avoid this (suggestions welcome).
Due to the circumstances under which the problem happens; that is
(rarely and unpredictably) in the implementation of our Un-handled
Exception Handler on live systems. I don't think it will be possible
to compare the behaviour of the .dump command should the problem happen
again. On systems where we do run under the debugger (e.g. some test
scenarios) we usually debug the issue directly there and then.
I have seen occasional problems where running .dump with /ma is
unsuccessful and it is possible to run .dump with fewer options
selected (usually it is the full heap dump that doesn't work if this
happens). Under these circumstances I usually assume some form of heap
corruption and look for bugs using app verifier.
Thanks again for your reply.
Regards
Paul

[Paul Arnold]

Hi Drew,

Thanks again for your time, I am going to try the latest version of
dbghlp before anything else. If the issue remains then I'll be sure to
try out your suggestions.

Regards
Paul