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

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

Any easy way to set up Visual Studio to push the driver.sys automatically over to another computer?

Michael_RolleMichael_Rolle Member - All Emails Posts: 135

Just wondering if there's something like a Deploy setting, or something else in the project properties that will make the output file get copied over to another remote location.
I know about making a post-build step, but something better would be nice, such as making the remote destination a dependent of the local output file (this way it will get copied even if the local file is up to date).

Comments

  • raj_rraj_r Member - All Emails Posts: 977
    via Email
    if you were on windbg you can the command .kdfiles

    to use it you create a text file x.y

    contents being

    map
    {path in target}
    {path in host}

    and issue .kdfile {path}/x.y
  • Michael_RolleMichael_Rolle Member - All Emails Posts: 135

    That's pretty cool. Instead of a "push" we get a "pull" from the target.
    Sounds like this is only good for the actual driver.sys files. Which is all I was concerned about at this point.
    I have a test program that runs on the target machine, and I will want to run the test with a user mode debugger. I guess I can write a script that will bring the test.exe up to date with the dev machine, before launching windbg.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,215

    you can the command .kdfiles

    Mr. Raj_R is correct. This is the way most "pros" do it. Two things to be aware of:

    a) The syntax of the text file can be quite fussy... They've made some fixes over the past couple of years to try to make it less so, but be aware it can be quite demanding in terms of (for example) the way the path in the target is specified. In fact, I rarely use this method because I don't remember the (admittedly simple) syntax of the text file, and I almost never have the patience to get the matching path correct. I just copy the damn executable myself.

    b) When KDFILES sucks the new driver over, it does so on load. And the (old) one on your target system doesn't get replaced. This can be "a surprise" for those who haven't used it much.

    I guess I can write a script that will bring the test.exe up to date with the dev machine

    You can copy both the app and the driver image to a dedicated directory on the target with a script (that's what I typically do)... then use another script ON the target to replace the .SYS file for the driver in \windows\system32\drivers. Just disable the driver and re-enable it to cause the driver to reload.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • raj_rraj_r Member - All Emails Posts: 977
    via Email
    ah you just hit ctrl+alt+D to enable the debug spew and peer around
    to find the admittedly simple path replacement error :)

    basically as documented \??\c:\ should work but apparently
    sometimes it will look for %systemroot%\ in the target path

    as to local path it can be anything like
    xxx:\foo\blah\bar\yuk\mybeautifulugly.sys

    normally when i use a vm i simply bundle all into an iso and use it
    with capture cd image in the vm


    C:\>cat c:\Windows\bldiso.bat
    "c:\Program Files\ImgBurn\ImgBurn.exe" /Mode Build /SRC .\%1 /DEST
    .\%1.iso /buildoutputmode imagefile /FILESYSTEM "ISO9660 + Joliet"
    /start /volumelabel %1 /rootfolder no /close /noimagedetails
    C:\>

    just run bldiso foo.sys or folder open the vm and capture the iso that
    was just made
  • Jeffrey_Tippet_[MSFT]Jeffrey_Tippet_[MSFT] Member - All Emails Posts: 513

    b) When KDFILES sucks the new driver over, it does so on load. And the (old) one on your target system doesn't get replaced. This can be "a surprise" for those who haven't used it much.

    Actually (and perhaps regrettably), the behavior depends on the type of driver you're replacing. If you replace a boot start driver, then the driver on the target's disk is not replaced. Otherwise, the driver on disk is replaced.

    I speculate that perhaps the original plan was to always replace the driver on disk. But that is somewhat impossible to do from the OS loader, since the loader has only a limited filesystem driver, with mostly read-only access to disk.

    Note that you can't .kdfiles boot start drivers at all without running "bcdedit /set bootdebug on", so unless you took this slightly irregular step, you can expect that all drivers will get replaced on disk.

    I almost never have the patience to get the matching path correct

    This used to be a grave problem, to the extent that I'd routinely email out a pre-baked list of the One True Paths for all the drivers my team cares about, with stern instructions to cargo-cult the commands directly into the debugger. But a few years ago, the debugger team added the small-but-life-changing feature of partial string matches. So you can simply type .kdfiles -m ndis c:\my\build\environment\ndis.sys, and it'll match whatever ridiculous path the OS loader cobbles together. This simplified syntax is easy for me to memorize, and works for all types of drivers.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,215

    That is perhaps one of the funniest (I quite literally laughed out loud at the use of "cargo-cult" as a verb), and one of the most helpful, posts here in a long time.

    Thank you, Mr. Tippet. Enjoy the snow. :o

    Peter Viscarola
    OSR
    @OSRDrivers

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