Author: BSOD2600
Subject: Help pinpoint driver in IRQL_NOT_LESS_OR_EQUAL
Posted: 12 June 2013 at 5:54pm
In our environment, we've got a bunch of WinXP SP3 workstations which all exhibit the same BSOD signature (details below). I'm fairly certain it's the Hypercom vendors old RS232ToUsb.sys driver as the cause, however I'm lacking definitive proof.
As the crash appears to be caused regarding USB transfers, and the only USB devices plugged in are HP keyboard, mice, and Hypercom signature capture devices.
The PCs have the latest Windows updates, Intel system/chipset drivers, and a range of BIOS revisions among the different hardware models.
All of the BSOD's have the same call stack as below.
I doubt it's the Microsoft USBPORT driver. I cannot take the shotgun approach and blanket upgrade the driver on all production workstations without definitive proof it's the root cause of these random BSODs. They're random enough that if I did enable driver verification, I could be waiting for weeks before it could occur again on the same workstation.
What are some additional Windbg commands/techniques I can use to help pinpoint the root cause?
Subject: Help pinpoint driver in IRQL_NOT_LESS_OR_EQUAL
Posted: 12 June 2013 at 5:54pm
In our environment, we've got a bunch of WinXP SP3 workstations which all exhibit the same BSOD signature (details below). I'm fairly certain it's the Hypercom vendors old RS232ToUsb.sys driver as the cause, however I'm lacking definitive proof.
As the crash appears to be caused regarding USB transfers, and the only USB devices plugged in are HP keyboard, mice, and Hypercom signature capture devices.
The PCs have the latest Windows updates, Intel system/chipset drivers, and a range of BIOS revisions among the different hardware models.
All of the BSOD's have the same call stack as below.
|
I doubt it's the Microsoft USBPORT driver. I cannot take the shotgun approach and blanket upgrade the driver on all production workstations without definitive proof it's the root cause of these random BSODs. They're random enough that if I did enable driver verification, I could be waiting for weeks before it could occur again on the same workstation.
What are some additional Windbg commands/techniques I can use to help pinpoint the root cause?