Running Debug Capability Test (Logo) - Reboots SUT and hangs on BIOS RRS feed

  • Question

  • I had been running into some issues while running the Debug Capability Test (Logo). My Host machine is running Windows 8 x64, has an Intel Gigabit built-in NIC on motherboard (harwarde ID#104B), certified in MSDN as one of the NIC that can run Kernel debugger. When I run the test, I see that it copies some files onto both the SUT and Host computers. And it reboots the SUT. After the first reboot, the test fails and the logs says that "Kernel Debugging failed due to non-supported NIC 55058515". But the Intel NIC on the Host machine is clearly a supported NIC as shown on the MSDN website. Another issue I'm having really bugs the hell out of me. I tried running the test again for the 2nd time and when the files were copied to the SUT and Host, it reboots the SUT. Then the SUT hangs on BIOS boot up. I can't even get into the BIOS configuration. I tried to clear the CMOS and removing the battery but it's still won't POST. So I had change the BIOS chip. And it works fine for a while. I ran the Debug Capability Test again and it failed too, no suprise there. So I ran it again, and now it kills my new BIOS too. I am really baffled now. How can a test kills my BIOS?? Did anyone experience this? Am I the only one? BTW, I'm using the Asus P8Z77-V LX motherboard.

    Thank you.

    Friday, November 23, 2012 8:28 PM

All replies

  • I have asked the team that owns this test to take a look this thread.
    Monday, January 7, 2013 8:01 PM
  • Hi there, I'm the PM on the team that owns this test and I may have some information for you. It seems that with some bios systems there was a recommended change that may not have been done. In some cases machines with 4+GB of RAM don't work for the NIC debugging (but will if you change the system to less than 4GB). It may be that your board passed their certification test with a different bios or with less RAM and worked around the issue.

    The MSDN article on this is here: but the key part is:

    • System      firmware should discover and configure the NIC device such that its resources      do not conflict with any other devices that have been BIOS-configured.
    • System      firmware should place the NIC’s resources under address windows that are      not marked prefetchable

    It seems for some MB's this isn't adhered to if they have more than 4GB of RAM configured and try to use NIC debugging. The 'workaround' was to reduce the RAM during debugging (less than ideal we know but unless the BIOS is updated by the manufacturer there isn't another workaround we are aware of at this time).

    That being said we are unaware of anything that could actually 'kill' the BIOS here in terms of the test (it should have no effect on the BIOS chip itself). That may be unrelated to the MSDN article about the BIOS and could point to some other issues that I could only theorize about with respect to your MB.

    Monday, January 7, 2013 9:56 PM
  • The NIC that you have in the HOST machine (the one running the debugger) does NOT have to support network debugging.  The NIC that needs to support KDNET is the one in the TARGET machine.  The machine being debugged.

    Ignore the NIC in your HOST.  If it has a Windows driver, and can send IPv4 packets, it is fine.  It can be from any manufacturer whatsoever, and doesn't have to be a "supported KDNET NIC".

    However, the NIC in the target machine absolutely MUST be a supported NIC if you want KDNET to actually work.

    I suspect that you have an unsupported NIC in the target machine, and that KDNET on the target machine is attempting to use USB3 debugging, and that you have a MB that has USB3 hardware support, and which also "supports" USB3 debugging.  The parameters that KDNET uses for USB3 debug support are different than those used for standard USB3 debugging using kdusb.dll, and if ASUS is making assumptions about the parameters for USB3 debugging, then you might see something like what you are seeing.

    What NIC is in the target machine?  If it is a new model Realtek 8168 then it is likely NOT supported.  (Unfortunately Realtek keeps their PCI device ID unchanged for many different hardware spins of their chips, and so some 8168 chips are supported and some are not.)

    Tuesday, January 8, 2013 8:14 AM