My Dell 380 at work has got just one COM port and I have been switching my serial cable between hosts as needed to get going. Since I had been hearing a lot about Vista supporting kernel debugging through USB, I thought yeah why not try it out. I could use some speed for sure.

I found an Intel document about it here and saw Hector’s memo on it here. I saw some evidence of folks getting nowhere in osronline forums so I figured, I may have some challenges ahead for this to work. No biggie.

I ordered Net20DC USB 2.0 Debug Cable1 from PLX Technology, which is pretty much the only cable out there for this purpose and got it couple of days later. Since USB was originally designed for devices connecting to PC, and not for PC to PC connection, the debug cable poses as a device to the PCs at both ends and so it is different from regular USB cables in that way. Now, hubs are permitted on the host side (the machine on which debugger is running) and not permitted on target side (the machine being debugged) of the debug cable. So I was thinking of using a hub on the host side to potentially debug same host from multiple machines. I can still use my COM port on XP and older machines.

My windbg host machine on XP SP2 installed the driver once I plugged in the cable and device manager showed it as Ajays USB 2.0 Cable [or something like that] and everything looked fine. The driver that was picked was usb2dbg.sys [written by Microsoft].

I went ahead and plugged the cable onto my target Vista host. Vista could not find the drivers for it and gave me the option to search online. No luck there. Then Vista suggested I check if there is a solution to my problem. No solution there. Turns out you have to point Vista to usb2dbg.sys lying in your debugging tools installation folders [for example C:\Program Files\Debugging Tools for Windows\usb] and then everything is fine and dandy. Why did Microsoft decide not to ship this driver on Vista when it was in XP ? No idea.

In any case, after copying default Vista boot entry [via bcdedit /copy ] and turning on debugging on the copy [via bcdedit /dbgsettings usb targetname:name-you-want ], I downloaded USBView and started hunting for Port 1 on my target host, since that is a requirement for kernel debugging to work. Once I found out the port numbers and marked them such with a marker [so I dont have to do this again], I realized that the organization of USB ports on a machine can be rather disorderly with some ports missing in between. I did not open my box to check if there were internal ports that would explain the “missing” ports.

I made sure that both sides were working with EHCI Controllers and rebooted target and chose the debug boot option. Then fired up windbg and connected to the target name. It was not working. I was combing through the web to see if I was missing something, when I found the following in windbg documentation –

Additional software components need to be installed for USB 2.0 kernel debugging to work. For details, contact [email protected].

So I did, and I learnt that the EHCI Controllers have to implement KD support for this to work and it is optional for the Controllers. Also there is no programmatic way to know whether an EHCI Controller supports debugging, unless the BIOS exposes it and Microsoft is not aware of any Controller+BIOS combo that advertises debug support. Therefore there is no way to find out if debugging is supported on a system, other than by trial and error. If that sounds crazy already, check this out. Some vendors have debugging support in their controller, but have not exposed the port so you can be SOL on those systems !

I wish I had seen this and this before I bought the dongle. Now I am not looking forward to calling HP and Dell to find out whether their EHCI Controllers support debugging. Bottom line – chances of getting your kernel debugging setup through USB to work, are similar to your chances of winning the lotto.

I learnt my lesson and paid $97.35 ($83 + freight $7.50 + Sales Tax $6.85) for it.

1net20dc seems to have vanished from PLX site. But I found net20dc being sold here.

Tagged with →  
Share →

8 Responses to Kernel Debugging Vista Over USB (Or Not)

  1. Frank Roh says:

    Hello John Bloe,

    First of all, I really appreciate your reply on my question.

    From you blog post, I found that there are both hardware and BIOS restriction to enable USB WinDbg.

    Using five computers, I tried several host and target pairs to check whether USB WinDbg worked.

    Fortunately, using Dell E520 (target) + Samsung MV60 (host), I finally had USB WinDbg set up successfully.

    Thanks again.

  2. Satya Das says:

    Congratulations Frank ! I wish I was that lucky.

    So, what motherboard, BIOS and EHCI controller on your target ? What EHCI controller on host ?

  3. Wahoo says:

    Thank you for sharing!

  4. Stan says:

    Is there any one to try Kernel Debugging Windows Server 2008 Over USB ? successful ?
    I tried it but there is no driver for Ajays USB 2.0 Debug Cable even if point Server 2008 to usb2dbg.sys lying in my debugging tools installation folders [for example C:\Program Files\Debugging Tools for Windows\usb] .

    Thanks,
    Stan

  5. Stan says:

    Hi ,

    Sorry, because I installed 2008 x64 OS as target but used 32bit XP as debugger , so both Debugging Tool and USB driver were 32bit.
    Then, I installed x64 OS and x64 Debugging Tool to captured x64 USB driver and loaded the driver for Ajays USB 2.0 Debug Cable successfully .

  6. Yuhong Bao says:

    I’d still keep the Net20DC, simply because there are computers with no FireWire or serial ports and no way to add one, such as the MacBook Air, so USB 2.0 debugging is the only chance you will have to get kernel debugging working on these computers. No it may not always work, but it is still better than nothing at all.

  7. Matt says:

    I know this is old, but since I stumbled across this page, I figure others might as well. So here is what I know on the subject of the EHCI debug port, and USB in general.

    You will always see ‘extra’ ports. The way a system supports both 2.0 and 1.x devices is the device connects to a UHCI/OHCI controller, then is passed off to a companion EHCI if the device is 2.0 capable. The port is shared between the physical port is shared between the two controllers.

    BIOS should not be involved in the debug port, at least in my experience. To find out if a EHCI supports a debug port, it is listed as part of its capabilities in its PCI configuration space. The interface is simple as well, consisting of a small block of memory mapped registers.

    The real trick is finding which physical port is the debug port.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Looking for something?

Use the form below to search the site:


Still not finding what you're looking for? Drop us a note so we can take care of it!

Visit our friends!

A few highly recommended friends...

Set your Twitter account name in your settings to use the TwitterBar Section.