KD 1394 Work-Around

Hey everyone!

The most recent Windows 10 preview(build 14901) no longer includes the ability to be kernel debugged over 1394(firewire) out of the box. We looked at a lot of data to make this decision, and decided with how many PCs are shipping with 1394, and how few people were using 1394 for KD, and the cost to maintain it, the value of keeping it just wasn’t there. We will continue to optimize KDNET and by focusing on fewer physical transports, this change will help us to continue to enhance KDNET. For those of you that use 1394 because it used to gather dumps faster than KDNET, I highly recommend trying out KDNET on a newer debugger release as we’ve made a lot of improvements to dump gathering.  KDNET should typically be significantly faster to capture a dump than 1394, and can be easily setup with kdnet.exe that ships with the kits or by following the directions on MSDN: Setting Up Kernel-Mode Debugging over a Network Cable Manually.

We aren’t completely getting rid of our 1394 support, we’ve decided to move the 1394 binary into to the kits so that people can still use it. We still have a few changes we need to do to the kits to pull in the driver so expect that with the next SDK preview.

Edit: As of the 14951 SDK preview, the 1394 driver is available in the 1394 folder of the debugger install directory.

Until then, if you need 1394, you can:

  1. Copy kd1394.dll from C:\Windows.old\Windows\system32\kd1394.dll (or from the C:\Windows\system32 directory of any older Windows 10 install) to C:\Windows\system32
  2. Run bcdedit -set {dbgsettings} debugtype 1394
    bcdedit -set {dbgsettings} channel n  (where n is the 1394 channel you typically use 0, 1, 2, … 63)
  3. Reboot and you’re good to go!


Comments (4)

  1. Jan says:

    Last month I had to use all of serial, 1394 and KDNET. Serial has the unique advantage that it does not require administrator privileges on the host. KDNET is fine as long as you can get host and target on the same (unfiltered) network. But I was indeed impressed by the 1394 one in speed, ease of set-up and reliability. Good to know it will still be around!

  2. Jan Bottorff says:

    I greatly prefer 1394 as a transport when I can. Using LSI chipset 1394 cards, I get around 40 MBytes/sec for writing dumps, and it single steps at keyboard repeat rate if I just hold down F10. Debugging is just more pleasant when you don’t wait. I tried writing a dump on an 8 GB ram system about 6 months ago with KDNET, and as I remember after a few hours waiting I gave up. Are you saying KDNET dumps are VASTLY improved recently, or a little better than before? I think you have to balance the costs of creating high quality debugging tools with the alternative of developers not being able to effectively debug low level code. A $10 ARM chip (or even a $3 micro-controller) often has low level debugging support built into the processor.

  3. William says:

    Does this mean 1394 debugging will continue to be available as an ad-on in the SDK, just not baked into the Windows media?
    Also, does the removal of 1394 debugging reduce the chance and/or impact of DMA attacks over 1394?

  4. Well this definitely hurts for those of us who have clients more concerned with Windows 7 than Windows 10. Till now, the approach was get a stable 1394 debugging environment, and use it for all cases. Enhancing KDNET is probably good because the crappy experience I and my clients have had, turned of most of us from ever using it. This will probably drive a number of firms I know who use custom systems (without network cards) to look more strongly at dumping Windows. The idea of pulling the 1394 card, every time they wish to test Windows 10 will at least probably keep them from the version of Windows.

Skip to main content