As I posted recently, I have an UMDF driver which crashes sometimes
during DTM test and I'd need a dump to analyze it. Finally, I was able
to get WER reports in queue. WER was disabled at DTM machine, probably
to make DTM problems easier to debug :-# After enable, reports are
generated and some even contain some data. There are ETL traces from
UMDF but unfortunately, I haven't found anything useful there even when
verbose logging was enabled. It is apparent driver crashed but there is
no apparent reason.
I'd need dumps but WER isn't able to create them. Instead, there is a
small text file named WERXXX.tmp.WERDataCollectionFailure.txt which
always contains following text:
Heap dump generation failed: 0x8007012bMini dump generation failed:
0x8007001f
d:\>err 8007012b
as an HRESULT: Severity: FAILURE (1), Facility: 0x7, Code 0x12b
for hex 0x12b / decimal 299 :
MCIERR_NEW_REQUIRES_ALIAS
mmsystem.h
SQL_299_severity_16 sql_err
The DATEADD function was called with bad type %ls.
ERROR_PARTIAL_COPY
winerror.h
Only part of a ReadProcessMemory or WriteProcessMemory
request was completed.
3 matches found for "8007012b"
The second one is general error and seems as a consequence of the first
one.
Has anybody an idea what can be wrong and how to configure WER to
generate something usable?
I have to say debugging such an UMDF problem is much harder than
debugging kernel mode driver crash. We didn't even notice there is a
problem because of automatic driver restart nature. Which is IMO really
bad idea, mainly during Windows beta testing and at DTM machines. I set
number of restarts to 0 and now the problem is reproducible even
locally. So yes, I can connect kernel debugger and probably will, but
I'd really like to know how to make this extremely unreliable thing
(i.e. WER) working at customers' machines. When UMDF team decided to use
it.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]