Have to say it works well, very quick.
How far back is network debugging supported, windows 8.1 isnt it? Better hang on to that old hardware that supports firewire if you ever need to debug windows 7 then!
I have definitely used 1394 with Windows 10 for both the host and target,
not sure what happened in your environment. Maybe this:
https://blogs.msdn.microsoft.com/windbg/2016/08/11/kd-1394-work-around/
?
The only other time I’ve had problems is when I’ve had two 1394 controllers
on the host (the 1394 debug driver will only bind to one of them).
Network debug is indeed Win8+.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@windbg…
Have to say it works well, very quick.
How far back is network debugging supported, windows 8.1 isnt it? Better
hang on to that old hardware that supports firewire if you ever need to
debug windows 7 then!
Interesting, though the failure occured on win 10 IoT (Enterprise) build 14393 so not sure its relevant.
However network debugging is an appreciable leap in performance over 1394, just a shame they didnt add it to the system config GUI, then it would have been obvious its suported.
Thanks!
Be careful that one of the limits of network debugging (at least back when I tried it) was that you couldnt debug anything before the network stack was up. So if you are working on a driver that has stuff to do before the netowrk drivers are up, it won’t work.
I am assuing this will be fixed in the future Jim? If MSFT are moving to network debugging as the only solution, and it seems ot be that way, then it is going to need to work properly.
Perhaps in debug mode its got/going to have a different stack?
I am not familiar with the limitation of waiting for the network driver to start. I have been using network debugging going back to Win8 and its be started early enough to KdFile replace boot start drivers.