I’m looking at a crash dump. The location of the crash (an access violation) is where the driver is looking at the driver object’s device object’s device extension.
I’d like to examine these objects, but I can’t find a way (after an hour of internet searching) to simply find them. I did use winobj to find the name I gave to the device object, but !devobj failed (Unable to get value of ObpRootDirectoryObject).
I’m in DriverUnload. Can I find the address of the driver object that it was called with?
Now I did finally find my Driver Object address as a parameter to the call to DriverUnload.
But I’m looking for the magic command that will display a device or driver object when all I know about my driver is the name “mydriver” from the file “mydriver.sys”. Or even a command that will list all driver objects.
I couldn’t get these commands to work with a crash dump files. I got errors trying to read IopRootDeviceNode and ObpRootDirectoryObject. Is that supposed to happen or do I need a full crash dump instead of a minidump, or what?
Interesting… I’ve been opening the crash dump files in the Windows\Minidump folder. But I tried opening Windows\MEMORY.DMP instead, then these commands worked fine. HOWEVER, my driver did not show up under the !devnode tree, as it also does not show up in the Device Manager application.
What I do know about my driver is:
Driver file name, ibsops.sys.
The names of devices it creates, \driver\devibsopsdriver-0, etc.
The symlinks it creates, \?\slIbsOpsDriver-0, etc.
The driver and its devices are not installed in the device tree, rather the driver is loaded on demand by the user opening a File to it.
So I still want to know how to find my driver object and/or device objects from the crash dump.
And what’s this about the crash dump appearing in two different places, with two different sizes, dated about 4 minutes apart?
Interesting… I’ve been opening the crash dump files in the Windows\Minidump folder. But I tried opening Windows\MEMORY.DMP instead, then these commands worked fine.
…
And what’s this about the crash dump appearing in two different places, with two different sizes, dated about 4 minutes apart?
Every crash gets a minidump, whether you have dumps enabled or not,
written at the time of the crash. It includes only minimal information
for describing the crash. If you have full or full kernel dump enabled,
the much larger MEMORY.DMP file gets copied (as I understand it) from
the page file during the next boot.
@Tim_Roberts said:
Every crash gets a minidump, whether you have dumps enabled or not,
written at the time of the crash. It includes only minimal information
for describing the crash. If you have full or full kernel dump enabled,
the much larger MEMORY.DMP file gets copied (as I understand it) from
the page file during the next boot.
Indeed. As further evidence of this, if I try to open the minidump in windbg in the first few minutes after reboot, it gives me an error. So what I do is go into File Explorer and make a copy of the minidump file. It says the file is locked by Wer-something.exe. I wait until this message goes away and the file copy occurs. Then I can open it in windbg without error. That is, except for stuff that is missing as I have reported before.
Opening MEMORY.DMP does give me my device and driver objects as long as I know their names. !drvobj \driver\ibsops and !devobj \device\devibsopsdriver-0 work for my case. Also !object with either of these names. If I forgot the device name, I can look at the device objects enumerated under the driver object, and the driver object’s name comes from the base name of the driver file (i.e., ibsops.sys).
FYI: I found the sym link for the device with !object \GLOBAL??\slibsopsdriver-0. It gives me the target string (\Device\devibsopsdriver-0). If I don’t know the link name, then I can look at !object \GLOBAL?? and look for it. Any command that will find symbolic links for a given target object name?