Both target and host are vista sp2+. Maybe there is something off about my
hardware setup…
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@evitechnology.com
Sent: Wednesday, September 09, 2009 5:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WdfRequestSend completion routine gives
status=0xC000000D urb USBD_STATUS=0x80000600
I don’t know the answer to this question, but I kind of doubt it, and
everything that I’ve heard about using USB with windbg hasn’t been good, and
that’s out of only a handful of cases, so I don’t think that I would try it
(expensive, hard to find cable as well) without some better information that
I can offer.
It’s been a while, but I definitely recall that at least during the Vista
beta cycle, a lot of people had this slow 1394 problem. Unfortunately, I
don’t recall what was doing it. It’s true that DbgPrint can be quite slow,
but what you’re describing sounds REALLY slow.
What’s your target OS?
I’d be curious to see how creating a crashdump over your connection would
go. At the speed your describing, it would take forever. I not all that
uncommonly create a full memory dump of an 8GB target, and that takes a
while, but many times less what it would at that rate, if my mental math is
correct (know to be dubious).
.dump /f
mm
—
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
Also, do you happen to know what chipset your 1394 card uses? If the answer isn’t TI, then if you get desperate, it might be worth replacing it with one that does.
You could also try to enable verbose debugging information (Ctrl+D) and/or protocol debugging (Ctrl+Alt+D) to see what’s happening on the line. This will however make your existing problem worse due to overload.
mm
I know that it’s not supposed to be necessary, but as it can’t hurt, I’d try disabling the 1394 card on the target, if you haven’t already.
mm
Whoops. I’m not sure what I was thinking, but the bit I wrote about spew/protocol debugging is incorrect. The former is controlled with ‘Ctrl+Alt+V’ and the later ‘Ctrl+Alt+D.’
My bad,
mm
Thanks.
I will try those things out, but for now, I think I’ll just live with what
I’ve got so I can focus on the real work…
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@evitechnology.com
Sent: Wednesday, September 09, 2009 5:43 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WdfRequestSend completion routine gives
status=0xC000000D urb USBD_STATUS=0x80000600
Whoops. I’m not sure what I was thinking, but the bit I wrote about
spew/protocol debugging is incorrect. The former is controlled with
‘Ctrl+Alt+V’ and the later ‘Ctrl+Alt+D.’
My bad,
mm
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
Not sure why you would expect WDF to tell you the frame time has passed, that is entirely a usb isoch concept that WDF is totally unaware of
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of pgruebele
Sent: Wednesday, September 09, 2009 2:05 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfRequestSend completion routine gives status=0xC000000D urb USBD_STATUS=0x80000600
Ok, I inadvertently solved the problem. I accidentally booted the target without debug mode, and it worked. It turns out that my DbgPrintEx statements were slowing the computer down enough to cause USB ISO to no longer work. I have removed some of these and now things work even when booting into debug mode.
I’m still surprised that I did not get any error messages, for example for
the specified frame time having passed etc… WDF/USB should have given
some kind of error. Would have saved me 10 hours of grief 
Thanks Doron, Tim, and Philip for helping me on this. As usual it turned out to be a simple solution!
On another note, I am surprised at how slow DbgPrintEx is considering I am using a 1394 debug cable. The host/target must not make full use of 1394 bandwidth.
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
It depends on what operation you are performing. If you are doing something that takes many round-trips to the debuggee (use Ctrl-Alt-D (windbg) or Ctrl-D (kd) to see), then performance will suffer.
The 1394 kd transport has a clever special optimization that none of the other debugger transports currently support: For raw physical memory reads, the debugger DMA’s the target"s physical memory directly off the wire rather than sending a readphysical command packet to the remote kd stub.
This makes bulk physical memory data transfers much faster on 1394, e.g. pool search or .dump or the like. AFAIK, USB does not have this (or other such) optimizations as a kd transport.
-----Original Message-----
From: pgruebele
Sent: Wednesday, September 09, 2009 14:16
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfRequestSend completion routine gives status=0xC000000D urb USBD_STATUS=0x80000600
Is there any way to modify the data rate used via 1394? Would a USB
connection be faster? USB might not be a good idea in my case since I’m
debugging a USB device.
My estimation is that the 1394 data rate is roughly equivalent to a 200KBaud
serial connection, which is pretty darn slow for such a high speed
interface.
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
I was referring to the USBD_STATUS_ISO_NOT_ACCESSED_LATE flag being returned
in the packet flag if the system was too late at sending the packet.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, September 09, 2009 5:16 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfRequestSend completion routine gives
status=0xC000000D urb USBD_STATUS=0x80000600
Not sure why you would expect WDF to tell you the frame time has passed,
that is entirely a usb isoch concept that WDF is totally unaware of
d
Again what would kmdf do with that? It is a client driver domain specific error, kmdf can do nothing generically with it. Kmdf has no special handling for any NTSTATUS code returned in an irp, it just gives the request back to the client to process the results
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: pgruebele
Sent: Thursday, September 10, 2009 9:04 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfRequestSend completion routine gives status=0xC000000D urb USBD_STATUS=0x80000600
I was referring to the USBD_STATUS_ISO_NOT_ACCESSED_LATE flag being returned
in the packet flag if the system was too late at sending the packet.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, September 09, 2009 5:16 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfRequestSend completion routine gives
status=0xC000000D urb USBD_STATUS=0x80000600
Not sure why you would expect WDF to tell you the frame time has passed,
that is entirely a usb isoch concept that WDF is totally unaware of
d
—
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
I understand that. What I meant is that this error should probably have
been returned to me in the packet status flag so that I know that the
problem I was experiencing was timing related (because the computer was
slowed down due to debug printing). I know KMDF could not do anything with
that flag, but I could… In other words, I should not have gotten zero
errors when no data was being transmitted. Obviously there was some sort of
error (timing related in this case)…
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, September 10, 2009 12:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfRequestSend completion routine gives
status=0xC000000D urb USBD_STATUS=0x80000600
Again what would kmdf do with that? It is a client driver domain specific
error, kmdf can do nothing generically with it. Kmdf has no special handling
for any NTSTATUS code returned in an irp, it just gives the request back to
the client to process the results
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: pgruebele
Sent: Thursday, September 10, 2009 9:04 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfRequestSend completion routine gives
status=0xC000000D urb USBD_STATUS=0x80000600
I was referring to the USBD_STATUS_ISO_NOT_ACCESSED_LATE flag being returned
in the packet flag if the system was too late at sending the packet.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, September 09, 2009 5:16 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfRequestSend completion routine gives
status=0xC000000D urb USBD_STATUS=0x80000600
Not sure why you would expect WDF to tell you the frame time has passed,
that is entirely a usb isoch concept that WDF is totally unaware of
d
—
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