Bugcheck CA on Vista X64

Gianluca_Varenni · May 14, 2009, 11:48am

Hi guys,

I just received a crash dump report with one of our USB products, and the
bugcheck is 0xCA, PNP_DETECTED_FATAL_ERROR.
“The PNP_DETECTED_FATAL_ERROR bug check has a value of 0x000000CA. This
indicates that the Plug and Play Manager encountered a severe error,
probably as a result of a problematic Plug and Play driver.”

The crash happened while connecting a USB hub to the PC and the USB hub had
three of our devices connected to the hub itself.

Below is the output of “analyze -v”, which seems to point the finger to
usbhub.sys, which enumerates the USB devices. Can my USB driver cause this
issue? Or it’s really a bug in the usbhub bus driver?

Thanks!
GV

3: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

PNP_DETECTED_FATAL_ERROR (ca)
PnP encountered a severe error, either as a result of a problem in a driver
or
a problem in PnP itself. The first argument describes the nature of the
problem, the second argument is the address of the PDO. The other arguments
vary depending on argument 1.
Arguments:
Arg1: 0000000000000001, Duplicate PDO
A specific instance of a driver has enumerated multiple PDOs with
identical device id and unique ids.
Arg2: fffffa8008037060, Newly reported PDO.
Arg3: fffffa80095214a0, PDO of which it is a duplicate.
Arg4: 0000000000000000

Debugging Details:

BUGCHECK_STR: 0xCA_1

DEVICE_OBJECT: fffffa8008037060

DRIVER_OBJECT: fffffa8006feb8c0

IMAGE_NAME: usbhub.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 479199e5

MODULE_NAME: usbhub

FAULTING_MODULE: fffffa6003a0c000 usbhub

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LOCK_ADDRESS: fffff80002446c20 – (!locks fffff80002446c20)

Resource @ nt!PiEngineLock (0xfffff80002446c20) Exclusively owned
Contention Count = 44
NumberOfExclusiveWaiters = 1
Threads: fffffa80039adbb0-01<*>
Threads Waiting On Exclusive Access:
fffffa80039ae720

1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0xfffff80002446c20
Thread Count : 1
Thread address: 0xfffffa80039adbb0
Thread wait : 0xf0ad1b

LAST_CONTROL_TRANSFER: from fffff8000267d058 to fffff8000229f650

STACK_TEXT:
fffffa6001bd4848 fffff8000267d058 : 00000000000000ca 0000000000000001
fffffa8008037060 fffffa80095214a0 : nt!KeBugCheckEx
fffffa6001bd4850 fffff8000268130e : fffffa80041d2010 fffffa8000000002
0000000000000000 0000000000000000 : nt!PiProcessNewDeviceNode+0x588
fffffa6001bd49c0 fffff800026817ea : fffffa800a436210 fffffa80039adbb0
fffffa60019d5cc0 0000000000000000 : nt!PipProcessDevNodeTree+0x2de
fffffa6001bd4c30 fffff80002378bad : fffff80100000003 fffffa8004711b80
0000000000000000 0000000032706e50 : nt!PiProcessReenumeration+0x8a
fffffa6001bd4c80 fffff800022ac366 : fffff80002378980 fffff800023dd801
fffff800023dd8f8 0000000000000001 : nt!PnpDeviceActionWorker+0x22d
fffffa6001bd4cf0 fffff800024c3fd3 : fffff800024445a0 3736353433323130
fffffa80039adbb0 0000000000000080 : nt!ExpWorkerThread+0x11a
fffffa6001bd4d50 fffff800022d9816 : fffffa60019d2180 fffffa80039adbb0
fffffa60019dbd40 0000000000000001 : nt!PspSystemThreadStartup+0x57
fffffa6001bd4d80 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys

BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys

Followup: MachineOwner

David_R_Cattley · May 14, 2009, 11:57am

Gianluca,

Does your hardware robustly report a unique ID?

I assume you have tried plugging in the hub without any devices and then one
by one adding in the (three) devices.

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Thursday, May 14, 2009 11:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Bugcheck CA on Vista X64

Hi guys,

I just received a crash dump report with one of our USB products, and the
bugcheck is 0xCA, PNP_DETECTED_FATAL_ERROR.
“The PNP_DETECTED_FATAL_ERROR bug check has a value of 0x000000CA. This
indicates that the Plug and Play Manager encountered a severe error,
probably as a result of a problematic Plug and Play driver.”

The crash happened while connecting a USB hub to the PC and the USB hub had
three of our devices connected to the hub itself.

Below is the output of “analyze -v”, which seems to point the finger to
usbhub.sys, which enumerates the USB devices. Can my USB driver cause this
issue? Or it’s really a bug in the usbhub bus driver?

Thanks!
GV

3: kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

PNP_DETECTED_FATAL_ERROR (ca)
PnP encountered a severe error, either as a result of a problem in a driver
or
a problem in PnP itself. The first argument describes the nature of the
problem, the second argument is the address of the PDO. The other arguments
vary depending on argument 1.
Arguments:
Arg1: 0000000000000001, Duplicate PDO
A specific instance of a driver has enumerated multiple PDOs with
identical device id and unique ids.
Arg2: fffffa8008037060, Newly reported PDO.
Arg3: fffffa80095214a0, PDO of which it is a duplicate.
Arg4: 0000000000000000

Debugging Details:

BUGCHECK_STR: 0xCA_1

DEVICE_OBJECT: fffffa8008037060

DRIVER_OBJECT: fffffa8006feb8c0

IMAGE_NAME: usbhub.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 479199e5

MODULE_NAME: usbhub

FAULTING_MODULE: fffffa6003a0c000 usbhub

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LOCK_ADDRESS: fffff80002446c20 – (!locks fffff80002446c20)

Resource @ nt!PiEngineLock (0xfffff80002446c20) Exclusively owned
Contention Count = 44
NumberOfExclusiveWaiters = 1
Threads: fffffa80039adbb0-01<*>
Threads Waiting On Exclusive Access:
fffffa80039ae720

1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0xfffff80002446c20
Thread Count : 1
Thread address: 0xfffffa80039adbb0
Thread wait : 0xf0ad1b

LAST_CONTROL_TRANSFER: from fffff8000267d058 to fffff8000229f650

STACK_TEXT:
fffffa6001bd4848 fffff8000267d058 : 00000000000000ca 0000000000000001
fffffa8008037060 fffffa80095214a0 : nt!KeBugCheckEx
fffffa6001bd4850 fffff8000268130e : fffffa80041d2010 fffffa8000000002
0000000000000000 0000000000000000 : nt!PiProcessNewDeviceNode+0x588
fffffa6001bd49c0 fffff800026817ea : fffffa800a436210 fffffa80039adbb0
fffffa60019d5cc0 0000000000000000 : nt!PipProcessDevNodeTree+0x2de
fffffa6001bd4c30 fffff80002378bad : fffff80100000003 fffffa8004711b80
0000000000000000 0000000032706e50 : nt!PiProcessReenumeration+0x8a
fffffa6001bd4c80 fffff800022ac366 : fffff80002378980 fffff800023dd801
fffff800023dd8f8 0000000000000001 : nt!PnpDeviceActionWorker+0x22d
fffffa6001bd4cf0 fffff800024c3fd3 : fffff800024445a0 3736353433323130
fffffa80039adbb0 0000000000000080 : nt!ExpWorkerThread+0x11a
fffffa6001bd4d50 fffff800022d9816 : fffffa60019d2180 fffffa80039adbb0
fffffa60019dbd40 0000000000000001 : nt!PspSystemThreadStartup+0x57
fffffa6001bd4d80 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys

BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys

Followup: MachineOwner

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

Gianluca_Varenni · May 14, 2009, 12:44pm

----- Original Message -----
From: “David R. Cattley”
To: “Windows System Software Devs Interest List”
Sent: Thursday, May 14, 2009 8:56 AM
Subject: RE: [ntdev] Bugcheck CA on Vista X64

> Gianluca,
>
> Does your hardware robustly report a unique ID?
>

Our hardware doesn’t have a unique ID, all the devices have the same ID,
12345. Can a device without a unique ID cause such troubles?

> I assume you have tried plugging in the hub without any devices and then
> one
> by one adding in the (three) devices.

This crash happened randomly, it’s not consistent. I tried plugging the hub
and the devices one by one, and nothing bad happened. I tried connecting the
hub with the three devices on, and it didn’t crash.

Have a nice day
GV

>
> -dave
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
> Sent: Thursday, May 14, 2009 11:48 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Bugcheck CA on Vista X64
>
> Hi guys,
>
> I just received a crash dump report with one of our USB products, and the
> bugcheck is 0xCA, PNP_DETECTED_FATAL_ERROR.
> “The PNP_DETECTED_FATAL_ERROR bug check has a value of 0x000000CA. This
> indicates that the Plug and Play Manager encountered a severe error,
> probably as a result of a problematic Plug and Play driver.”
>
> The crash happened while connecting a USB hub to the PC and the USB hub
> had
> three of our devices connected to the hub itself.
>
> Below is the output of “analyze -v”, which seems to point the finger to
> usbhub.sys, which enumerates the USB devices. Can my USB driver cause this
> issue? Or it’s really a bug in the usbhub bus driver?
>
> Thanks!
> GV
>
>
>
>
> 3: kd> !analyze -v
> *************************************************************************
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> ************************************************************************
>
>
> PNP_DETECTED_FATAL_ERROR (ca)
> PnP encountered a severe error, either as a result of a problem in a
> driver
> or
> a problem in PnP itself. The first argument describes the nature of the
> problem, the second argument is the address of the PDO. The other
> arguments
> vary depending on argument 1.
> Arguments:
> Arg1: 0000000000000001, Duplicate PDO
> A specific instance of a driver has enumerated multiple PDOs with
> identical device id and unique ids.
> Arg2: fffffa8008037060, Newly reported PDO.
> Arg3: fffffa80095214a0, PDO of which it is a duplicate.
> Arg4: 0000000000000000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0xCA_1
>
> DEVICE_OBJECT: fffffa8008037060
>
> DRIVER_OBJECT: fffffa8006feb8c0
>
> IMAGE_NAME: usbhub.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 479199e5
>
> MODULE_NAME: usbhub
>
> FAULTING_MODULE: fffffa6003a0c000 usbhub
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 0
>
> LOCK_ADDRESS: fffff80002446c20 – (!locks fffff80002446c20)
>
> Resource @ nt!PiEngineLock (0xfffff80002446c20) Exclusively owned
> Contention Count = 44
> NumberOfExclusiveWaiters = 1
> Threads: fffffa80039adbb0-01<>
> Threads Waiting On Exclusive Access:
> fffffa80039ae720
>
> 1 total locks, 1 locks currently held
>
> PNP_TRIAGE:
> Lock address : 0xfffff80002446c20
> Thread Count : 1
> Thread address: 0xfffffa80039adbb0
> Thread wait : 0xf0ad1b
>
> LAST_CONTROL_TRANSFER: from fffff8000267d058 to fffff8000229f650
>
> STACK_TEXT:
> fffffa6001bd4848 fffff8000267d058 : 00000000000000ca 0000000000000001
> fffffa8008037060 fffffa80095214a0 : nt!KeBugCheckEx
> fffffa6001bd4850 fffff8000268130e : fffffa80041d2010 fffffa8000000002
> 0000000000000000 0000000000000000 : nt!PiProcessNewDeviceNode+0x588
> fffffa6001bd49c0 fffff800026817ea : fffffa800a436210 fffffa80039adbb0
> fffffa60019d5cc0 0000000000000000 : nt!PipProcessDevNodeTree+0x2de
> fffffa6001bd4c30 fffff80002378bad : fffff80100000003 fffffa8004711b80
> 0000000000000000 0000000032706e50 : nt!PiProcessReenumeration+0x8a
> fffffa6001bd4c80 fffff800022ac366 : fffff80002378980 fffff800023dd801
> fffff800023dd8f8 0000000000000001 : nt!PnpDeviceActionWorker+0x22d
> fffffa6001bd4cf0 fffff800024c3fd3 : fffff800024445a0 3736353433323130
> fffffa80039adbb0 0000000000000080 : nt!ExpWorkerThread+0x11a
> fffffa6001bd4d50 fffff800022d9816 : fffffa60019d2180 fffffa80039adbb0
> fffffa60019dbd40 0000000000000001 : nt!PspSystemThreadStartup+0x57
> fffffa6001bd4d80 0000000000000000 : 0000000000000000 0000000000000000
> 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_NAME: MachineOwner
>
> FAILURE_BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys
>
> BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> 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

David_R_Cattley · May 14, 2009, 12:48pm

I am not a USB expert but I think the situation you have is that they all
have the same (quite non) unique id. I am guessing that Windows has some
counter-measure logic to deal with this but AFAIK ‘unique’ is supposed to be
just that so that the USB system can assign a ‘port-independent’ Instance Id
to the PDO and thus make it possible to plug the device into any port and
get the same DevNode (stack) instance identified.

There have been other references in the list to device that did not do this
and the challenges of making multiple devices work correctly.

Perhaps the challenge (to USBxxx.SYS) of dealing with *many* such insertions
all at once causes a race not well dealt with.

Good Luck,
-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Thursday, May 14, 2009 12:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Bugcheck CA on Vista X64

----- Original Message -----
From: “David R. Cattley”
To: “Windows System Software Devs Interest List”
Sent: Thursday, May 14, 2009 8:56 AM
Subject: RE: [ntdev] Bugcheck CA on Vista X64

> Gianluca,
>
> Does your hardware robustly report a unique ID?
>

Our hardware doesn’t have a unique ID, all the devices have the same ID,
12345. Can a device without a unique ID cause such troubles?

> I assume you have tried plugging in the hub without any devices and then
> one
> by one adding in the (three) devices.

This crash happened randomly, it’s not consistent. I tried plugging the hub
and the devices one by one, and nothing bad happened. I tried connecting the

hub with the three devices on, and it didn’t crash.

Have a nice day
GV

>
> -dave
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
> Sent: Thursday, May 14, 2009 11:48 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Bugcheck CA on Vista X64
>
> Hi guys,
>
> I just received a crash dump report with one of our USB products, and the
> bugcheck is 0xCA, PNP_DETECTED_FATAL_ERROR.
> “The PNP_DETECTED_FATAL_ERROR bug check has a value of 0x000000CA. This
> indicates that the Plug and Play Manager encountered a severe error,
> probably as a result of a problematic Plug and Play driver.”
>
> The crash happened while connecting a USB hub to the PC and the USB hub
> had
> three of our devices connected to the hub itself.
>
> Below is the output of “analyze -v”, which seems to point the finger to
> usbhub.sys, which enumerates the USB devices. Can my USB driver cause this
> issue? Or it’s really a bug in the usbhub bus driver?
>
> Thanks!
> GV
>
>
>
>
> 3: kd> !analyze -v
>
*************************************************************************
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
>
************************************************************************
>
>
> PNP_DETECTED_FATAL_ERROR (ca)
> PnP encountered a severe error, either as a result of a problem in a
> driver
> or
> a problem in PnP itself. The first argument describes the nature of the
> problem, the second argument is the address of the PDO. The other
> arguments
> vary depending on argument 1.
> Arguments:
> Arg1: 0000000000000001, Duplicate PDO
> A specific instance of a driver has enumerated multiple PDOs with
> identical device id and unique ids.
> Arg2: fffffa8008037060, Newly reported PDO.
> Arg3: fffffa80095214a0, PDO of which it is a duplicate.
> Arg4: 0000000000000000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0xCA_1
>
> DEVICE_OBJECT: fffffa8008037060
>
> DRIVER_OBJECT: fffffa8006feb8c0
>
> IMAGE_NAME: usbhub.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 479199e5
>
> MODULE_NAME: usbhub
>
> FAULTING_MODULE: fffffa6003a0c000 usbhub
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 0
>
> LOCK_ADDRESS: fffff80002446c20 – (!locks fffff80002446c20)
>
> Resource @ nt!PiEngineLock (0xfffff80002446c20) Exclusively owned
> Contention Count = 44
> NumberOfExclusiveWaiters = 1
> Threads: fffffa80039adbb0-01<>
> Threads Waiting On Exclusive Access:
> fffffa80039ae720
>
> 1 total locks, 1 locks currently held
>
> PNP_TRIAGE:
> Lock address : 0xfffff80002446c20
> Thread Count : 1
> Thread address: 0xfffffa80039adbb0
> Thread wait : 0xf0ad1b
>
> LAST_CONTROL_TRANSFER: from fffff8000267d058 to fffff8000229f650
>
> STACK_TEXT:
> fffffa6001bd4848 fffff8000267d058 : 00000000000000ca 0000000000000001
> fffffa8008037060 fffffa80095214a0 : nt!KeBugCheckEx
> fffffa6001bd4850 fffff8000268130e : fffffa80041d2010 fffffa8000000002
> 0000000000000000 0000000000000000 : nt!PiProcessNewDeviceNode+0x588
> fffffa6001bd49c0 fffff800026817ea : fffffa800a436210 fffffa80039adbb0
> fffffa60019d5cc0 0000000000000000 : nt!PipProcessDevNodeTree+0x2de
> fffffa6001bd4c30 fffff80002378bad : fffff80100000003 fffffa8004711b80
> 0000000000000000 0000000032706e50 : nt!PiProcessReenumeration+0x8a
> fffffa6001bd4c80 fffff800022ac366 : fffff80002378980 fffff800023dd801
> fffff800023dd8f8 0000000000000001 : nt!PnpDeviceActionWorker+0x22d
> fffffa6001bd4cf0 fffff800024c3fd3 : fffff800024445a0 3736353433323130
> fffffa80039adbb0 0000000000000080 : nt!ExpWorkerThread+0x11a
> fffffa6001bd4d50 fffff800022d9816 : fffffa60019d2180 fffffa80039adbb0
> fffffa60019dbd40 0000000000000001 : nt!PspSystemThreadStartup+0x57
> fffffa6001bd4d80 0000000000000000 : 0000000000000000 0000000000000000
> 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_NAME: MachineOwner
>
> FAILURE_BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys
>
> BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> 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

—
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

Doron_Holan · May 14, 2009, 1:04pm

The usb core does have logic that will fix up busted devices which report the same serial number. My guess aligns with David’s in that the logic does not quite work if all the busted devices show up at once under a new hub.

Gianluca, the IDs will eventually be fixed right?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Thursday, May 14, 2009 9:48 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bugcheck CA on Vista X64

I am not a USB expert but I think the situation you have is that they all
have the same (quite non) unique id. I am guessing that Windows has some
counter-measure logic to deal with this but AFAIK ‘unique’ is supposed to be
just that so that the USB system can assign a ‘port-independent’ Instance Id
to the PDO and thus make it possible to plug the device into any port and
get the same DevNode (stack) instance identified.

There have been other references in the list to device that did not do this
and the challenges of making multiple devices work correctly.

Perhaps the challenge (to USBxxx.SYS) of dealing with *many* such insertions
all at once causes a race not well dealt with.

Good Luck,
-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Thursday, May 14, 2009 12:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Bugcheck CA on Vista X64

----- Original Message -----
From: “David R. Cattley”
To: “Windows System Software Devs Interest List”
Sent: Thursday, May 14, 2009 8:56 AM
Subject: RE: [ntdev] Bugcheck CA on Vista X64

> Gianluca,
>
> Does your hardware robustly report a unique ID?
>

Our hardware doesn’t have a unique ID, all the devices have the same ID,
12345. Can a device without a unique ID cause such troubles?

> I assume you have tried plugging in the hub without any devices and then
> one
> by one adding in the (three) devices.

This crash happened randomly, it’s not consistent. I tried plugging the hub
and the devices one by one, and nothing bad happened. I tried connecting the

hub with the three devices on, and it didn’t crash.

Have a nice day
GV

>
> -dave
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
> Sent: Thursday, May 14, 2009 11:48 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Bugcheck CA on Vista X64
>
> Hi guys,
>
> I just received a crash dump report with one of our USB products, and the
> bugcheck is 0xCA, PNP_DETECTED_FATAL_ERROR.
> “The PNP_DETECTED_FATAL_ERROR bug check has a value of 0x000000CA. This
> indicates that the Plug and Play Manager encountered a severe error,
> probably as a result of a problematic Plug and Play driver.”
>
> The crash happened while connecting a USB hub to the PC and the USB hub
> had
> three of our devices connected to the hub itself.
>
> Below is the output of “analyze -v”, which seems to point the finger to
> usbhub.sys, which enumerates the USB devices. Can my USB driver cause this
> issue? Or it’s really a bug in the usbhub bus driver?
>
> Thanks!
> GV
>
>
>
>
> 3: kd> !analyze -v
>
*************************************************************************
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
>
************************************************************************
>
>
> PNP_DETECTED_FATAL_ERROR (ca)
> PnP encountered a severe error, either as a result of a problem in a
> driver
> or
> a problem in PnP itself. The first argument describes the nature of the
> problem, the second argument is the address of the PDO. The other
> arguments
> vary depending on argument 1.
> Arguments:
> Arg1: 0000000000000001, Duplicate PDO
> A specific instance of a driver has enumerated multiple PDOs with
> identical device id and unique ids.
> Arg2: fffffa8008037060, Newly reported PDO.
> Arg3: fffffa80095214a0, PDO of which it is a duplicate.
> Arg4: 0000000000000000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0xCA_1
>
> DEVICE_OBJECT: fffffa8008037060
>
> DRIVER_OBJECT: fffffa8006feb8c0
>
> IMAGE_NAME: usbhub.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 479199e5
>
> MODULE_NAME: usbhub
>
> FAULTING_MODULE: fffffa6003a0c000 usbhub
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 0
>
> LOCK_ADDRESS: fffff80002446c20 – (!locks fffff80002446c20)
>
> Resource @ nt!PiEngineLock (0xfffff80002446c20) Exclusively owned
> Contention Count = 44
> NumberOfExclusiveWaiters = 1
> Threads: fffffa80039adbb0-01<>
> Threads Waiting On Exclusive Access:
> fffffa80039ae720
>
> 1 total locks, 1 locks currently held
>
> PNP_TRIAGE:
> Lock address : 0xfffff80002446c20
> Thread Count : 1
> Thread address: 0xfffffa80039adbb0
> Thread wait : 0xf0ad1b
>
> LAST_CONTROL_TRANSFER: from fffff8000267d058 to fffff8000229f650
>
> STACK_TEXT:
> fffffa6001bd4848 fffff8000267d058 : 00000000000000ca 0000000000000001
> fffffa8008037060 fffffa80095214a0 : nt!KeBugCheckEx
> fffffa6001bd4850 fffff8000268130e : fffffa80041d2010 fffffa8000000002
> 0000000000000000 0000000000000000 : nt!PiProcessNewDeviceNode+0x588
> fffffa6001bd49c0 fffff800026817ea : fffffa800a436210 fffffa80039adbb0
> fffffa60019d5cc0 0000000000000000 : nt!PipProcessDevNodeTree+0x2de
> fffffa6001bd4c30 fffff80002378bad : fffff80100000003 fffffa8004711b80
> 0000000000000000 0000000032706e50 : nt!PiProcessReenumeration+0x8a
> fffffa6001bd4c80 fffff800022ac366 : fffff80002378980 fffff800023dd801
> fffff800023dd8f8 0000000000000001 : nt!PnpDeviceActionWorker+0x22d
> fffffa6001bd4cf0 fffff800024c3fd3 : fffff800024445a0 3736353433323130
> fffffa80039adbb0 0000000000000080 : nt!ExpWorkerThread+0x11a
> fffffa6001bd4d50 fffff800022d9816 : fffffa60019d2180 fffffa80039adbb0
> fffffa60019dbd40 0000000000000001 : nt!PspSystemThreadStartup+0x57
> fffffa6001bd4d80 0000000000000000 : 0000000000000000 0000000000000000
> 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_NAME: MachineOwner
>
> FAILURE_BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys
>
> BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> 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

—
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

Tim_Roberts · May 14, 2009, 1:24pm

Doron Holan wrote:

The usb core does have logic that will fix up busted devices which report the same serial number. My guess aligns with David’s in that the logic does not quite work if all the busted devices show up at once under a new hub.

Gianluca, the IDs will eventually be fixed right?

In the short term, you can work around this by simply setting the serial
number string descriptor number (iSerialNumber in the device descriptor)
to 0, which means “I don’t have a serial number.”

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

Gianluca_Varenni · May 14, 2009, 1:28pm

Well, we do not manufacture the hardware directly, and so far we have never
reprogrammed the unique ID. The device is basically a wireless adapter (with
a custom non-NDIS driver), and the manufacturer programs each device with a
different MAC but leaves the unique ID set to 12345 (because this is
probably what the chip manufacturer told them to do in their reference
designs).
We can definitely reprogram the adapters that we are selling now with the
MAC address as the unique ID (it’s my understanding that the unique ID is
just a string). But we already have literally thousands of customers which
have devices all with the same unique ID.

Just so that it’s clear to me, is it a requirement to a unique ID for every
device? I’ve seen that even big manufacturers ship all their devices with
the same unique ID. Can the usbcore distinguish the various devices from
their position on the USB bus, exactly like PCI?

Have a nice day
GV

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Thursday, May 14, 2009 9:55 AM
Subject: RE: [ntdev] Bugcheck CA on Vista X64

The usb core does have logic that will fix up busted devices which report
the same serial number. My guess aligns with David’s in that the logic does
not quite work if all the busted devices show up at once under a new hub.

Gianluca, the IDs will eventually be fixed right?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Thursday, May 14, 2009 9:48 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bugcheck CA on Vista X64

I am not a USB expert but I think the situation you have is that they all
have the same (quite non) unique id. I am guessing that Windows has some
counter-measure logic to deal with this but AFAIK ‘unique’ is supposed to be
just that so that the USB system can assign a ‘port-independent’ Instance Id
to the PDO and thus make it possible to plug the device into any port and
get the same DevNode (stack) instance identified.

There have been other references in the list to device that did not do this
and the challenges of making multiple devices work correctly.

Perhaps the challenge (to USBxxx.SYS) of dealing with many such insertions
all at once causes a race not well dealt with.

Good Luck,
-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Thursday, May 14, 2009 12:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Bugcheck CA on Vista X64

----- Original Message -----
From: “David R. Cattley”
To: “Windows System Software Devs Interest List”
Sent: Thursday, May 14, 2009 8:56 AM
Subject: RE: [ntdev] Bugcheck CA on Vista X64

> Gianluca,
>
> Does your hardware robustly report a unique ID?
>

Our hardware doesn’t have a unique ID, all the devices have the same ID,
12345. Can a device without a unique ID cause such troubles?

> I assume you have tried plugging in the hub without any devices and then
> one
> by one adding in the (three) devices.

This crash happened randomly, it’s not consistent. I tried plugging the hub
and the devices one by one, and nothing bad happened. I tried connecting the

hub with the three devices on, and it didn’t crash.

Have a nice day
GV

>
> -dave
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
> Sent: Thursday, May 14, 2009 11:48 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Bugcheck CA on Vista X64
>
> Hi guys,
>
> I just received a crash dump report with one of our USB products, and the
> bugcheck is 0xCA, PNP_DETECTED_FATAL_ERROR.
> “The PNP_DETECTED_FATAL_ERROR bug check has a value of 0x000000CA. This
> indicates that the Plug and Play Manager encountered a severe error,
> probably as a result of a problematic Plug and Play driver.”
>
> The crash happened while connecting a USB hub to the PC and the USB hub
> had
> three of our devices connected to the hub itself.
>
> Below is the output of “analyze -v”, which seems to point the finger to
> usbhub.sys, which enumerates the USB devices. Can my USB driver cause this
> issue? Or it’s really a bug in the usbhub bus driver?
>
> Thanks!
> GV
>
>
>
>
> 3: kd> !analyze -v
>
*************************************************************************
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
>
************************************************************************
>
>
> PNP_DETECTED_FATAL_ERROR (ca)
> PnP encountered a severe error, either as a result of a problem in a
> driver
> or
> a problem in PnP itself. The first argument describes the nature of the
> problem, the second argument is the address of the PDO. The other
> arguments
> vary depending on argument 1.
> Arguments:
> Arg1: 0000000000000001, Duplicate PDO
> A specific instance of a driver has enumerated multiple PDOs with
> identical device id and unique ids.
> Arg2: fffffa8008037060, Newly reported PDO.
> Arg3: fffffa80095214a0, PDO of which it is a duplicate.
> Arg4: 0000000000000000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0xCA_1
>
> DEVICE_OBJECT: fffffa8008037060
>
> DRIVER_OBJECT: fffffa8006feb8c0
>
> IMAGE_NAME: usbhub.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 479199e5
>
> MODULE_NAME: usbhub
>
> FAULTING_MODULE: fffffa6003a0c000 usbhub
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 0
>
> LOCK_ADDRESS: fffff80002446c20 – (!locks fffff80002446c20)
>
> Resource @ nt!PiEngineLock (0xfffff80002446c20) Exclusively owned
> Contention Count = 44
> NumberOfExclusiveWaiters = 1
> Threads: fffffa80039adbb0-01<>
> Threads Waiting On Exclusive Access:
> fffffa80039ae720
>
> 1 total locks, 1 locks currently held
>
> PNP_TRIAGE:
> Lock address : 0xfffff80002446c20
> Thread Count : 1
> Thread address: 0xfffffa80039adbb0
> Thread wait : 0xf0ad1b
>
> LAST_CONTROL_TRANSFER: from fffff8000267d058 to fffff8000229f650
>
> STACK_TEXT:
> fffffa6001bd4848 fffff8000267d058 : 00000000000000ca 0000000000000001
> fffffa8008037060 fffffa80095214a0 : nt!KeBugCheckEx
> fffffa6001bd4850 fffff8000268130e : fffffa80041d2010 fffffa8000000002
> 0000000000000000 0000000000000000 : nt!PiProcessNewDeviceNode+0x588
> fffffa6001bd49c0 fffff800026817ea : fffffa800a436210 fffffa80039adbb0
> fffffa60019d5cc0 0000000000000000 : nt!PipProcessDevNodeTree+0x2de
> fffffa6001bd4c30 fffff80002378bad : fffff80100000003 fffffa8004711b80
> 0000000000000000 0000000032706e50 : nt!PiProcessReenumeration+0x8a
> fffffa6001bd4c80 fffff800022ac366 : fffff80002378980 fffff800023dd801
> fffff800023dd8f8 0000000000000001 : nt!PnpDeviceActionWorker+0x22d
> fffffa6001bd4cf0 fffff800024c3fd3 : fffff800024445a0 3736353433323130
> fffffa80039adbb0 0000000000000080 : nt!ExpWorkerThread+0x11a
> fffffa6001bd4d50 fffff800022d9816 : fffffa60019d2180 fffffa80039adbb0
> fffffa60019dbd40 0000000000000001 : nt!PspSystemThreadStartup+0x57
> fffffa6001bd4d80 0000000000000000 : 0000000000000000 0000000000000000
> 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_NAME: MachineOwner
>
> FAILURE_BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys
>
> BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> 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

—
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

—
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

Thomas_Divine-2 · May 14, 2009, 1:34pm

I am not at all surprised at bad behavior when you have multiple USB devices
that do not have unique USB serial numbers.

I had one customer who wanted a driver that basically worked with 24 USB
Ethernet devices connected to a tree of hubs. (Understand that is RARE to
find USB Ethernet adapters that have unique USB serial numbers…)

Under controlled conditions with orderly insertion of the devices all was
well. However, when a new hub with multiple devices was presented to the
system chaos often ensues. Having unique USB serial numbers improves the
situation, BUT the scheme always had a problem of one sort or another when
order of insertion was changed or other USB devices were added to the mix.

There were occasional bugchecks in usbhub.sys - even on XP 32 - if you test
like a typical end-user. Being a “little guy” with a product of limited
distribution (and with XP SP 3 released) there was no practical expectation
of fixing this bug.

I suggest that 1.) you provide unique USB serial numbers to your devices and
2.) you provide documentation that recommends a systematic order for
insertion and removal of your devices.

Good luck!

(And more luck if you start working with 11 concurrent AirPCaps…)

Thomas F. Divine

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Thursday, May 14, 2009 11:56 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bugcheck CA on Vista X64

Gianluca,

Does your hardware robustly report a unique ID?

I assume you have tried plugging in the hub without any devices and then one
by one adding in the (three) devices.

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Thursday, May 14, 2009 11:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Bugcheck CA on Vista X64

Hi guys,

I just received a crash dump report with one of our USB products, and the
bugcheck is 0xCA, PNP_DETECTED_FATAL_ERROR.
“The PNP_DETECTED_FATAL_ERROR bug check has a value of 0x000000CA. This
indicates that the Plug and Play Manager encountered a severe error,
probably as a result of a problematic Plug and Play driver.”

The crash happened while connecting a USB hub to the PC and the USB hub had
three of our devices connected to the hub itself.

Below is the output of “analyze -v”, which seems to point the finger to
usbhub.sys, which enumerates the USB devices. Can my USB driver cause this
issue? Or it’s really a bug in the usbhub bus driver?

Thanks!
GV

3: kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

PNP_DETECTED_FATAL_ERROR (ca)
PnP encountered a severe error, either as a result of a problem in a driver
or
a problem in PnP itself. The first argument describes the nature of the
problem, the second argument is the address of the PDO. The other arguments
vary depending on argument 1.
Arguments:
Arg1: 0000000000000001, Duplicate PDO
A specific instance of a driver has enumerated multiple PDOs with
identical device id and unique ids.
Arg2: fffffa8008037060, Newly reported PDO.
Arg3: fffffa80095214a0, PDO of which it is a duplicate.
Arg4: 0000000000000000

Debugging Details:

BUGCHECK_STR: 0xCA_1

DEVICE_OBJECT: fffffa8008037060

DRIVER_OBJECT: fffffa8006feb8c0

IMAGE_NAME: usbhub.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 479199e5

MODULE_NAME: usbhub

FAULTING_MODULE: fffffa6003a0c000 usbhub

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LOCK_ADDRESS: fffff80002446c20 – (!locks fffff80002446c20)

Resource @ nt!PiEngineLock (0xfffff80002446c20) Exclusively owned
Contention Count = 44
NumberOfExclusiveWaiters = 1
Threads: fffffa80039adbb0-01<*>
Threads Waiting On Exclusive Access:
fffffa80039ae720

1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0xfffff80002446c20
Thread Count : 1
Thread address: 0xfffffa80039adbb0
Thread wait : 0xf0ad1b

LAST_CONTROL_TRANSFER: from fffff8000267d058 to fffff8000229f650

STACK_TEXT:
fffffa6001bd4848 fffff8000267d058 : 00000000000000ca 0000000000000001
fffffa8008037060 fffffa80095214a0 : nt!KeBugCheckEx
fffffa6001bd4850 fffff8000268130e : fffffa80041d2010 fffffa8000000002
0000000000000000 0000000000000000 : nt!PiProcessNewDeviceNode+0x588
fffffa6001bd49c0 fffff800026817ea : fffffa800a436210 fffffa80039adbb0
fffffa60019d5cc0 0000000000000000 : nt!PipProcessDevNodeTree+0x2de
fffffa6001bd4c30 fffff80002378bad : fffff80100000003 fffffa8004711b80
0000000000000000 0000000032706e50 : nt!PiProcessReenumeration+0x8a
fffffa6001bd4c80 fffff800022ac366 : fffff80002378980 fffff800023dd801
fffff800023dd8f8 0000000000000001 : nt!PnpDeviceActionWorker+0x22d
fffffa6001bd4cf0 fffff800024c3fd3 : fffff800024445a0 3736353433323130
fffffa80039adbb0 0000000000000080 : nt!ExpWorkerThread+0x11a
fffffa6001bd4d50 fffff800022d9816 : fffffa60019d2180 fffffa80039adbb0
fffffa60019dbd40 0000000000000001 : nt!PspSystemThreadStartup+0x57
fffffa6001bd4d80 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys

BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys

Followup: MachineOwner

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

Gianluca_Varenni · May 14, 2009, 1:38pm

----- Original Message -----
From: “Thomas F. Divine”
To: “Windows System Software Devs Interest List”
Sent: Thursday, May 14, 2009 10:33 AM
Subject: RE: [ntdev] Bugcheck CA on Vista X64

>I am not at all surprised at bad behavior when you have multiple USB
>devices
> that do not have unique USB serial numbers.
>
> I had one customer who wanted a driver that basically worked with 24 USB
> Ethernet devices connected to a tree of hubs. (Understand that is RARE to
> find USB Ethernet adapters that have unique USB serial numbers…)
>
> Under controlled conditions with orderly insertion of the devices all was
> well. However, when a new hub with multiple devices was presented to the
> system chaos often ensues. Having unique USB serial numbers improves the
> situation, BUT the scheme always had a problem of one sort or another when
> order of insertion was changed or other USB devices were added to the mix.
>
> There were occasional bugchecks in usbhub.sys - even on XP 32 - if you
> test
> like a typical end-user. Being a “little guy” with a product of limited
> distribution (and with XP SP 3 released) there was no practical
> expectation
> of fixing this bug.
>
> I suggest that 1.) you provide unique USB serial numbers to your devices
> and
> 2.) you provide documentation that recommends a systematic order for
> insertion and removal of your devices.
>
> Good luck!
>
> (And more luck if you start working with 11 concurrent AirPCaps…)

Are you? I think I maxed out to 8 AirPcap adapters…

Have a nice day
GV

>
> Thomas F. Divine
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
> Sent: Thursday, May 14, 2009 11:56 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Bugcheck CA on Vista X64
>
> Gianluca,
>
> Does your hardware robustly report a unique ID?
>
> I assume you have tried plugging in the hub without any devices and then
> one
> by one adding in the (three) devices.
>
> -dave
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
> Sent: Thursday, May 14, 2009 11:48 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Bugcheck CA on Vista X64
>
> Hi guys,
>
> I just received a crash dump report with one of our USB products, and the
> bugcheck is 0xCA, PNP_DETECTED_FATAL_ERROR.
> “The PNP_DETECTED_FATAL_ERROR bug check has a value of 0x000000CA. This
> indicates that the Plug and Play Manager encountered a severe error,
> probably as a result of a problematic Plug and Play driver.”
>
> The crash happened while connecting a USB hub to the PC and the USB hub
> had
> three of our devices connected to the hub itself.
>
> Below is the output of “analyze -v”, which seems to point the finger to
> usbhub.sys, which enumerates the USB devices. Can my USB driver cause this
> issue? Or it’s really a bug in the usbhub bus driver?
>
> Thanks!
> GV
>
>
>
>
> 3: kd> !analyze -v
> *************************************************************************
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> ************************************************************************
>
>
> PNP_DETECTED_FATAL_ERROR (ca)
> PnP encountered a severe error, either as a result of a problem in a
> driver
> or
> a problem in PnP itself. The first argument describes the nature of the
> problem, the second argument is the address of the PDO. The other
> arguments
> vary depending on argument 1.
> Arguments:
> Arg1: 0000000000000001, Duplicate PDO
> A specific instance of a driver has enumerated multiple PDOs with
> identical device id and unique ids.
> Arg2: fffffa8008037060, Newly reported PDO.
> Arg3: fffffa80095214a0, PDO of which it is a duplicate.
> Arg4: 0000000000000000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0xCA_1
>
> DEVICE_OBJECT: fffffa8008037060
>
> DRIVER_OBJECT: fffffa8006feb8c0
>
> IMAGE_NAME: usbhub.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 479199e5
>
> MODULE_NAME: usbhub
>
> FAULTING_MODULE: fffffa6003a0c000 usbhub
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 0
>
> LOCK_ADDRESS: fffff80002446c20 – (!locks fffff80002446c20)
>
> Resource @ nt!PiEngineLock (0xfffff80002446c20) Exclusively owned
> Contention Count = 44
> NumberOfExclusiveWaiters = 1
> Threads: fffffa80039adbb0-01<>
> Threads Waiting On Exclusive Access:
> fffffa80039ae720
>
> 1 total locks, 1 locks currently held
>
> PNP_TRIAGE:
> Lock address : 0xfffff80002446c20
> Thread Count : 1
> Thread address: 0xfffffa80039adbb0
> Thread wait : 0xf0ad1b
>
> LAST_CONTROL_TRANSFER: from fffff8000267d058 to fffff8000229f650
>
> STACK_TEXT:
> fffffa6001bd4848 fffff8000267d058 : 00000000000000ca 0000000000000001
> fffffa8008037060 fffffa80095214a0 : nt!KeBugCheckEx
> fffffa6001bd4850 fffff8000268130e : fffffa80041d2010 fffffa8000000002
> 0000000000000000 0000000000000000 : nt!PiProcessNewDeviceNode+0x588
> fffffa6001bd49c0 fffff800026817ea : fffffa800a436210 fffffa80039adbb0
> fffffa60019d5cc0 0000000000000000 : nt!PipProcessDevNodeTree+0x2de
> fffffa6001bd4c30 fffff80002378bad : fffff80100000003 fffffa8004711b80
> 0000000000000000 0000000032706e50 : nt!PiProcessReenumeration+0x8a
> fffffa6001bd4c80 fffff800022ac366 : fffff80002378980 fffff800023dd801
> fffff800023dd8f8 0000000000000001 : nt!PnpDeviceActionWorker+0x22d
> fffffa6001bd4cf0 fffff800024c3fd3 : fffff800024445a0 3736353433323130
> fffffa80039adbb0 0000000000000080 : nt!ExpWorkerThread+0x11a
> fffffa6001bd4d50 fffff800022d9816 : fffffa60019d2180 fffffa80039adbb0
> fffffa60019dbd40 0000000000000001 : nt!PspSystemThreadStartup+0x57
> fffffa6001bd4d80 0000000000000000 : 0000000000000000 0000000000000000
> 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_NAME: MachineOwner
>
> FAILURE_BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys
>
> BUCKET_ID: X64_0xCA_1_IMAGE_usbhub.sys
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> 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
>
>
> —
> 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

Mike_Kemp · May 14, 2009, 1:44pm

FWIW my understanding is that unique serial numbers are optional for USB
devices. If you don’t have one, you must not define a serial number string
in the device descriptor. If you define a serial number string, they must be
unique. I am pretty sure this is understood by Windows. I hope my
recollection is correct!!! M

>>>>>
----- Original Message -----
From: Gianluca Varenni
To: Windows System Software Devs Interest List
Sent: Thursday, May 14, 2009 6:27 PM
Subject: Re: [ntdev] Bugcheck CA on Vista X64

Well, we do not manufacture the hardware directly, and so far we have never
reprogrammed the unique ID. The device is basically a wireless adapter (with
a custom non-NDIS driver), and the manufacturer programs each device with a
different MAC but leaves the unique ID set to 12345 (because this is
probably what the chip manufacturer told them to do in their reference
designs).
We can definitely reprogram the adapters that we are selling now with the
MAC address as the unique ID (it’s my understanding that the unique ID is
just a string). But we already have literally thousands of customers which
have devices all with the same unique ID.

Just so that it’s clear to me, is it a requirement to a unique ID for every
device? I’ve seen that even big manufacturers ship all their devices with
the same unique ID. Can the usbcore distinguish the various devices from
their position on the USB bus, exactly like PCI?

Have a nice day
GV

Michal_Vodicka-2 · May 14, 2009, 1:51pm

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Thursday, May 14, 2009 7:44 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Bugcheck CA on Vista X64

FWIW my understanding is that unique serial numbers are
optional for USB
devices. If you don’t have one, you must not define a serial
number string
in the device descriptor. If you define a serial number
string, they must be
unique. I am pretty sure this is understood by Windows. I hope my
recollection is correct!!! M

My understanding is the same but unfortunately, I haven’t found anything
like this in the USB specification.

Anyway, non-unique serial number just doesn’t make sense. Ah, these hw
manufacturers…

Best regards,

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

Gianluca_Varenni · May 14, 2009, 1:53pm

----- Original Message -----
From: “Michal Vodicka”
To: “Windows System Software Devs Interest List”
Sent: Thursday, May 14, 2009 10:50 AM
Subject: RE: [ntdev] Bugcheck CA on Vista X64

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
> Sent: Thursday, May 14, 2009 7:44 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Bugcheck CA on Vista X64
>
> FWIW my understanding is that unique serial numbers are
> optional for USB
> devices. If you don’t have one, you must not define a serial
> number string
> in the device descriptor. If you define a serial number
> string, they must be
> unique. I am pretty sure this is understood by Windows. I hope my
> recollection is correct!!! M

My understanding is the same but unfortunately, I haven’t found anything
like this in the USB specification.

Anyway, non-unique serial number just doesn’t make sense. Ah, these hw
manufacturers…

–GV–
And shame on me, I didn’t know about this serial number thingie when I first
started working on USB…

GV

Thomas_Divine-2 · May 14, 2009, 1:53pm

If you never expect multiple of your devices to be installed on a PC, then
your assumption is correct.

It will probably “survive” using this approach if two such devices are
installed.

Much more than that - I would expect some issues under some insertion
scenarios.

I don’t have a solution to this problem - just observations that it really
sucks when lots of USB devices without unique USB serial numbers are
inserted. True in XP and Vista.

Thomas

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Thursday, May 14, 2009 1:44 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Bugcheck CA on Vista X64

FWIW my understanding is that unique serial numbers are optional for USB
devices. If you don’t have one, you must not define a serial number string
in the device descriptor. If you define a serial number string, they must be

unique. I am pretty sure this is understood by Windows. I hope my
recollection is correct!!! M

>>>>>
----- Original Message -----
From: Gianluca Varenni
To: Windows System Software Devs Interest List
Sent: Thursday, May 14, 2009 6:27 PM
Subject: Re: [ntdev] Bugcheck CA on Vista X64

Well, we do not manufacture the hardware directly, and so far we have never
reprogrammed the unique ID. The device is basically a wireless adapter (with
a custom non-NDIS driver), and the manufacturer programs each device with a
different MAC but leaves the unique ID set to 12345 (because this is
probably what the chip manufacturer told them to do in their reference
designs).
We can definitely reprogram the adapters that we are selling now with the
MAC address as the unique ID (it’s my understanding that the unique ID is
just a string). But we already have literally thousands of customers which
have devices all with the same unique ID.

Just so that it’s clear to me, is it a requirement to a unique ID for every
device? I’ve seen that even big manufacturers ship all their devices with
the same unique ID. Can the usbcore distinguish the various devices from
their position on the USB bus, exactly like PCI?

Have a nice day
GV

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

Doron_Holan · May 14, 2009, 1:55pm

That is correct. Serial numbers are optional. If you opt in they must be unique for all instances of that product.

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Mike Kemp
Sent: Thursday, May 14, 2009 10:45 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Bugcheck CA on Vista X64

FWIW my understanding is that unique serial numbers are optional for USB
devices. If you don’t have one, you must not define a serial number string
in the device descriptor. If you define a serial number string, they must be
unique. I am pretty sure this is understood by Windows. I hope my
recollection is correct!!! M
>>>>>>
----- Original Message -----
From: Gianluca Varenni
To: Windows System Software Devs Interest List
Sent: Thursday, May 14, 2009 6:27 PM
Subject: Re: [ntdev] Bugcheck CA on Vista X64

Well, we do not manufacture the hardware directly, and so far we have never
reprogrammed the unique ID. The device is basically a wireless adapter (with
a custom non-NDIS driver), and the manufacturer programs each device with a
different MAC but leaves the unique ID set to 12345 (because this is
probably what the chip manufacturer told them to do in their reference
designs).
We can definitely reprogram the adapters that we are selling now with the
MAC address as the unique ID (it’s my understanding that the unique ID is
just a string). But we already have literally thousands of customers which
have devices all with the same unique ID.

Just so that it’s clear to me, is it a requirement to a unique ID for every
device? I’ve seen that even big manufacturers ship all their devices with
the same unique ID. Can the usbcore distinguish the various devices from
their position on the USB bus, exactly like PCI?

Have a nice day
GV

—
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 · May 14, 2009, 2:07pm

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
Gianluca Varenni
Sent: Thursday, May 14, 2009 7:53 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Bugcheck CA on Vista X64

And shame on me, I didn’t know about this serial number
thingie when I first
started working on USB…

Neither did I but fortunately our hw department didn’t have an idea to
add serial number to our devices this time

Wasn’t it better when two devices with the same serial number caused
immediate BSOD when connected at one?

Best regards,

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

Tim_Roberts · May 14, 2009, 2:20pm

Gianluca Varenni wrote:

Well, we do not manufacture the hardware directly, and so far we have
never reprogrammed the unique ID. The device is basically a wireless
adapter (with a custom non-NDIS driver), and the manufacturer programs
each device with a different MAC but leaves the unique ID set to 12345
(because this is probably what the chip manufacturer told them to do
in their reference designs).
We can definitely reprogram the adapters that we are selling now with
the MAC address as the unique ID (it’s my understanding that the
unique ID is just a string).

Correct. It’s a Unicode string, but the serial number has a limited
alphabet, basically 0-9 and A-Z.

But we already have literally thousands of customers which have
devices all with the same unique ID.

Just so that it’s clear to me, is it a requirement to a unique ID for
every device?

Yes it is. What you’re talking about is a violation of the USB
specification. If you don’t have a copy of the USB specification, I
recommend you download one from www.usb.org. In my opinion, it’s quite
readable. The most applicable sections for driver developers are
chapters 5 and 9.

However, I’ve been drilling into the USB 2.0 spec over the last 10
minutes, and so far I haven’t found the “must be unique” requirement.
Jan Axelson’s book says that a VID, PID and SN combo must be unique, and
that certainly matches my understanding, but I can’t find it in the spec.

It’s certainly not supported in Windows. Windows uses the VID/PID/SN
combo to uniquely identify a single device. In the absence of a SN, it
uses VID/PID/hub slot number.

I’ve seen that even big manufacturers ship all their devices with the
same unique ID.

Can you name one? We can make fun of them.

Can the usbcore distinguish the various devices from their position on
the USB bus, exactly like PCI?

Yes, but it only does so if the device has no serial number.

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

OSR_Community_User · May 15, 2009, 1:03am

On Thu, May 14, 2009 at 11:19:33AM -0700, Tim Roberts wrote:

> But we already have literally thousands of customers which have
> devices all with the same unique ID.
>
> Just so that it’s clear to me, is it a requirement to a unique ID for
> every device?

Yes it is. What you’re talking about is a violation of the USB
specification. If you don’t have a copy of the USB specification, I
recommend you download one from www.usb.org. In my opinion, it’s quite
readable. The most applicable sections for driver developers are
chapters 5 and 9.

However, I’ve been drilling into the USB 2.0 spec over the last 10
minutes, and so far I haven’t found the “must be unique” requirement.
Jan Axelson’s book says that a VID, PID and SN combo must be unique, and
that certainly matches my understanding, but I can’t find it in the spec.

No, it is not part of the spec for most devices. You are allowed to
have a serial number that is not unique for almost all types of devices,
except a few. USB printers is one where the class spec requires a
unique serial number (that is what the OS uses to determine which
printer is which.)

So while it is desirable, it is not required.

Hope this helps,

greg k-h

Mike_Kemp · May 15, 2009, 4:18am

Hi, this thread made me check the USB spec and with a bit of googling I
think I confirmed what I thought:

http://msdn.microsoft.com/en-us/library/dd450465.aspx
“Universal Serial Bus (USB) device serial numbers are optional, but if they
are implemented, they are required to be unique.”

As far as I can tell the USB spec is silent on the issue. And why not, after
all as far as USB is concerned every device is uniquely identified by its
address assigned when it is connected. If the host wants to get confused by
identical devices on different ports it is at liberty to do so, but it would
be a bad host. If the functionality of the device is such that the user
might care which device is which, e.g, if it is a device to which the user
might connect something, or view something, or control something, or save
something, it had better have something unique so the OS or application can
manage assigning the same service to the same device each time the bus is
re-configured. You can also think of devices where uniqueness is
unnecessary, for example if the device adds some processing power for an
application. You could add more and more devices to add more and more
processing power and never care which device was doing what. M.

>>>>>>>>quote:
Just so that it’s clear to me, is it a requirement to a unique ID for
every device?

Yes it is. What you’re talking about is a violation of the USB
specification. If you don’t have a copy of the USB specification, I
recommend you download one from www.usb.org. In my opinion, it’s quite
readable. The most applicable sections for driver developers are
chapters 5 and 9.
<<<<<<<<<<

Gianluca_Varenni · May 15, 2009, 12:25pm

Just to sum things up,

the USB 2.0 specification does not say that the serial numbers must be
unique (at least I haven’t found any reference to it) but
the Windows USB core stack requires that the serial number, if present,
is unique. If not,
the USB stack tries to do its best to deal with devices with the same
serial, but sometimes it fails. This is enforced by DTM with this test
http://msdn.microsoft.com/en-us/library/dd450465.aspx

Right?

GV

----- Original Message -----
From: “Mike Kemp”
To: “Windows System Software Devs Interest List”
Sent: Friday, May 15, 2009 1:17 AM
Subject: Re: [ntdev] Bugcheck CA on Vista X64

> Hi, this thread made me check the USB spec and with a bit of googling I
> think I confirmed what I thought:
>
> http://msdn.microsoft.com/en-us/library/dd450465.aspx
> “Universal Serial Bus (USB) device serial numbers are optional, but if
> they are implemented, they are required to be unique.”
>
> As far as I can tell the USB spec is silent on the issue. And why not,
> after all as far as USB is concerned every device is uniquely identified
> by its address assigned when it is connected. If the host wants to get
> confused by identical devices on different ports it is at liberty to do
> so, but it would be a bad host. If the functionality of the device is such
> that the user might care which device is which, e.g, if it is a device to
> which the user might connect something, or view something, or control
> something, or save something, it had better have something unique so the
> OS or application can manage assigning the same service to the same device
> each time the bus is re-configured. You can also think of devices where
> uniqueness is unnecessary, for example if the device adds some processing
> power for an application. You could add more and more devices to add more
> and more processing power and never care which device was doing what. M.
>
>>>>>>>>>>quote:
>> Just so that it’s clear to me, is it a requirement to a unique ID for
>> every device?
>
> Yes it is. What you’re talking about is a violation of the USB
> specification. If you don’t have a copy of the USB specification, I
> recommend you download one from www.usb.org. In my opinion, it’s quite
> readable. The most applicable sections for driver developers are
> chapters 5 and 9.
> <<<<<<<<<<
>
> —
> 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

Tim_Roberts · May 15, 2009, 12:58pm

Mike Kemp wrote:

Hi, this thread made me check the USB spec and with a bit of googling
I think I confirmed what I thought:

http://msdn.microsoft.com/en-us/library/dd450465.aspx
“Universal Serial Bus (USB) device serial numbers are optional, but if
they are implemented, they are required to be unique.”

Yes, but this is not the USB spec. This is just Microsoft documenting
the restrictions of it’s own implementation.

As far as I can tell the USB spec is silent on the issue. And why not,
after all as far as USB is concerned every device is uniquely
identified by its address assigned when it is connected.

USB defines a lot more than just electrical connectivity. It also
defines behavior, and the class specs do so to a much greater extent.
It would have been perfectly natural for a serial number restriction to
be in the spec. The fact that it’s not in there, when I was so
confident that it was, has left me somewhat disturbed.

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