Thanks, I already found it creates WER report. Unfortunately, I can see
it at my machine on App Verifier failure (which also doesn’t create a
UMDF dump) but not on the DTM machine. At my machine I can see reports
at Users\All Users\Microsoft\Windows\WER\ReportQueue. I don’t know how
WER exactly works – are these records deleted when (if) posted to MS?
I can see these crashes logged in Event Log (events 10110 and 10111). As
I looked, once it is written to Event Log, WER report should be created
afterwards but there is none. It is pretty frustrating…
LogMinidumpType is set to 0x1120 at my machine. And it creates dump when
I caused crash (dereferencing NULL) inside the driver.
I already managed to configure ETW to generate info (LogLevel to 255)
but unfortunately, the log is deleted on machine restart (which is
favorite DTM entertainment). The log is copied to WER report so having
it would be probably quite sufficient to find a problem.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Tuesday, July 28, 2009 12:19 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UMDF driver crash dumps
If UMDF creates the dump it will be in that location.
There’s a registry key which can control the flags we pass to
create the minidump when we detect the host process crashing
(look for LogMinidumpType under
HKLM\software\microsoft\windows nt\currentversion\wudf - if
not set the default is to create a dump).
UMDF registers an unhandled exception handler to dump on
exceptions, and it manually triggers a dump on any sort of
verifier failure. However a problem like a major stack
corruption or a thread calling TerminateProcess won’t result
in a UMDF created dump. You could check the general WER
reporting queue to see if WER has any failures of
wudfhost.exe. You can also check the UMDF log file in that
same logs directory (TMF file in the WDK - run “sc control
wudfsvc 234” first to shut down the driver manager and flush
the log) to see if they mention where the host went, but that
would probably only be useful if you can stop near the point
of failure.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, July 24, 2009 9:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UMDF driver crash dumps
OK, I’ll try JIT approach if UMDF one fails. Still I hope
there is a simple way how to make it working, maybe there is
only a bug in docs and dumps are somewhere else.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
> Sent: Friday, July 24, 2009 6:39 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] UMDF driver crash dumps
>
> Assuming that you have already verified that your code runs
> pageheap-clean locally.
>
> The JIT debugger doesn’t need to be something that works
> interactively. It’s quite possible to use the debugger to
just write
> a full dump out and quit on exception.
>
> I’ll have to defer on UMDF’s built-in crash capturing logic
as I don’t
> have specific experience with that, however.
>
> - S
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
Michal Vodicka
> Sent: Friday, July 24, 2009 9:29 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] UMDF driver crash dumps
>
> If I can reproduce it locally, I’d try it. But it occurs at
customers’
> machines on the other side of the World. When they’re
running DTM test
> which automatically restart machine many times and takes hours. So
> even if JIT/WER approach works, somebody would have to watch the
> machine and save dump before DTM makes next restart. For the same
> reason I can’t ask them to pre-attach the debugger.
>
> So I believe the crashdump is the best possibility and it seems as
> standard UMDF feature in this scenario. The only problem is
it doesn’t
> seems to work.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
> > Sent: Friday, July 24, 2009 6:22 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] UMDF driver crash dumps
> >
> > Sounds like memory corruption-esque to me, enable page
heap and see
> > if you get something useful out of that.
> >
> > As for crash dumps, I’ve personally never had to debug a UMDF
> > driver. Thus, my recommendations here are standard user mode
> > debugging tips.
> >
> > For user mode apps, you can usually set a JIT debugger with the
> > usual AeDebug key (and could use -server with cdb/ntsd so that it
> > can be remotely controlled).
> >
> > The WER client, if it’s catching the crash, should have a dialog
> > that lets you get to its saved .dmp files when you next
log on as an
> > admin and the queue unspools.
> >
> > If something has a top-level UEF that doesn’t let things
get to the
> > JIT debugger, then you’ll want to pre-attach the debugger ahead of
> > time before the process crashes. (If possible, I’d prefer doing
> > this anyway as it’s less code that must run in a failing
process vs.
> > Launching the JIT debugger.)
> >
> > - S
> >
> > -----Original Message-----
> > From: Michal Vodicka
> > > Sent: Friday, July 24, 2009 09:07
> > > To: Windows System Software Devs Interest List
>
> > > Subject: [ntdev] UMDF driver crash dumps
> > >
> > >
> > > It seems my great UMDF driver crashes occasionally during some DTM
> > > tests when our customers run in on their machines. It is visible
> > from traces
> > > and also from event log, there are reports about host
> process crash.
> > > We can’t reproduce it locally so I can’t connect a
> debugger (even if
> > > I want :). Unfortunately, from traces it seems it crashes
> on random
> > > places; it seems as a crash from different thread or as
> if somebody
> > > killed the process. To make things worse, the framework feature
> > > which tries to restart process 5 times mostly works so it
> is hard to
> > > notice, driver has to crash 5 times in row which seems very
> > > unlikely.
> > >
> > > Host process crashdump analysis would be probably
> sufficient to find
> > > what causes it. According to this page
> > > http://msdn.microsoft.com/en-us/library/bb743209.aspx dumps should
> > > be in the %windir%\system32\LogFiles\WUDF directory.
> > Unfortunately, there is
> > > none, although driver crashed several times during the test.
> > > It occured
> > > at different machines and I always asked for dumps and
> > never got any.
> > >
> > > My question is: where to find the dump or how to enable dump
> > > generation if it is disabled by default? Win7, WDF 1.9.
> > >
> > > Best regards,
> > >
> > > Michal Vodicka
> > > UPEK, Inc.
> > > [xxxxx@upek.com, http://www.upek.com]
> > >
> > > Email secured by Check Point at OSR.COM
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > > http://www.osronline.com/page.cfm?name=ListServer
> > >
> > > Email secured by Check Point at OSR.COM
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > > http://www.osronline.com/page.cfm?name=ListServer
> > >
> >
> > Email secured by Check Point at OSR.COM
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
> > Email secured by Check Point at OSR.COM
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
> Email secured by Check Point at OSR.COM
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>