I’m debugging a case where it appears a scsi miniport driver during a crashdump is hanging. If I enable debugging on the system it just reboots after the original crash - in this case it is induced - and i’d like to see why the miniport appears stuck dumping to the crashdump.dmp file. I’m able to determine/guess that the miniport is hung through logs to the hypervisor.
Any ideas how this achieved?
Thanks,
G
You can debug it by entering hibernation. You need to use breakpoints on FindAdapter. You will not be able to break on runtime. You can also print debug messages from it. Use serial port connection for the debugger.
You can set a breakpoint in the crashdump version of the driver using its
crashdump name, the “dump_*” name for the port and miniport drivers.
Mark Roddy
On Wed, Dec 17, 2014 at 5:08 PM, wrote:
>
> I’m debugging a case where it appears a scsi miniport driver during a
> crashdump is hanging. If I enable debugging on the system it just reboots
> after the original crash - in this case it is induced - and i’d like to see
> why the miniport appears stuck dumping to the crashdump.dmp file. I’m able
> to determine/guess that the miniport is hung through logs to the hypervisor.
>
> Any ideas how this achieved?
>
> Thanks,
> G
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
so you’d basically do something like:
bp dump_drvr!entry
.crash
??
I’m not seeing a break at this point. Is this the correct process?
Greg
Do you manage to set the break point successfully?
Show us the exactly WinDbg command and output, please (yes, you can obscure your driver name, that’ll be fine).
Peter
OSR
@OSRDrivers
I haven’t done it in a while, but I recall you may have to put a hard breakpoint (DebugBreak()) at the DriverEntry, and only when it’s hit, set your soft breakpoints.
He just needs to use bu instead of bp, as bp will only set a breakpoint if the symbol is already loaded.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Friday, December 19, 2014 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] debugging the crashdump handling path
I haven’t done it in a while, but I recall you may have to put a hard breakpoint (DebugBreak()) at the DriverEntry, and only when it’s hit, set your soft breakpoints.
Crashdump initialization doesn’t trigger module load event in the debugger to allow it to set the breakpoints. The crash driver is preloaded.
> Crashdump initialization doesn’t trigger module load event
It does.
But IIRC DriverEntry (in a special form, with DriverObject == NULL) is only called when the crash occurs.
The crash driver is preloaded.
Yes.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Correct. as in bu dump_mymp!DriverEntry
Mark Roddy
On Fri, Dec 19, 2014 at 11:43 AM, Phil Barila
wrote:
> He just needs to use bu instead of bp, as bp will only set a breakpoint if
> the symbol is already loaded.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
> Sent: Friday, December 19, 2014 9:19 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] debugging the crashdump handling path
>
> I haven’t done it in a while, but I recall you may have to put a hard
> breakpoint (DebugBreak()) at the DriverEntry, and only when it’s hit, set
> your soft breakpoints.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
The I/O Manager checksums the dump images at load time and can skip
generating a crash dump if the checksum doesn’t match at crash time. Because
software breakpoints modify the image, you can end up not having your code
execute at all if you set a breakpoint with bp/bu. I forget which version
this started happening to me on (Server 2003 or 2008?), but it’s really
annoying.
Go the route of having a hard coded breakpoint (__debugbreak()) in your
DriverEntry or FindAdapter. Once you hit that breakpoint you can set all the
software breakpoints you want because you have already passed the checksum
validation.
One other tip: beware setting breakpoints in the GUI as the debugger will
often end up setting breakpoints in your normal driver image instead of the
dump version. You can mitigate some of this by unloading your original
driver from the debugger’s loaded module list (.reload /u foo.sys), though I
always verify that my breakpoints are in the right module with bl before
hitting GO.
-scott
OSR
@OSRDrivers
OP,
bu always has always worked for me although I did notice .crash would skip breakpoint that otherwise would hit. I have not pursued why “.crash” would do that.
Instead, I use one of the following ways to generate a crash:
Good luck,
Calvin