Driver Verifier DMA Error in USBPORT?

NTDEV
1

I was doing some final testing on a USB capture driver that I consider
finished, when I got a driver verifier error E6 on USBPORT. I run
driver verifier on all of the USB drivers, just to check my own
stupidity, but I’m hard-pressed to figure out how I could trigger a DMA
violation in USBPORT. It looks like it is just about to warn me about
USB_STATUS_ISOCH_REQUEST_FAILED, which is plausible. I get those at
startup before I’ve triggered streaming.

This is XP SP2. I’ve never seen this before, so I’m tempted to blame
gamma rays, but any wild ideas would be welcome.

Microsoft (R) Windows Debugger Version 6.4.0007.2
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Dev\Videology\sw\driver\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is:
srv*c:\ddk\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (4 procs) Free x86
compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700
Debug session time: Fri Feb 8 13:04:47.678 2008 (GMT-8)
System Uptime: 0 days 0:05:02.888
Loading Kernel Symbols
…
Loading unloaded module list
…
Loading User Symbols
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck E6, {d, 0, 0, 0}

Probably caused by : USBPORT.SYS ( USBPORT!USBPORT_CompleteTransfer+2b5 )

Followup: MachineOwner

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

DRIVER_VERIFIER_DMA_VIOLATION (e6)
An illegal DMA operation was attempted by a driver being verified.
Arguments:
Arg1: 0000000d, Violation code.
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

OVERLAPPED_MODULE:

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xE6

LAST_CONTROL_TRANSFER: from 80659206 to 804f9deb

STACK_TEXT:
bace3b64 80659206 000000e6 0000000d 00000000 nt!KeBugCheckEx+0x1b
bace3b88 8065b783 00000000 0000000d 80551104 nt!VfAssert+0x9e
bace3bac 8065ba8c 8a171448 0000000f 8b2b4e20 nt!ViFreeMapRegisterFile+0x13b
bace3bc8 ba406e27 8a3258f0 8973f8f8 00000018 nt!VfFreeMapRegisters+0x6e
bace3c3c ba407b57 8b2b4e20 c0000b00 8a4507d8
USBPORT!USBPORT_CompleteTransfer+0x2b5
bace3c6c ba408754 026e6f44 8a4500e0 8a4500e0
USBPORT!USBPORT_DoneTransfer+0x137
bace3ca4 ba409f6a 8a450028 80545d0c 8a450230
USBPORT!USBPORT_FlushDoneTransferList+0x16c
bace3cd0 ba417fb0 8a450028 80545d0c 8a450028 USBPORT!USBPORT_DpcWorker+0x224
bace3d0c ba418128 8a450028 00000001 8055b0a0
USBPORT!USBPORT_IsrDpcWorker+0x37e
bace3d28 805450bf 8a45064c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
bace3d50 80544fa4 00000000 0000000e 00000000 nt!KiRetireDpcList+0x61

FOLLOWUP_IP:
USBPORT!USBPORT_CompleteTransfer+2b5
ba406e27 8a4dd7 mov cl,[ebp-0x29]

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: USBPORT!USBPORT_CompleteTransfer+2b5

MODULE_NAME: USBPORT

IMAGE_NAME: USBPORT.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 41107d62

STACK_COMMAND: kb

FAILURE_BUCKET_ID: 0xE6_USBPORT!USBPORT_CompleteTransfer+2b5

BUCKET_ID: 0xE6_USBPORT!USBPORT_CompleteTransfer+2b5

Followup: MachineOwner

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

2

Tim Roberts wrote:

I was doing some final testing on a USB capture driver that I consider
finished, when I got a driver verifier error E6 on USBPORT. I run
driver verifier on all of the USB drivers, just to check my own
stupidity, but I’m hard-pressed to figure out how I could trigger a
DMA violation in USBPORT. It looks like it is just about to warn me
about USB_STATUS_ISOCH_REQUEST_FAILED, which is plausible. I get
those at startup before I’ve triggered streaming.

Actually, it appears that the stock USB drivers misbehave in several
ways under the Driver Verifier microscope. I had turned on Driver
Verifier on usbehci.sys, usbport.sys, usbd.sys, and usbccgp.sys, and I
was seeing hangs during URB submission that I have never seen before. I
went back to using Verifier only on my driver, and the hangs all went away.

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

3

Tim,

On two separate threads you have insisted that a physical address cannot be invalid by its very definition. It looks like now you have experimentally established that you were too much optimistic on the subject…

Anton Bassov

4

> I was doing some final testing on a USB capture driver that I consider

finished, when I got a driver verifier error E6 on USBPORT. I run
driver verifier on all of the USB drivers, just to check my own
stupidity, but I’m hard-pressed to figure out how I could trigger a
DMA violation in USBPORT. It looks like it is just about to warn me
about USB_STATUS_ISOCH_REQUEST_FAILED, which is plausible. I get
those at startup before I’ve triggered streaming.

0x0D == HV_DID_NOT_FLUSH_ADAPTER_BUFFERS

I believe this would indicate that the Device to Host transfer buffer appeared to be modified beyond the Length parameter passed to IoFlushAdapterBuffers(). In the case of a URB_FUNCTION_ISOCH_TRANSFER request the IoFlushAdapterBuffers() Length should be calculated as (IsoPacket.Offset + IsoPacket.Length) for the largest x for the URB_ISOCH_TRANSFER where (IsoPacket.Length > 0).

It is possible that if the transfer failed with an error that parts of the transfer buffer were updated during the transfer that were not fully accounted for in the transfer length. Hard to say for sure without digging through and taking detailed look at an example.

-Glen

5

xxxxx@hotmail.com wrote:

On two separate threads you have insisted that a physical address cannot be invalid by its very definition. It looks like now you have experimentally established that you were too much optimistic on the subject…

Well, I can’t find any documentation on exactly what Driver Verifier
error 0xe6 is, but the stack evidence suggests that one of the DMA data
structures got overwritten. It’s happening during the FreeMapRegisters
call.

In other words, I stand by my opinion, right or wrong. No, wait, that’s
not what I meant…

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

6

Actually, you have raised another interesting issue - what happens if physical address that you have supplied to DMA agent is invalid (or probably, I should say “not present”). Will it result in a bus crash??? Is an answer to this question bus-specific???.

Anton Bassov

7

It is bus/platform specific but in general reads will return ff’s and writes
will result in a cascading set of errors that provoke an NMI.

On the other hand, devices handed ‘invalid’ but ‘present’ addresses will
happiy scribble all over memory that doesn’t belong to them.

On Feb 9, 2008 1:57 AM, wrote:

> Actually, you have raised another interesting issue - what happens if
> physical address that you have supplied to DMA agent is invalid (or
> probably, I should say “not present”). Will it result in a bus crash??? Is
> an answer to this question bus-specific???.
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Mark Roddy

8

> On the other hand, devices handed ‘invalid’ but ‘present’ addresses will

happiy scribble all over memory that doesn’t belong to them

Sure. If you are able to do DMA, theoretically you are able to wipe out the whole kernel…

Anton Bassov

9

On Sat, Feb 09, 2008 at 01:57:42AM -0500, xxxxx@hotmail.com wrote:

Actually, you have raised another interesting issue - what happens
if physical address that you have supplied to DMA agent is invalid
(or probably, I should say “not present”). Will it result in a bus
crash??? Is an answer to this question bus-specific???.

Absolutely, yes. As I understand it, PCI buses have to accept all
addresses because of things like shadowing, whereas PCIExpress, for
example, could possibly raise a bus fault when given an unclaimed
address.

Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.