Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


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/


How do I find the driver and device objects for my driver (crash dump)?

Michael_RolleMichael_Rolle Member - All Emails Posts: 135

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.

Comments

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,556

    First make sure your symbols are correct:

    .symfix
    .reload
    

    Then you can do the following to find the driver object:

    !drvobj \Driver\mydriver 7`
    

    Output should look something like this:

    1: kd> !drvobj \driver\fvevol 7
    Driver object (ffffdc865fb8adf0) is for:
     \Driver\fvevol
    Driver Extension List: (id , addr)
    (ffffdc865fb8adf0 ffffdc865fc95010)  
    Device Object list:
    ffffdc865f917030  ffffdc865f914030  ffffdc865f910030  ffffdc865fdcbb70
    
    
    DriverEntry:   fffff8067d2b6010 fvevol!GsDriverEntry
    DriverStartIo: 00000000 
    DriverUnload:  fffff8067d2a8ca0 fvevol!FveFilterUnload
    AddDevice:     fffff8067d288580 fvevol!FveFilterAddDevice
    

    -scott
    OSR

  • raj_rraj_r Member - All Emails Posts: 987
    via Email
    a big hammer
    !devnode 0 1
    this lists all the device nodes
    you can text search the output

    taking the driver scott used


    C:\>livekd -b "-c \"!devnode 0 1;q\"" | grep -A 5 -i fvevol
    InstancePath is "Root\LEGACY_FVEVOL\0000"
    ServiceName is "fvevol"
    State = DeviceNodeStarted (0x308)
    Previous State = DeviceNodeEnumerateCompletion (0x30d)
    DevNode 0x84ec37c8 for PDO 0x84ec3980
    InstancePath is "Root\LEGACY_HCMON\0000"
    ServiceName is "hcmon"

    C:\>livekd -b "-c \"!devobj 84ec3980;q\"" | grep -A 8 -i Reading
    kd> kd: Reading initial command '!devobj 84ec3980;q'
    *** ERROR: Module load completed but symbols could not be loaded for LiveKdD.SYS
    Device object (84ec3980) is for:
    0000001d \Driver\PnpManager DriverObject 84eb9310
    Current Irp 00000000 RefCount 0 Type 00000004 Flags 00001040
    SecurityDescriptor 89e61e50 DevExt 84ec3a38 DevObjExt 84ec3a40 DevNode 84ec37c8
    ExtensionFlags (0x00000810) DOE_START_PENDING, DOE_DEFAULT_SD_PRESENT
    Characteristics (0x00000080) FILE_AUTOGENERATED_DEVICE_NAME
    Device queue is not busy.

    C:\>livekd -b "-c \"dt nt!_DRIVER_OBJECT -a MajorFunction
    84eb9310;q\"" | grep -i quit -B 6
    [22] 0x82ed9d06 long nt!IopPowerDispatch+0
    [23] 0x830cf385 long nt!IopSystemControlDispatch+0
    [24] 0x82ec40e5 long nt!IopInvalidDeviceRequest+0
    [25] 0x82ec40e5 long nt!IopInvalidDeviceRequest+0
    [26] 0x82ec40e5 long nt!IopInvalidDeviceRequest+0
    [27] 0x82fc084e long nt!IopPnPDispatch+0
    quit:

    C:\>
  • Michael_RolleMichael_Rolle Member - All Emails Posts: 135

    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?

  • Michael_RolleMichael_Rolle Member - All Emails Posts: 135

    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?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,482
    via Email
    Michael_Rolle wrote:
    > 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.

  • Michael_RolleMichael_Rolle Member - All Emails Posts: 135

    @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?

    Thanks, Tim.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,065

    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.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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