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).
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
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.
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
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
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.
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