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!

-Andy
@aluhrs13

Comments

  • Anonymous
    August 11, 2016
    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!
  • Anonymous
    August 12, 2016
    The comment has been removed
  • Anonymous
    August 17, 2016
    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?
  • Anonymous
    September 14, 2016
    The comment has been removed
  • Anonymous
    September 01, 2017
    1394 is the ONLY transport that has direct access to physical RAM. It is the only way to get memory dump when CPUs are unresponsible or unreliable. You should not make such changes without providing alternative solution.
    • Anonymous
      September 01, 2017
      We've made a lot of improvements to KDNET so it can support scenarios where previously only 1394 would work. If you hit any problems with KDNET and an up to date debugger, let us know.
  • Anonymous
    December 05, 2017
    it's too slow ,I have to use virtualkd(: