windows NT kernel driver debugging

 I am having trouble using Windbg to debug a windows nt device driver. I  have a null modem cable installed between two computers both running the  same version of windows nt. I can use the com ports to talk between the
  two so I know the wiring is right. The host uses COM1 the target  COM2.
  I have enabled debugging on the target by inserting the /DEBUGPORT=COM2
  and /BAUDRATE=19200 in the boot.ini file under the correct [operating   systems] section.
  I start Windbg on the host system by: WinDbg -k i386 COM1 19200.
  When I select go I get the following message:
  Thread Create:  Process=0, Thread=0
  Kernel debugger waiting to connect on com1 @ 19200 baud
 check the SYMBOLS path in WinDbg. It points to a directory with the following structure:

The SYS directory contains the checked version of my driver.
 I then boot the target and the blue screen comes up saying  Kernel Debugger Using: COM2 (Port 0x2f8, Baud Rate 19200)
The screen flickers and I see the RCV and SND flash.
 I get stuck here because I never seem to get a response from the target. If I hit the ^C on the host the target will lock up. I never get any message saying the computers connected, but the ^c stops the target. The host never seems to connect!

 What am I doing wrong? Have I left
Who is Participating?
amartin030297Connect With a Mentor Commented:
Since nobody has answered you (and I don't have a technical ANSWER for you), but I have a non-free solution:

Purchase SoftIce.

Its trivial to debug kernel level drivers with it.  And you can
use a serial link OR 2 video cards OR 1 video card and 1 mono monitor (which is how most people do it).

It can also trace into and outof Interrupt (WinDbg sucks at that).

  -- Aaron

I have been unable to reproduce your symptoms. The message about checking your SYMBOLS path is not normal however. Make sure that the Symbol Search Path under the menu selections "Options\User DLLs" is set to the path you have placed your drivers checked binarie. I did find that if I have this path set wrong and the target machine hits a breakpoint in a driver it cannot continue the boot process, but it will halt on a ^c. After executing a ^c try typing ".reload" in the command window to see what happens.By the way windbg sucks. The only thing it is better than is nothing, wich is your only other option.
It would be reasonably trivial to set up a Linux partition for the COM port.  Then you could use tcpdump to get all the info you could ever want.  Reboot. switch back to windows.  done.  Linux is *much* better at getting port info.
Did I say tcpdump? whoops.  redirect a tty to a file.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.