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

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

How to set up symbol and source files on the host, when they reside on the target.

Michael_RolleMichael_Rolle Member - All Emails Posts: 135

I haven't yet figured out what to do so that windbg on my host can display symbols and source code for my driver as it's being debugged.
The driver.pdb will have names of source files, using the target's filesystem. How is windbg on the host going to find them? Does it use the remote debugger as a server to get the files? Or if I copy the source files over to the host, the folder paths will be different from what's in the .pdb, and how can windbg figure this out? Maybe I need to build a copy of the driver.sys on the target itself so that all the source file folders are correct?
Would somebody who uses windbg to debug a driver that is build on the host please tell me how you do it? Thanks.

Comments

  • raj_rraj_r Member - All Emails Posts: 981
    via Email
    target = system which is running the driver (a virtual machine , a
    second physical computer , whatever )

    you do not build your driver/app/anything on this machine it is solely
    used only to test / debug the built driver

    are you getting that right ? when you mention target ??


    host a physical machine where you build your driver it contains your
    source , pdbs , etc you take the built driver from this machine and
    install , load it on the target

    are you getting this right ? when you mention host ??


    you also run windbg in the host machine not on the target machine ??

    if you say yes to all three then windbg should not have any problems
    locating your latest pdbs

    the most easiest and versatile way is to create a folder say as {volume}{dir)

    where volume can be c,d,e,f, drives

    and dir can be "symbols", "mysymbols" , "sym" , "some other fancy name"
    always kiss is better shun path with spaces etc

    as an example i have E:\symbols as my symbol directory (it has been
    so for last ten years or so and i haven't had the necessity to tweak
    it and i have thrown a lot of shoes on it as mark roddy said the other
    day)

    once you create a directory

    the next step is to create an ENVIRONMENT_VARIABLE _NT_SYMBOL_PATH
    use computer->properties->advanced system settings-> envvars_. systemvars
    new -> var nam _NT_SYMBOL_PATH
    var val srv*E:\symbols*http://msdl.microsoft.com/download/symbols;

    this solves almost all the problems of windbg locating a symbol

    it will properly download the symbols to this directory and both user
    mode as well as kernel mode debugging will use this directory

    now what is left is how to copy the newly built drivers pdb to this directory

    (the directory is structured so just copying it anywwere wont help you

    use the provided utility symstore to copy the pdb to the designated directory

    i built an app and for src below and i am copying the pdb to _NT_SYMBOL_PATH

    #include
    #pragma comment(lib, "user32.lib")
    #pragma comment(lib, "kernel32.lib")

    // compile with cl -Gs /Zi /W4 /analyze /Od msgbox.cpp
    // link /release /entry:main /subsystem:windows msgbox.obj

    void main (void)
    {
    MessageBoxA(NULL,"test","test",MB_OK);
    ExitProcess(0);
    }


    \MessageBox>symstore add /f .\msgbox.pdb /t "w7" /s e:\SYMBOLS
    Finding ID... 0000000006

    SYMSTORE: Number of files stored = 1
    SYMSTORE: Number of errors = 0
    SYMSTORE: Number of files ignored = 0

    since the pdb has been stored i can delete the pdb in local dir and
    windbg will still be able to find the pdb



    cdb -c ".reload /f; lm m msg*;q" msgbox.exe | grep -B 3 -i quit:

    start end module name
    00180000 00184000 msgbox (private pdb symbols)
    e:\symbols\msgbox.pdb\1A6319967E6C4F9C901ACF5F391F9FD92\msgbox.pdb

    quit:

    C:\Users\XXXX\Desktop\code\MessageBox>
  • Michael_RolleMichael_Rolle Member - All Emails Posts: 135

    Actually, I was having trouble using my main computer as host because I couldn't make connection with the target. But I've solved that one (by using the laptop's ethernet connector instead of wifi). So my problem with file locations is simpler.
    On the PC I build the driver, and also a test vehicle that uses the driver, and all the sources are there too. The driver.pdb and test.pdb are where they should be, and the sources are where the pdb's say they should be.
    So the only issue is that I want to be sure that the driver and test executables get copied over to the target somewhere.
    I've never done remote debugging in VS before, so this is an adventure. What I'm hoping is that I just tell VS where on the remote machine the .exe is to go, and it will simply launch it over there. Even better would be if the .exe gets copied over there automatically.
    I have a KVM switch so that I can easily work on both the host and the target from my desk.
    I'm thinking that I'd use Visual Studio to remotely run the test program and use windbg to debug the driver at the same time. Of course when I'm in windbg looking at the driver I can't do anything with the test program until I do 'g' in windbg, but that's no matter.
    Do you think this would work, having two debugging sessions at the same time?
    And thanks much for your taking time to answer me so thoroughly. If I have more problems would you mind if I contact you privately, or would it be better just to use this same post with more comments?
    Michael

  • raj_rraj_r Member - All Emails Posts: 981
    via Email
    as i replied to your other thread i would employ .kdfiles for copying
    over to target

    as to contacting privately i have no problems if you have some private
    details that you wouldn't like the whole world to know about but can
    share with a single person

    but if the discussion could benefit the community please keep them here
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA