Zero-Length Buffer Test Error

Hi:

I am running the Device Path Exerciser Test with the DTM studio on Windows 7-32 bits Client but it fails, i checked the DC2.log and seems to be the Zero-Length Buffer Test the one that fails:
.
.
.
Start Relative Open Tests for ‘::$EA_INFORMATION’
Start Miscellaneous Tests (part 2)
End Miscellaneous Tests (part 2)
End Relative Open Tests for ‘::$EA_INFORMATION’
Start Relative Open Tests for ‘::$PROPERTY_SET’
Start Miscellaneous Tests (part 2)
End Miscellaneous Tests (part 2)
End Relative Open Tests for ‘::$PROPERTY_SET’
Start Relative Open Tests for ‘::$FIRST_USER_DEFINE’…
Start Miscellaneous Tests (part 2)
End Miscellaneous Tests (part 2)
End Relative Open Tests for ‘::$FIRST_USER_DEFINE’…
Start Relative Open Tests for ‘::$END’
Start Miscellaneous Tests (part 2)
End Miscellaneous Tests (part 2)
End Relative Open Tests for ‘::$END’
End STREAMS Tests
End sub-Open Tests
Start IOCTL/FSCTL Zero Length Buffer Tests (funcs 0-4095, with devtype 27-27)

This is the dump I got:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8fb0fb3e, The address that the exception occurred at
Arg3: 8ed709dc, Trap Frame
Arg4: 00000000

Debugging Details:

DBGHELP: C:\Program Files\Debugging Tools for Windows (x86)\sym\ntkrpamp.exe\4A5BC007410000\ntkrpamp.exe - OK
DBGHELP: C:\Program Files\Debugging Tools for Windows (x86)\sym\Wdf01000.sys\4A5BBF2871000\Wdf01000.sys - OK
DBGHELP: C:\Program Files\Debugging Tools for Windows (x86)\sym\usbser.sys\4A5BC875c000\usbser.sys - OK
SYMSRV: C:\Program Files\Debugging Tools for Windows (x86)\sym\upp_usb.sys\4DCC66E82680\upp_usb.sys not found
SYMSRV: http://msdl.microsoft.com/download/symbols/upp_usb.sys/4DCC66E82680/upp_usb.sys not found
DBGHELP: D:\Profiles\b31287\Desktop\PDB\upp_usb.sys - OK

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
usbser!Purge+c
8fb0fb3e 8b09 mov ecx,dword ptr [ecx]

TRAP_FRAME: 8ed709dc – (.trap 0xffffffff8ed709dc)
ErrCode = 00000000
eax=8f798e28 ebx=93bdd0f0 ecx=00000000 edx=00000000 esi=8f798e28 edi=00000000
eip=8fb0fb3e esp=8ed70a50 ebp=8ed70a54 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
usbser!Purge+0xc:
8fb0fb3e 8b09 mov ecx,dword ptr [ecx] ds:0023:00000000=???
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: devpathexer.ex

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 828d0372 to 828efd10

STACK_TEXT:
8ed70544 828d0372 0000008e c0000005 8fb0fb3e nt!KeBugCheckEx+0x1e
8ed7096c 82857016 8ed70988 00000000 8ed709dc nt!KiDispatchException+0x1ac
8ed709d4 82856fca 8ed70a54 8fb0fb3e badb0d00 nt!CommonDispatchException+0x4a
8ed70a54 8fb0f23f 93bdd038 8f798e28 93bdd0f0 nt!Kei386EoiHelper+0x192
8ed70a84 82b426c3 93bdd038 8f798e28 6c4229e0 usbser!UsbSer_Dispatch+0x239
8ed70aa8 8284f473 00000000 8ed70af0 93bdd038 nt!IovCallDriver+0x258
8ed70abc 856720da 8ed70b00 8f798e28 7513a770 nt!IofCallDriver+0x1b
8ed70ad4 8fb514c7 93bddde8 8aec5888 93bdd618 Wdf01000!imp_WdfRequestSend+0x254
WARNING: Stack unwind information not available. Following frames may be wrong.
8ed70b00 8fb51aff 7513a770 6c4229e0 93bde010 upp_usb+0x4c7
8ed70b1c 8568b072 6c421fe8 7513a770 00000000 upp_usb+0xaff
8ed70b40 8568c3d0 6c421fe8 7513a770 00000000 Wdf01000!FxIoQueueIoInternalDeviceControl::Invoke+0x30
8ed70b70 8568e9ac 7513a770 8aec5888 93bde010 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x31d
8ed70b8c 8568fa36 93bde000 00000000 93bddd18 Wdf01000!FxIoQueue::DispatchEvents+0x3be
8ed70bac 85691824 8aec5888 87670d78 8f798e28 Wdf01000!FxIoQueue::QueueRequest+0x1ec
8ed70bd0 85680a3f 8f798e28 8ed70c00 82b426c3 Wdf01000!FxPkgIo::Dispatch+0x27d
8ed70bdc 82b426c3 93bdd700 8f798e28 8cb07130 Wdf01000!FxDevice::Dispatch+0x7f
8ed70c00 8284f473 00000000 8f798e28 93bdd700 nt!IovCallDriver+0x258
8ed70c14 82a50eee 8cb07130 8f798e28 8f798fdc nt!IofCallDriver+0x1b
8ed70c34 82a6dcd1 93bdd700 8cb07130 00000000 nt!IopSynchronousServiceTail+0x1f8
8ed70cd0 82a704ac 93bdd700 8f798e28 00000000 nt!IopXxxControlFile+0x6aa
8ed70d04 8285642a 00000114 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
8ed70d04 76f664f4 00000114 00000000 00000000 nt!KiFastCallEntry+0x12a
01d2fe64 00000000 00000000 00000000 00000000 0x76f664f4

STACK_COMMAND: kb

FOLLOWUP_IP:
usbser!Purge+c
8fb0fb3e 8b09 mov ecx,dword ptr [ecx]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: usbser!Purge+c

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: usbser

IMAGE_NAME: usbser.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc875

FAILURE_BUCKET_ID: 0x8E_VRF_usbser!Purge+c

BUCKET_ID: 0x8E_VRF_usbser!Purge+c

Followup: MachineOwner

Any clue what could be the problem?
Thanks.

xxxxx@hotmail.com wrote:

Hi:

I am running the Device Path Exerciser Test with the DTM studio on Windows 7-32 bits Client but it fails, i checked the DC2.log and seems to be the Zero-Length Buffer Test the one that fails:

OK, so your driver is forwarding a “Purge” request to usbser.sys with a
zero-byte buffer, and usbser.sys doesn’t like it. My suggestion is that
you don’t do that. This is under your control.


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

This is my hierarchy driver:

upp.sys (FILTER)
usbser.sys
low.sys (FILTER)
|
lower.sys(FILTER THAT CREATES A PDO)
bus.sys(FDO)

I tested usbser.sys alone and there is no problem with that test, so i think the usbser is capable of handle those IO.
I tested upp,usbser,low working together and also there is no problem, but when the PDO is installed to work in conjunction with the other drivers the Test Fails, I do not find i reason why the PDO affects the handle of those IO.

I made a test to catch all the IO that comes with the OutputBufferLength = 0 in the lower.sys (BUS) and complete them as SUCCEED and the Test succeed but it affects the communication, is there any special condition i have to handle? or any clue about it.

Thanks