I don’t really know about your first question. Everytime I’ve card to
dump the driver object, then my driver was on the stack & I could ge the
device object from the parameters my driver was called with & from there
get the driver object.
As to your second question that is easy. WinDbg has historicly been
very unstable and so it really isn’t something with your setup. Because
of this (and other) issues we have been working all this year on a new
Windbg that has been completely re-writen. You can download version 1
of this new Windbg at http://www.microsoft.com/ddk/debugging
http:
It now uses the same backend as kd.exe, so the commads are now KD
commands. The package includes much improved documention. It also
includes an SDK that allows you to write new powerful extenstions that
can do anything the debugger can do. It also has a built in remoting
support to connect 2 debugger together over a network.
Enjoy.
-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Thursday, November 09, 2000 12:30 PM
To: NT Developers Interest List
Subject: [ntdev] There’s got to be an easy way to do this… getting
_DRIVER_OBJE CTs from a crash dump using WinDbg
I wasting a lot of time trying to get the _DRIVER_OBJECT that
were in memory at the time of a system crash using WinDbg (analyzing a
crash dump file). The !drivers command lists some information, but I’m
trying to get my actual _DRIVER_OBJECT as it existed at the time of the
crash. Can someone explain how I should go about doing this?
Also, the version of WinDbg (version 5.0 build 2195) crashes
quite often. Is this normal or is it more likely there is some sort of
environmental thing with my system that is causing WindDbg to be
unstable?
Thanks,
Joel</http:>