Just how do you get KD / WinDbg to debug a running target kernel??

NTDEV
1

Hello everyone. I thought I would learn to use the kernel debugging tools, and I have hit a number of snags. I’m wondering if I am missing some instructions somewhere, or it really is tricky. Let me enumerate…

  1. My target computer doesn’t have a COM port, so I went out and bought a USB 2.0 cable. That didn’t work. The Debugger docs say that some special hardware is needed and that it might not work, and no way to find out.
  2. I bought a PCI serial card and a null modem cable. And boy, were those hard to find, they’re mucho obsolete. My host and target computers can successfully send data back and forth between their COM ports. But still no success with debugging.
  3. Adding the /debug to the boot.ini (or selecting debug option with F8 during bootup) resulted in the system freezing after a couple of minutes. I have found that when I remove all startup applications, it doesn’t freeze, so apparently one of those applications causes the freeze when it launches.
  4. Now that my target doesn’t freeze, I try to connect with the debugger. With windbg -k com:port=com1,baud=19200, it sets in “waiting to reconnect…”, and the status bar says debuggee not connected. Similarly with KD.
  5. I try the .crash and .restart and .reboot commands in KD, to no avail. I have the impression that while it is waiting to reconnect, KD does not respond to anything except the control characters. This is because I type in some nonsense and it says nothing about it either. I guess it is just storing what I typed until it is ready to do something with it.
  6. I have also tried starting the debugger while the target is running, and rebooting the target while the debugger is waiting to reconnect. Nothing.

Anyway, I have no clue whether anything is being exchanged between host and target at all.

I’m sure you experts have been doing debugging for years, and not just local mode or softIce, which just analyze a snapshot of the kernel state like it’s a crashdump.

So, could someone who has actually been doing debugging over a serial cable please tell me what all the steps are, or at least point me to a good reference resource?

You guys at Microsoft, I have a complaint that it’s too darned hard to use the debugger. For one thing, the communication only has three obscure hardware options. And it would be nice to document more about exactly what the /debug boot switch does to affect the kernel’s behavior. I don’t think it should be necessary for a company to hire a team of seasoned experts just to create drivers to go with some nice new hardware – it really raises the cost of entry into the marketplace a lot, and this makes for less available peripherals and a smaller demand for computers and ultimately a smaller demand for the Windows operating system. I suggest that anything you can do to actively make it easier to write drivers will pay dividends to you. IMHO.

Thank you.

2

I should add that my serial device is a PCI card, as the computer doesn’t have a built-in serial device. This might make a difference.

3

I should also add that the host is an x86 system and the target is an x64 system with XP x64 edition. This might be a factor?
This raises a question: Does some debugger have to be installed on the target system (and the right one) for this to work, or is the communication protocol built into the OS itself? I’ve seen nothing about configuring the target other than the boot switches, but I’ve seen some posts here recommending that target and host both have the same version of WinDbg. That’s why I’m unclear about this.

4

There are three choices:

  1. Serial - standard on specific port addresses and IRQs as defined by IBM
    with the PC/XT.
  2. 1394a - use TI chipset based card for best results.
  3. USB 2.0 - Use only with Vista and higher for the target. You can use XP
    Pro on the host.

Buy the book. It is available on Amazon. It isn’t that difficult, but
without experience in kernel work it takes a long time to learn all you need
to know. Some stuff is difficult, but even the simple requires time.

Microsoft has done a lot to simplify the world of hardware over the years
with WHQL and various specifications for device design (such as mass storage
spec). One thing that works against their efforts is the various hardware
makers who want their devices to have some ‘difference’ that makes them
‘better’ than anyone following the specifications.

Most of the information on windbg given above is readily available in the
documentation. Read and read it again.

wrote in message news:xxxxx@ntdev…
>I should add that my serial device is a PCI card, as the computer doesn’t
>have a built-in serial device. This might make a difference.
>
>

5

It sounds like you’ve gone down some wrong turns and have managed to end up on just the wrong side of things.

The hardware options are limited because the part of the OS that implements KD needs to know how to talk to the hardware in use directly, without the benefits of third party drivers.

For serial connectivity, you must have a real UART on the target. The OS expects to talk to a UART and not a custom PCI device. The computer running the debugger talks to the serial port through the OS and can use USB to serial cables, custom PCI cards, real honest-to-goodness UARTs, etc. But the computer being debugged must have a UART.

For USB connectivity, you must use a special cable built for the USB debugging standard. This is not your usual cable. They are special purpose and, sadly, hard to find.

The best bet in this case is, IMO, to go with a 1394 card. You can use a PCI (or PCMCIA) card as they conform to standards understood by the 1394 mini-driver used by KD 1394 support.

OSR resells a cheap, solid 1394 card that’s reportedly good for just this sort of thing.

Personally, I use 1394 (if available), or serial. I have yet to (personally) have to KD real hardware where neither of those are available, though I hear that it is not uncommon with blade servers.

Re: blocking with /DEBUG: My guess is you have something that tries to spew lots of DbgPrints during boot. With KD enabled but no debugger attached, each one may need to time out to continue.

  • S

-----Original Message-----
From: xxxxx@pdsys.biz
Sent: Monday, June 22, 2009 22:37
To: Windows System Software Devs Interest List
Subject: [ntdev] Just how do you get KD / WinDbg to debug a running target kernel??

Hello everyone. I thought I would learn to use the kernel debugging tools, and I have hit a number of snags. I’m wondering if I am missing some instructions somewhere, or it really is tricky. Let me enumerate…
1. My target computer doesn’t have a COM port, so I went out and bought a USB 2.0 cable. That didn’t work. The Debugger docs say that some special hardware is needed and that it might not work, and no way to find out.
2. I bought a PCI serial card and a null modem cable. And boy, were those hard to find, they’re mucho obsolete. My host and target computers can successfully send data back and forth between their COM ports. But still no success with debugging.
3. Adding the /debug to the boot.ini (or selecting debug option with F8 during bootup) resulted in the system freezing after a couple of minutes. I have found that when I remove all startup applications, it doesn’t freeze, so apparently one of those applications causes the freeze when it launches.
4. Now that my target doesn’t freeze, I try to connect with the debugger. With windbg -k com:port=com1,baud=19200, it sets in “waiting to reconnect…”, and the status bar says debuggee not connected. Similarly with KD.
5. I try the .crash and .restart and .reboot commands in KD, to no avail. I have the impression that while it is waiting to reconnect, KD does not respond to anything except the control characters. This is because I type in some nonsense and it says nothing about it either. I guess it is just storing what I typed until it is ready to do something with it.
6. I have also tried starting the debugger while the target is running, and rebooting the target while the debugger is waiting to reconnect. Nothing.

Anyway, I have no clue whether anything is being exchanged between host and target at all.

I’m sure you experts have been doing debugging for years, and not just local mode or softIce, which just analyze a snapshot of the kernel state like it’s a crashdump.

So, could someone who has actually been doing debugging over a serial cable please tell me what all the steps are, or at least point me to a good reference resource?

You guys at Microsoft, I have a complaint that it’s too darned hard to use the debugger. For one thing, the communication only has three obscure hardware options. And it would be nice to document more about exactly what the /debug boot switch does to affect the kernel’s behavior. I don’t think it should be necessary for a company to hire a team of seasoned experts just to create drivers to go with some nice new hardware – it really raises the cost of entry into the marketplace a lot, and this makes for less available peripherals and a smaller demand for computers and ultimately a smaller demand for the Windows operating system. I suggest that anything you can do to actively make it easier to write drivers will pay dividends to you. IMHO.

Thank you.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

The target being debugged uses logic baked into the system itself. You do not need to install the debugger on the target, although there’s no harm from doing so.

32 to 64-bit debugging is supported, as vice-versa. Your issue is that you’re not having a real UART on the target which is required for serial port support.

  • S

-----Original Message-----
From: xxxxx@pdsys.biz
Sent: Monday, June 22, 2009 23:07
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Just how do you get KD / WinDbg to debug a running target kernel??

I should also add that the host is an x86 system and the target is an x64 system with XP x64 edition. This might be a factor?
This raises a question: Does some debugger have to be installed on the target system (and the right one) for this to work, or is the communication protocol built into the OS itself? I’ve seen nothing about configuring the target other than the boot switches, but I’ve seen some posts here recommending that target and host both have the same version of WinDbg. That’s why I’m unclear about this.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

The freezing is likely due to a breakpoint or exception being hit. But
without a debugger attached this results in a freeze. Just booting with
/debug is not enough . You also need to specify /debug /debugport=COM1
/baudrate=19200.
For an overview of boot parameters check here:
http://support.microsoft.com/kb/833721

//Daniel

wrote in message news:xxxxx@ntdev…
> 3. Adding the /debug to the boot.ini (or selecting debug option with F8
> during bootup)
> resulted in the system freezing after a couple of minutes. I have found
> that when I remove all startup applications, it doesn’t freeze, so
> apparently one of those applications causes the freeze when it launches.
> 4. Now that my target doesn’t freeze, I try to connect with the debugger.
> With windbg -k com:port=com1,baud=19200, it sets in “waiting to
> reconnect…”, and the status bar says debuggee not connected. Similarly
> with KD.
>

8

Many thanks, Skywing. It’s not the answer I hoped for, but it does resolve
the problem.

All I have is a little piece of kernel code I have adapted from somebody
else’s code. It was appealing to have a debugger so I could find out where
the “parameter is invalid” status is coming from. However, I see that
kernel mode debugging is tricky, and relatively expensive compared to the
task at hand. Depending on how expensive it is, I may go with a 1394 card,
or I may just do without.

As far as doing with out is concerned… Can you tell me what happens to
DbgPrint in kernel code if there is no debugger? Does the output go to a
log file somewhere, or do I get a crash? If I can read the output later,
DbgPrint would be very helpful in debugging.

By the way, it seems that skype is the culprit in the /debug boot hangup.
Heaven knows why, but I’ll know not to launch skype if I have the /debug
boot.

9

I seem to recall that OSR’s 1394 card was something like on the order of $20ish, though I may misremember. I’d check their site to be sure.

Normally, DbgPrints will by default go nowhere without a debugger attached. You can use a tool like Sysinternals’ DbgView to capture them – but for most nontrivial kernel mode development tasks, I suspect you may run a risk of spending a lot of time on things that would have been much simpler|quicker with a debugger.

If your boot is hanging entirely and not just being slow in the case you described, it may be that Skype hits a breakpoint or another event that would try to synchronously break into the debugger.

You could try booting with /noumex to disable most unhandled user mode events from trying to break into KD - but if you’re not going to hook up a debugger in the first place, then there’s not much point in booting /debug in most scenarios. Such might be even counterproductive, as depending on the circumstances, you might see the machine wait forever for the debugger to connect in the event of a bugcheck versus just writing out a crash dump which could be debugged offline.

  • S

-----Original Message-----
From: Michael Rolle
Sent: Wednesday, June 24, 2009 00:11
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] Just how do you get KD / WinDbg to debug a running target kernel??

Many thanks, Skywing. It’s not the answer I hoped for, but it does resolve
the problem.

All I have is a little piece of kernel code I have adapted from somebody
else’s code. It was appealing to have a debugger so I could find out where
the “parameter is invalid” status is coming from. However, I see that
kernel mode debugging is tricky, and relatively expensive compared to the
task at hand. Depending on how expensive it is, I may go with a 1394 card,
or I may just do without.

As far as doing with out is concerned… Can you tell me what happens to
DbgPrint in kernel code if there is no debugger? Does the output go to a
log file somewhere, or do I get a crash? If I can read the output later,
DbgPrint would be very helpful in debugging.

By the way, it seems that skype is the culprit in the /debug boot hangup.
Heaven knows why, but I’ll know not to launch skype if I have the /debug
boot.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer