Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
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.
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!|
|Kernel Debugging||30 January 2023||Live, Online|
|Developing Minifilters||20 March 2023||Live, Online|
|Internals & Software Drivers||17 April 2023||Live, Online|
|Writing WDF Drivers||22 May 2023||Live, Online|
First make sure your symbols are correct:
Then you can do the following to find the driver object:
Output should look something like this:
!devnode 0 1
this lists all the device nodes
you can text search the output
taking the driver scott used
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:
1. Driver file name, ibsops.sys.
2. The names of devices it creates, \driver\devibsopsdriver-0, etc.
3. 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, [email protected]
Providenza & Boekelheide, Inc.
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?
Symbolic links don’t work in that direction, right? The symlink points to the target... and the relationship may be many to one.