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

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/


Before Posting...

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

Symbols in WinDBG for firmware loaded into memory?

OSR_Community_UserOSR_Community_User Member Posts: 110,217
Here's my scenario:
I load an executable image ( just a plain PE format DLL) with my own PE
loader, and only call it from my driver. This all works just fine.
However, since the system hasn't done the loading, WinDBG doesn't see it
happen, hence doesn't equate this blob of memory with executable
instructions with its definition of a module, hence can't load the symbols.
If I were using SoftICE, I could do the following:

1) Set SoftICE to load the symbol file.
2) When I get to my module, type the following:
table [image name]
symloc 1 28 0xNNNNNNNN, where NNNNNNNN is the base address of my image.

This forces it to use the previously loaded symbol file for that area of
memory, and it shows me the symbols properly.

To try to duplicate this on WinDBG, I have tried to manually force it to
load the symbol file using ld, but it either won't do it, or I am not asking
it to do so in the right way. I do have the right symbol path.

Is there an equivalent procedure for WinDBG, or am I going to have to use
SoftICE?

Thanks,

Phil

* Philip D. Barila | (503) 264-8386
* Intel Corp. | M/S JF2-53 Office JF2-2-G6
* Storage Architecture and Performance
* Internet Systems Lab



---
You are currently subscribed to windbg as: $subst('Recip.EmailAddr')
To unsubscribe send a blank email to leave-windbg-$subst('Recip.MemberIDChar')@lists.osr.com

Comments

  • .reload will do this.

    .reload <module>=<address>,<size>

    This is only useful in the specific case where a module does not exist
    in the loaded module list. This only occurs in certain cases for user
    mode debugging through the kernel debugger and image headers are paged
    out, or if you have written your own image loader, and the OS does not
    know about this image.

    The "ld" command is fairly useless. It just causes the symbols to
    attempt to load. Refering to any symbol in the module does the same
    thing. In other words the debugger does "ld" for you all the time.

    -----Original Message-----
    From: Barila, Phil [mailto:[email protected]]
    Sent: Monday, April 23, 2001 11:47 AM
    To: Kernel Debugging Interest List
    Subject: [windbg] Symbols in WinDBG for firmware loaded into memory?

    Here's my scenario:
    I load an executable image ( just a plain PE format DLL) with my own PE
    loader, and only call it from my driver. This all works just fine.
    However, since the system hasn't done the loading, WinDBG doesn't see it
    happen, hence doesn't equate this blob of memory with executable
    instructions with its definition of a module, hence can't load the
    symbols.
    If I were using SoftICE, I could do the following:

    1) Set SoftICE to load the symbol file.
    2) When I get to my module, type the following:
    table [image name]
    symloc 1 28 0xNNNNNNNN, where NNNNNNNN is the base address of my image.

    This forces it to use the previously loaded symbol file for that area of
    memory, and it shows me the symbols properly.

    To try to duplicate this on WinDBG, I have tried to manually force it to
    load the symbol file using ld, but it either won't do it, or I am not
    asking
    it to do so in the right way. I do have the right symbol path.

    Is there an equivalent procedure for WinDBG, or am I going to have to
    use
    SoftICE?

    Thanks,

    Phil

    * Philip D. Barila | (503) 264-8386
    * Intel Corp. | M/S JF2-53 Office JF2-2-G6
    * Storage Architecture and Performance
    * Internet Systems Lab



    ---
    You are currently subscribed to windbg as: [email protected]
    To unsubscribe send a blank email to leave-windbg-$subst('Recip.MemberIDChar')@lists.osr.com

    ---
    You are currently subscribed to windbg as: $subst('Recip.EmailAddr')
    To unsubscribe send a blank email to leave-windbg-$subst('Recip.MemberIDChar')@lists.osr.com
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!
Writing WDF Drivers 24 January 2022 Live, Online
Internals & Software Drivers 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online
Developing Minifilters 23 May 2022 Live, Online