none
Kernel Debugging How to dump DEVICE_EXTENSION RRS feed

  • Question

  • How Can I Retrieve "MYDEVEXT" structure name ? here what's i am doing >>

    lkd> !drvobj \Driver\i8042prt
    Driver object (8c9bb528) is for:
     \Driver\i8042prt
    Driver Extension List: (id , addr)
    
    Device Object list:
    8c996020  8c9e0a88  
    lkd> !devobj 8c996020
    Device object (8c996020) is for:
      \Driver\i8042prt DriverObject 8c9bb528
    Current Irp 00000000 RefCount 0 Type 00000027 Flags 00002004
    Dacl 836b4d10 DevExt 8c9960d8 DevObjExt 8c996378 
    ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT
    Characteristics (0000000000)  
    AttachedDevice (Upper) 8dd14018 \Driver\ETD
    AttachedTo (Lower) 8b279470 \Driver\ACPI
    Device queue is not busy.
    lkd> !devstack 8c996020
      !DevObj   !DrvObj            !DevExt   ObjectName
      8c994cd8  \Driver\moh        8c994d90  
      8c993d90  \Driver\mouclass   8c993e48  PointerClass0
      8dd14018  \Driver\ETD        8dd140d0  
    > 8c996020  \Driver\i8042prt   8c9960d8  
      8b279470  \Driver\ACPI       8a7d9008  00000030
    !DevNode 8b277a80 :
      DeviceInst is "ACPI\ETD062F\4&33ddcf81&0"
      ServiceName is "i8042prt"
    lkd> dt 8c9960d8 i8042prt.sys!_PORT_MOUSE_EXTENSION // Here i don't know the name of the structure
    Symbol i8042prt.sys!_PORT_MOUSE_EXTENSION not found

    How do i dump symbol name ? 


    Friday, October 2, 2015 6:55 AM

Answers

  • In the "module!symbol" syntax, the module name should not include a file name extension such as ".sys".

    You can also try the dt i8042prt!* command. That should list all the types described in the debug information of i8042prt. If you're lucky, one of them may be the device extension type. If dt i8042prt!* does not output anything, that means you do not have private symbols for i8042prt and cannot use dt commands to examine its types.

    In some other cases, you might find type definitions in public header files, even if they have been stripped from debug symbol files. However, device extension types are not normally defined in public header files, because the data in the device extension should be used only by the driver that created the device object. If another driver needs to retrieve some information from there, then it should use an IOCTL request or something, rather than peek directly in the device extension.

    Friday, October 2, 2015 3:16 PM
  • The i8042prt source was available in some older DDK.

    Once you get the pdb file, use dt command to "cast" an address to that type:

    dt module!struct_name  address

    -- pa

    Friday, October 2, 2015 10:52 AM

All replies

  • The i8042prt source was available in some older DDK.

    Once you get the pdb file, use dt command to "cast" an address to that type:

    dt module!struct_name  address

    -- pa

    Friday, October 2, 2015 10:52 AM
  • In the "module!symbol" syntax, the module name should not include a file name extension such as ".sys".

    You can also try the dt i8042prt!* command. That should list all the types described in the debug information of i8042prt. If you're lucky, one of them may be the device extension type. If dt i8042prt!* does not output anything, that means you do not have private symbols for i8042prt and cannot use dt commands to examine its types.

    In some other cases, you might find type definitions in public header files, even if they have been stripped from debug symbol files. However, device extension types are not normally defined in public header files, because the data in the device extension should be used only by the driver that created the device object. If another driver needs to retrieve some information from there, then it should use an IOCTL request or something, rather than peek directly in the device extension.

    Friday, October 2, 2015 3:16 PM