Hi,
Introduction:
******************
I am developing a profiling driver, this driver is build of two kernel level modules that communicate with each other using a collection of IOCTLs (IRP_MJ_INTERNAL_DEVICE_CONTROL), the drivers communication is triggered by a user-mode IOCTL (IRP_MJ_DEVICE_CONTROL) request, hence, user-mode calls Driver A and Driver A calls Driver B.
The problem:
******************
The drivers and user-mode app works fine, Still, when using the XP DriverVerifier ( with only the specialpool test checked ) I get an IRQL_NOT_LESS_OR_EQUAL BugCheck, this happens at the point ‘Driver A’ calls IoCallDriver on ‘Driver B’, the BugCheck happen BEFORE any of Driver B code is being executed, I Assume the DriverVerifier hooked to IoCallDriver and triggered this BugCheck ( I can see it’s debug output ) BUT WHY? The call is executed in PASSIVE_LEVEL ( as it was triggered by a user-mode request ), IoBuildDeviceIoControlRequest require executing in PASSIVE_LEVEL and IoCallDriver must be called at IRQL <- DISPATCH_LEVEL, It seems I have met all of the requirement, Still, I get this IRQL_NOT_LESS_OR_EQUAL BugCheck, Why???
[*] Note that running the DriverVerifier on Win2K with all of it’s options on doesn’t trigger this BugCheck…
Following is MEMORY.DMP output of DbgView, I don’t know what to make out of it… why does this BugCheck happen ONLY with the DriverVerifier? What am I doing wrong here?
********************************************************************* Bugcheck 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: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 8052587e, address which referenced memory
Debugging Details:
READ_ADDRESS: 00000000
CURRENT_IRQL: 2
FAULTING_IP:
nt!KeBugCheckUnicodeToAnsi+4
8052587e 0fb701 movzx eax,word ptr [ecx]
DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 8064e9f5 to 8052587e
STACK_TEXT:
fac207b8 8064e9f5 00000000 fac207d8 00000051 nt!KeBugCheckUnicodeToAnsi+0x4
fac20848 8064efcd 806793b0 00000224 00000006 nt!ViBucheckProcessParams+0x103
fac20af4 8064f0bd 806793b0 00000224 fac20b18 nt!VfBugcheckThrowException+0x33
fac20be0 8065131d 00000224 00002041 80d4a0f4 nt!VfBugcheckThrowIoException+0x8c
fac20c1c 80647121 00e2f650 fe70fe48 806c9190 nt!IovpCallDriver2+0x292
fac20c44 8058b076 81d8cfdc fef28a10 81d8cf48 nt!IovCallDriver+0xae
fac20c58 8058bc62 feeba438 81d8cf48 fef28a10 nt!IopSynchronousServiceTail+0x5e
fac20d00 805987ec 000007d4 00000000 00000000 nt!IopXxxControlFile+0x5ec
fac20d34 804da140 000007d4 00000000 00000000 nt!NtDeviceIoControlFile+0x28
fac20d34 7ffe0304 000007d4 00000000 00000000 nt!KiSystemService+0xc4
0145f14c 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4
FOLLOWUP_IP:
nt!KiTrap0E+2ad
804dce53 cc int 3
SYMBOL_STACK_INDEX: 1
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!KiTrap0E+2ad
MODULE_NAME: nt
IMAGE_NAME: ntoskrnl.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 3d6de35c
STACK_COMMAND: .trap fffffffffac20748 ; kb
FAILURE_BUCKET_ID: 0xA_VRF_nt!KiTrap0E+2ad
BUCKET_ID: 0xA_VRF_nt!KiTrap0E+2ad
Followup: MachineOwner
Thanks Ahead,
Naddav.
Yahoo! Music Unlimited - Access over 1 million songs. Try it free.