Debugging Drivers

Robert_Gaurie · October 20, 2008, 2:22pm

What are my option on debugging Windows drivers? Currently I use a null modem serial cable and Windbg. The only thing I can find suggests this or a IEEE 1394 cable. Are there other cable options? My newer systems don’t have these plugs. Is there a USB solution?

Doron_Holan · October 20, 2008, 2:28pm

Serial and 1394 are your best bets. Usb 2.0 debugging is nearly impossible to get right and is quite flakey in my experience. 1394 is the preferred option if the machine you are debugging has an open pci slot in which you can plug in a 1394 host controller card.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Monday, October 20, 2008 11:24 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Debugging Drivers

What are my option on debugging Windows drivers? Currently I use a null modem serial cable and Windbg. The only thing I can find suggests this or a IEEE 1394 cable. Are there other cable options? My newer systems don’t have these plugs. Is there a USB solution?

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

OSR_Community_User · October 20, 2008, 2:29pm

Forget USB, it is too hard to get working. So your only options are
1394 and Serial cable.

–Mark Cariddi
OSR, Open Systems Resources, Inc.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Monday, October 20, 2008 2:24 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Debugging Drivers

What are my option on debugging Windows drivers? Currently I use a null
modem serial cable and Windbg. The only thing I can find suggests this
or a IEEE 1394 cable. Are there other cable options? My newer systems
don’t have these plugs. Is there a USB solution?

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

Don_Burn_1 · October 20, 2008, 2:29pm

There is a USB solution but whether you can get it to work is highly
questionable. It has an extremely expensive cable required (you can buy two
1394 adapters from OSR and a 1394 cable for the same price as the USB
cable). The usb option also requires a specific configuration of USB which
many systems do not have.

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> What are my option on debugging Windows drivers? Currently I use a null
> modem serial cable and Windbg. The only thing I can find suggests this or
> a IEEE 1394 cable. Are there other cable options? My newer systems don’t
> have these plugs. Is there a USB solution?
>

Ken_Johnson · October 20, 2008, 2:32pm

I prefer, in this order:

Debugging a VM, if possible for the situation
Debugging over 1394
Debugging over serial

There is support for USB 2.0 debugging in Vista and beyond, but I have never had a situation where I had to use it.

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Monday, October 20, 2008 2:24 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Debugging Drivers

What are my option on debugging Windows drivers? Currently I use a null modem serial cable and Windbg. The only thing I can find suggests this or a IEEE 1394 cable. Are there other cable options? My newer systems don’t have these plugs. Is there a USB solution?

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

Mark_S_Edwards · October 20, 2008, 2:35pm

At 19:23 20/10/2008, xxxxx@yahoo.com wrote:

What are my option on debugging Windows drivers? Currently I use a
null modem serial cable and Windbg. The only thing I can find
suggests this or a IEEE 1394 cable. Are there other cable
options? My newer systems don’t have these plugs. Is there a USB solution?

Two possible USB solutions.

The latest WinDbg does support a direct USB connection. However, it
has to be made with a USB Debug cable. This is a real mythical
beast. Although it’s not much more than a null-modem for USB I’ve
never found one for sale. The USB specs available from Intel do
describe this cable and the pin-outs if you’re feeling brave with a
soldering iron.

The other option is a USB to Serial converter which I use myself,
though this does require that the debug target still have a physical
COM port. My laptop on which I run WinDbg has no COM port, but the
USB to Serial device solves the problem. These devices are pretty
cheap - search for ATEN and product: UC232A.

HTH

Mark.

Ken_Johnson · October 20, 2008, 2:40pm

To expand on some reasoning here, 1394 is the highest performing debugging interface of all the officially supported options, as the “read physical memory” function is essentially overridden on the 1394 interface, such that it essentially DMA’s the target’s memory over the wire (instead of sending read memory protocol message requests to the kd stub in the kernel on the target).

I don’t think that USB debugging has this performance improvement (though I might be misremembering). The 1394 debug transport read physical memory optimization is very noticeable if you are doing large bulk read operations (such as searching memory, or creating a dump file over the wire), where you may see operations complete orders of magnitude faster than over serial.

Operations that require many small individual round-trip operations (e.g. !process 0 1f) are still very relatively slow over 1394, however.

Debugging a VM will likely still limit you to serial port speeds, unless you use a third party program to swap out the KD transport with something faster. Even so, the convenience of snapshot-able systems and not having to get up to reboot things manually or type on the console are compelling, if you can debug in a virtualized environment. (Obviously, this is unsuited for physical hardware drivers. Software only components are a different story, however, so it really depends on the project that you are working on.)

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, October 20, 2008 2:25 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Debugging Drivers

Serial and 1394 are your best bets. Usb 2.0 debugging is nearly impossible to get right and is quite flakey in my experience. 1394 is the preferred option if the machine you are debugging has an open pci slot in which you can plug in a 1394 host controller card.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Monday, October 20, 2008 11:24 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Debugging Drivers

What are my option on debugging Windows drivers? Currently I use a null modem serial cable and Windbg. The only thing I can find suggests this or a IEEE 1394 cable. Are there other cable options? My newer systems don’t have these plugs. Is there a USB solution?

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

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

Michal_Vodicka-2 · October 20, 2008, 2:51pm

For completeness I’d add there is a way how to avoid debuggers at all.
Traces and DebugView. For me it is much more efficient than any debugger
which I haven’t used for years.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, October 20, 2008 8:32 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Debugging Drivers

I prefer, in this order:

Debugging a VM, if possible for the situation

Debugging over 1394

Debugging over serial

There is support for USB 2.0 debugging in Vista and beyond,
but I have never had a situation where I had to use it.

S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Monday, October 20, 2008 2:24 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Debugging Drivers

What are my option on debugging Windows drivers? Currently I
use a null modem serial cable and Windbg. The only thing I
can find suggests this or a IEEE 1394 cable. Are there other
cable options? My newer systems don’t have these plugs. Is
there a USB solution?

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

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

Pavel_A1 · October 20, 2008, 4:05pm

Doron Holan wrote:

Serial and 1394 are your best bets. Usb 2.0 debugging is nearly impossible to get right and is quite flakey in my experience. 1394 is the preferred option if the machine you are debugging has an open pci slot in which you can plug in a 1394 host controller card.

Doron, is this because it’s hard to find the right USB port - or
are there any problems *after* the connection over usb is up and working?

FWIW, there was a message recently in the windbg NG that
explains how to find the port #0 and even more, describes
the parameter to select the EHCI controller (when there are several).

Regards,
–PA

Doron_Holan · October 20, 2008, 4:13pm

Finding the right port can be evil. Many manufacturers do not expose it or have attached an embedded device to it. The cable itself is not that reliable either. Of the 3 transports, usb gets the least amount of attention internally at Microsoft. The quality of the usb transport reflects its 3rd tier status, in part due to constrained dev resources and in part b/c the hardware is not that cooperative.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Monday, October 20, 2008 1:01 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Debugging Drivers

Doron Holan wrote:

Serial and 1394 are your best bets. Usb 2.0 debugging is nearly impossible to get right and is quite flakey in my experience. 1394 is the preferred option if the machine you are debugging has an open pci slot in which you can plug in a 1394 host controller card.

Doron, is this because it’s hard to find the right USB port - or
are there any problems *after* the connection over usb is up and working?

FWIW, there was a message recently in the windbg NG that
explains how to find the port #0 and even more, describes
the parameter to select the EHCI controller (when there are several).

Regards,
–PA

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

Don_Burn_1 · October 20, 2008, 4:13pm

There are problems after you get it to “work”, it remind me of Windbg for NT
3.5

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Pavel A.” wrote in message news:xxxxx@ntdev…
> Doron Holan wrote:
>> Serial and 1394 are your best bets. Usb 2.0 debugging is nearly
>> impossible to get right and is quite flakey in my experience. 1394 is
>> the preferred option if the machine you are debugging has an open pci
>> slot in which you can plug in a 1394 host controller card.
>>
>
> Doron, is this because it’s hard to find the right USB port - or
> are there any problems after the connection over usb is up and working?
>
> FWIW, there was a message recently in the windbg NG that
> explains how to find the port #0 and even more, describes
> the parameter to select the EHCI controller (when there are several).
>
>
> Regards,
> --PA
>

David_J_Craig · October 20, 2008, 4:14pm

There are three options for debugging two physical machines. The target is
where the code under test is located. The host is where windbg/kd/etc are
run and where the code being tested should be compiled - especially true for
drivers. Using the map capability of _NT_KD_FILES in the environment to
point to an ini file you can cause any driver loading later than boot start
to be retrieved from the host system. It works very well and as long as
your different OS versions use a different name you can do, for example, a
NDIS5 and NDIS6 miniport easily even if the code bases are different.

Serial. Slow, but easy to use. Requires a real serial port on the
target that uses either COM1 or COM2. Some success might be obtained with
other ports, but it is unlikely. The serial should be a clone of the
16550AFN device.
USB. Search for NET20DC on Google to locate the magic blue box that
permits it. It requires some special conditions exist on the target system
that many systems do not implement. It will work on some systems such as
Dell enterprise desktops. The device will cost less than $100, but that is
too much. Read the windbg docs for all the rules. Vista and later, but the
host works just fine with XP.
1394a. Very good but the target should be running a TI chipset 1394a
board. It can be PCI/PCI-X/PCIe. I disable the card on the target since it
cannot be shared. Pyro offers an excellent PCI 64R2 card from ADS (1394DV
API-315 Rev. F) that works in standard PCI slots and PCI-X slots as well.
OSR sells a good PCI only card. There are cards for PCIe that use the TI
chipsets, but you may have to ask the manufacturer which specific model
numbers have them. Koutech has some but they also offer ones that use the
Via and Agere chipsets that don’t work as well.

wrote in message news:xxxxx@ntdev…
> What are my option on debugging Windows drivers? Currently I use a null
> modem serial cable and Windbg. The only thing I can find suggests this or
> a IEEE 1394 cable. Are there other cable options? My newer systems don’t
> have these plugs. Is there a USB solution?
>

Ken_Johnson · October 20, 2008, 5:05pm

You might not even be able to use port #0 on modern hardware.

Most laptops nowadays use USB internally in the case (inside the casing) for several of the built-in devices. For example, my Dell XPS M1710 puts the integrated smartcard reader and Bluetooth transceiver on USB, despite that some of these components (the smartcard reader in particular) are not exactly user swappable.

If one of those “USB ports” happens to be port #0, then you’re kind of hosed.

This is especially a shame, as I think the whole driving goal for USB debugging was for debugging laptops that don’t have native serial ports anymore.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Monday, October 20, 2008 4:01 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Debugging Drivers

Doron Holan wrote:

Serial and 1394 are your best bets. Usb 2.0 debugging is nearly impossible to get right and is quite flakey in my experience. 1394 is the preferred option if the machine you are debugging has an open pci slot in which you can plug in a 1394 host controller card.

Doron, is this because it’s hard to find the right USB port - or
are there any problems *after* the connection over usb is up and working?

FWIW, there was a message recently in the windbg NG that
explains how to find the port #0 and even more, describes
the parameter to select the EHCI controller (when there are several).

Regards,
–PA

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

Calvin_Guan-2 · October 20, 2008, 5:34pm

>>Of the 3 transports, usb gets the least amount of attention internally at Microsoft.
?
That’s bad. For laptops don’t have serial port or 1394 port, it’s generally easy to put an add-in 1394 card so no big deal here.
?
The real pain in the ass is that some (and more and more) blade server vendors?remove the com port from their new designs, and there is no way you can add any PCI card on.
?
If msft could force vendors to put com port on their blade until they get the usb debugging right, that’d be nice-
?

Calvin Guan
Broadcom Corp.
Connecting Everything(r)
?

----- Original Message ----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Monday, October 20, 2008 1:10:54 PM
Subject: RE: Re:[ntdev] Debugging Drivers

Finding the right port can be evil. Many manufacturers do not expose it or have attached an embedded device to it.? The cable itself is not that reliable either.? Of the 3 transports, usb gets the least amount of attention internally at Microsoft.? The quality of the usb transport reflects its 3rd tier status, in part due to constrained dev resources and in part b/c the hardware is not that cooperative.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Monday, October 20, 2008 1:01 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Debugging Drivers

Doron Holan wrote:
> Serial and 1394 are your best bets.? Usb 2.0 debugging is nearly impossible to get right and is quite flakey in my experience.? 1394 is the preferred option if the machine you are debugging has an open pci slot in which you can plug in a 1394 host controller card.
>

Doron, is this because it’s hard to find the right USB port - or
are there any problems after the connection over usb is up and working?

FWIW, there was a message recently in the windbg NG that
explains how to find the port #0 and even more, describes
the parameter to select the EHCI controller (when there are several).

Regards,
–PA

—
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

—
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

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Tim_Roberts · October 20, 2008, 8:38pm

Don Burn wrote:

There is a USB solution but whether you can get it to work is highly
questionable. It has an extremely expensive cable required (you can buy two
1394 adapters from OSR and a 1394 cable for the same price as the USB
cable). The usb option also requires a specific configuration of USB which
many systems do not have.

I am being reminded again today about how delicate the 1394 solution
is. I have one high-powered test target machine (Dell Optiplex 755),
with a half-dozen bootable partitions. It includes an Agere 1394
controller chip. If I boot up XP on it, I can debug it over 1394 all
day – rock solid. If I boot up Vista without the kernel debugger
enabled, the 1394 controller comes up fine. But if I turn on the kernel
debugger in bcdedit, the “Intel 82801 PCI Bridge” comes up with a yellow
bang saying it can’t get enough resources, and the 1394 controller does
not appear in Device Manager at all.

Frustrating.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.