BSOD NTOSKRNL.EXE USBPORT.SYS Help Request

OSR_Community_User · December 4, 2012, 8:05pm

Hello OSR members. First up, apologies, I’m a hardware dev and my Win programming is a little limited. Hope I am in the correct list!

I started working on an USB interface using a ‘MICROCHIP PIC’ based circuit. I threw together and checked the basic circuit and flashed the MCHPUSB Bootloader to the 18F2550 MCU. It should all just work as far as I can tell, unfortunately I get a Blue Screen, instead.
I ran windbg but it’s mostly gobbledegook to me. I could really use some help debugging to correct this frustrating problem. I will say, it does not happen in safe mode (XPProSP3) and only when attempting to enter the bootloader and not during the normal USER MODE operation/application. The bootloader code is standard and *should* not pose a problem.
I saw a similar thread and that’s what brought me to this site. From what I can tell it may not apply to me.
So, after installing the Microchip Custom USB Device Driver (successfully) I proceed to plug in my USB B type to the circuit. A few seconds later the BSOD shows IRQL LESS EQUAL, Bugcheck 0xA -> NTOSKRNL.EXE and USBPORT.SYS, also SPTD.SYS, although removing SPTD has no significance. I’m on a Pentium4. Here’s the analysis:

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: e1edb5b0, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 8067337a, address which referenced memory

Debugging Details:

WRITE_ADDRESS: e1edb5b0
CURRENT_IRQL: 2
FAULTING_IP:
nt!ViFlushDoubleBuffer+182
8067337a f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
CUSTOMER_CRASH_COUNT: 5
DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: svchost.exe
LAST_CONTROL_TRANSFER: from 80673951 to 8067337a

STACK_TEXT:
f78a2e30 80673951 8948bd90 00000000 e1edb5b0 nt!ViFlushDoubleBuffer+0x182
f78a2e64 b7891f8d 89ea7610 891e9d20 00000000 nt!VfFlushAdapterBuffers+0x147
f78a2ee4 b7892d47 f78d68dc 00000000 8a0467d8 USBPORT!USBPORT_CompleteTransfer+0x22b
f78a2f14 b7893944 026e6f44 8a0460e0 8a0460e0 USBPORT!USBPORT_DoneTransfer+0x137
f78a2f4c b789513a 8a046028 804e2ec4 8a046230 USBPORT!USBPORT_FlushDoneTransferList+0x16c
f78a2f78 b78a324b 8a046028 804e2ec4 8a046028 USBPORT!USBPORT_DpcWorker+0x224
f78a2fb4 b78a33c2 8a046028 00000001 8a04a590 USBPORT!USBPORT_IsrDpcWorker+0x38f
f78a2fd0 804dbbd4 8a04664c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
f78a2ff4 804db89e aea5095c 00000000 00000000 nt!KiRetireDpcList+0x46
f78a2ff8 aea5095c 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2a
WARNING: Frame IP not in any known module. Following frames may be wrong.
804db89e 00000000 00000009 bb835675 00000128 0xaea5095c

STACK_COMMAND: kb
FOLLOWUP_IP:
USBPORT!USBPORT_CompleteTransfer+22b
b7891f8d 56 push esi
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: USBPORT!USBPORT_CompleteTransfer+22b
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: USBPORT
IMAGE_NAME: USBPORT.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 480254ce
FAILURE_BUCKET_ID: 0xA_USBPORT!USBPORT_CompleteTransfer+22b
BUCKET_ID: 0xA_USBPORT!USBPORT_CompleteTransfer+22b
Followup: MachineOwner

Thanks for any help and Kindest of Regards

Tim_Roberts · December 4, 2012, 8:35pm

xxxxx@yahoo.com wrote:

I started working on an USB interface using a ‘MICROCHIP PIC’ based circuit. I threw together and checked the basic circuit and flashed the MCHPUSB Bootloader to the 18F2550 MCU. It should all just work as far as I can tell, unfortunately I get a Blue Screen, instead.

Which bootloader did you load, exactly? The Microchip development kit
includes several. Did you modify the code at all?

I ran windbg but it’s mostly gobbledegook to me. I could really use some help debugging to correct this frustrating problem. I will say, it does not happen in safe mode (XPProSP3) and only when attempting to enter the bootloader and not during the normal USER MODE operation/application.

I’m not sure what that last sentence means. Are you just saying it
doesn’t crash if your device is not plugged in?

Your driver is probably not being loaded in safe mode.

The bootloader code is standard and *should* not pose a problem.

That’s what they all say.

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

OSR_Community_User · December 4, 2012, 9:26pm

Hi Tim, thanks for the reply.

The Bootloader is the 18F4550 family, Custom MCHPUSB driver included with the v2.9 examples libraries from Microchip.com. It seems to be quite popular
[USB\Device - Bootloaders\MCHPUSB\Firmware - PIC18F4550 Family]

The code was written for a 4550 so I modified the linker of a 18F2550 to match the 18F4550 Bootloaded version, as the two chips are memory/code compatible. I removed the references and calls to PORTD as this set of IO does not exist on the 2550, which has 28 pins as opposed to the 40 on the 4550. I removed blinking LED code to save space and then I set “SELF_POWERED” Flag to 0 to represent a 100% bus powered device.

In safe mode windows recognises the device and also enumerates it successfully, labelling it “Microchip Custom USB Device” in Devicemanager.

To program a PIC with a bootloader, basically the BL gets flashed on to the chip first (I use PICSTART PLUS) and then any application code for the bells and whistles gets flashed on to the chip via USB through the ICSP. On power up a logic 1 on pin RB4 makes the bootloader quit its operation and tells the program counter to move to the user application code. A logic 0 on pin RB4 makes the chip stay within the BL code in order that one can use the ICSP to modify the program.
BSOD only occurs in bootloader mode.

The interesting thing is that, in safe mode, despite successful enumeration and evidence of the correct driver having been loaded, and appearing in the list of USBVIEW.EXE and device manager, polling the VID/PID of the device returns a “Device not connected” message.
It is, Mr. Computer. I can see it in front of me.

ALSO, in normal XP operation I tried plugging it into a different USB port. The device driver reinstalled from USB Device to Microchip Custom automatically, enumerated and sat there with no crash. However, when I reset the device it caused instant BSOD. After this, even after restarting, plugging in the device once again caused BSOD after seconds.

I think my problem is with the Windows side driver.
Hope this sheds some light on the situation without sounding like a load of guff

Thanks again, Kind regards,
John.

Alex_Grig · December 5, 2012, 12:35am

It would not surprise me this is just another bug in USBPORT.SYS in XP. The gold version was horrible. If this is SP3, the probability of a bug is low, but still.

BUT, it may be that the URB has incorrect flags in it, and it bombs when the Driver Verifier is enabled with DMA checks.

OSR_Community_User · December 5, 2012, 4:09am

Hi Alex, thanks for the reply!
Do you know how I might go about switching off the verifier? Or perhaps correcting the flags?

Kind Regards

OSR_Community_User · December 5, 2012, 5:19am

Ok I ran Verifier.exe for ALL drivers and this caused BSOD with the following dump :

Symbol search path is: C:\WINDOWS\Symbols;SRV*c:\windows\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: C:\WINDOWS\system32;c:\windows\system32\drivers\
Windows XP Kernel Version 2600 (Service Pack 3) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp3_gdr.120821-1629
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b2c0
* Bugcheck Analysis *
Use !analyze -v to get detailed debugging information.
BugCheck C4, {1001, 898c2200, 89f09dc0, 0}
*** ERROR: Module load completed but symbols could not be loaded for CPWUA6D1.sys
Probably caused by : CPWUA6D1.sys ( CPWUA6D1+19ba7 )
Followup: MachineOwner

kd> !analyze -v
* Bugcheck Analysis *

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is because the driver was specified in the registry as being suspect (by the administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will be among the most commonly seen crashes.
Arguments:
Arg1: 00001001, Verifier predicted potential deadlock.
Arg2: 898c2200, Lock address.
Arg3: 89f09dc0, Verifier internal data.
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0xc4_1001
DRIVER_DEADLOCK: Deadlock detection not initialized
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
PROCESS_NAME: System
LAST_CONTROL_TRANSFER: from 80674ca7 to 805338be

STACK_TEXT:
f78a29a4 80674ca7 000000c4 00001001 898c2200 nt!KeBugCheckEx+0x1b
f78a29c4 8067552f 00001001 898c2200 89f09dc0 nt!ViDeadlockReportIssue+0x57
f78a29ec 80675d3e 898c2200 01f09dc0 00000001 nt!ViDeadlockAnalyze+0x18a
f78a2a48 8066ed57 898c2200 00000004 89f09d50 nt!VfDeadlockAcquireResource+0x19c
f78a2a6c b8417ed2 898c2200 898b0e10 a5408ba7 nt!VerifierKfAcquireSpinLock+0x64
f78a2a78 a5408ba7 898c2200 8985b360 899ae000 NDIS!NdisAcquireSpinLock+0x11
WARNING: Stack unwind information not available. Following frames may be wrong.
f78a2a8c a541334f 899ae000 899e5604 00000000 CPWUA6D1+0x19ba7
f78a2a9c a54133f3 899ae000 899e5600 a5401ff1 CPWUA6D1+0x2434f
00000000 00000000 00000000 00000000 00000000 CPWUA6D1+0x243f3

STACK_COMMAND: kb
FOLLOWUP_IP:
CPWUA6D1+19ba7
a5408ba7 8b442418 mov eax,dword ptr [esp+18h]
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: CPWUA6D1+19ba7
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: CPWUA6D1
IMAGE_NAME: CPWUA6D1.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 423a44d1
FAILURE_BUCKET_ID: 0xc4_1001_CPWUA6D1+19ba7
BUCKET_ID: 0xc4_1001_CPWUA6D1+19ba7
Followup: MachineOwner

Going to remove monitoring and see if that stops BSOD with the circuit.

OSR_Community_User · December 5, 2012, 5:57am

Alex, you hit the nail on the head! I disabled verifier for all devices and now there is no blue screen when I plug in my circuit. Thank you very much. This is great as I can now make some progress finally Host application sees the circuit and it is enabled for ICSP. Sweet!

Do you perhaps have an idea of how I can ID/correct the problem that caused the BSOD? I know its not important at this stage really but I will eventually need my drivers to sit nicely with the verifier.

Thank You
Kind Regards,
John

Alex_Grig · December 5, 2012, 12:59pm

Is your driver creating and submitting the URBs?

Does it process the user mode IRPs?

Do you call IoMarkIrpPending?

You also might forget to call NdisAllocateSpinlock for some spinlock, which caused the bugcheck C4.

OSR_Community_User · December 7, 2012, 5:17am

Hi Alex, sorry for the delay; I’m trying to get my head around all this stuff.

I ran UBSlyzer (free eval so no exports) and found that some of the submitted requests are coming back unsupported.

pnp 0032-0031 -Query device relations- Bus relations- usbhub IRP 88DA7008h Not supported
pnp 0033-0030 -Query device relations- Bus relations- MCHPUSB IRP 88DA7008h Not supported

URB 0036 -Get Descriptor- Dvc Qual- IN usbhub 88D258D8h
URB 0037-0036 -Control Transfer- Get descriptor(Dvc Qual)- IN --:–:00(C:I:E) usbhub IRP 88D258D8h Unsuccessful (Stall PID)

Clicking this last one gives the following
Get Descriptor
This request returns the specified descriptor if the descriptor exists.
Offset Field Size Value Description
0 bmRequestType 1 80h
4…0: Recipient …00000 Device
6…5: Type .00… Standard
7: Direction 1… Device-to-Host
1 bRequest 1 06h Get Descriptor
2 wValue.LowByte 1 00h
3 wValue.HiByte 1 06h Device Qualifier Descriptor
4 wIndex 2 0000h
6 wLength 2 000Ah Descriptor Length

Then one more:
KmIO 0059-0053 -Internal USB Submit Idle Notification- usbhub IRP 88CBDE70h Cancelled

I shall answer the other questions when I have more of an idea what it all means
The driver is written my MICROCHIP so theoretically, it should be sound. I’ve just installed VSc++ again so I’ll take a good look at the driver source files and let you know what I find.

Do you know of any free URB analysers? Ive tried a few “Simple loggers” but they either dont function or crash when I attempt to use them.
Kind Regards

OSR_Community_User · December 7, 2012, 5:21am

One more thing, it seems that Unconfigure is also unsupported…

Alex_Grig · December 7, 2012, 11:02am

>The driver is written my MICROCHIP so theoretically, it should be sound.

I would not be so sure.

Tim_Roberts · December 7, 2012, 1:09pm

xxxxx@yahoo.com wrote:

I ran UBSlyzer (free eval so no exports) and found that some of the submitted requests are coming back unsupported.

pnp 0032-0031 -Query device relations- Bus relations- usbhub IRP 88DA7008h Not supported
pnp 0033-0030 -Query device relations- Bus relations- MCHPUSB IRP 88DA7008h Not supported

That’s irrelevant. Those are PnP requests, not USB requests.

URB 0036 -Get Descriptor- Dvc Qual- IN usbhub 88D258D8h
URB 0037-0036 -Control Transfer- Get descriptor(Dvc Qual)- IN --:–:00(C:I:E) usbhub IRP 88D258D8h Unsuccessful (Stall PID)

What USB version do you have in your Device Descriptor? If you
advertise USB 2.0 (0200), and you are capable of running at high-speed,
then you are required to have a Device Qualifier descriptor. Otherwise,
the descriptor is optional and a stall is the correct response.

Do you know of any free URB analysers? Ive tried a few “Simple loggers” but they either dont function or crash when I attempt to use them.

I paid for the USB Monitor product from www.hhdsoftware.com, and I’m
happy with that. If you’re going to be developing USB devices, you
might consider a real hardware analyzer.

One more thing, it seems that Unconfigure is also unsupported…

What do you mean by that? Where is it rejected? The SetConfiguration
request with configuration=0 must be supported by the device.

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