DRIVER_IRQL_NOT_LESS_OR_EQUAL after call ioctl

extredo · January 27, 2011, 8:07am

HI,

Could you please answer on following question.

Environment

Win7 x86
WDK version: 7600.16385.1

I write driver on kernel mode. The driver has thread worker that put an item in the list and user-mode appication uses ioctl call to request a data from kernel driver. In my ioctl call implementation i get items from list.

Here is how I insert an item to the List.

KeAcquireInStackQueuedSpinLock(
&gPacketInfoListLock,
&packetInfoListLockHandle
);

InsertTailList(&gPacketInfoList, &packetInfo->listEntry);
packetInfo=NULL;

KeReleaseInStackQueuedSpinLock(&packetInfoListLockHandle);

Here is how I get an item from the list in ioctl call implementation.

KeAcquireInStackQueuedSpinLock(
&gPacketInfoListLock,
&packetInfoListLockHandle
);

while (!IsListEmpty(&gPacketInfoList))
{
listEntry = RemoveHeadList(&gPacketInfoList);
packetInfo = CONTAINING_RECORD(
listEntry,
PACKET_INFO,
listEntry
);
}

After first call ioctl from user application i see the following error:

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

FOLLOWUP_IP:

TestDriver!RemoveHeadList+26 [c:\winddk\7600.16385.1\inc\ddk\wdm.h @ 7592]

93d43be6 894804 mov dword ptr [eax+4],ecx

FAULTING_SOURCE_CODE:

7589: Entry = ListHead->Flink;

7590: Flink = Entry->Flink;

7591: ListHead->Flink = Flink;

7592: Flink->Blink = ListHead;

7593: return Entry;

7594: }

How to resolve this issue?

Thanks for any help.

Gary_Little-3 · January 27, 2011, 8:58am

Obvious first question: Did you initialize gPacketInfoList using InitializeListHead? I know you insert something on the list but did you initialize it? The fact you 're crashing in RemoveListHead tells me you may not have.

Gary G. Little

----- Original Message -----
From: xxxxx@gmail.com
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 27, 2011 7:06:34 AM
Subject: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL after call ioctl

HI,

Could you please answer on following question.

Environment

Win7 x86
WDK version: 7600.16385.1

I write driver on kernel mode. The driver has thread worker that put an item in the list and user-mode appication uses ioctl call to request a data from kernel driver. In my ioctl call implementation i get items from list.

Here is how I insert an item to the List.

KeAcquireInStackQueuedSpinLock(
&gPacketInfoListLock,
&packetInfoListLockHandle
);

InsertTailList(&gPacketInfoList, &packetInfo->listEntry);
packetInfo=NULL;

KeReleaseInStackQueuedSpinLock(&packetInfoListLockHandle);

Here is how I get an item from the list in ioctl call implementation.

KeAcquireInStackQueuedSpinLock(
&gPacketInfoListLock,
&packetInfoListLockHandle
);

while (!IsListEmpty(&gPacketInfoList))
{
listEntry = RemoveHeadList(&gPacketInfoList);
packetInfo = CONTAINING_RECORD(
listEntry,
PACKET_INFO,
listEntry
);
}

After first call ioctl from user application i see the following error:

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

FOLLOWUP_IP:

TestDriver!RemoveHeadList+26 [c:\winddk\7600.16385.1\inc\ddk\wdm.h @ 7592]

93d43be6 894804 mov dword ptr [eax+4],ecx

FAULTING_SOURCE_CODE:

7589: Entry = ListHead->Flink;

7590: Flink = Entry->Flink;

7591: ListHead->Flink = Flink;

> 7592: Flink->Blink = ListHead;

7593: return Entry;

7594: }

How to resolve this issue?

Thanks for any help.

—
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

extredo · January 27, 2011, 4:25pm

Thanks for the answer, but i’ve initilized the list and used spin lock for the list in DriverEntry. I’ve noticed that the driver works fine without ioctl implementation.

Tim_Roberts · January 27, 2011, 4:45pm

xxxxx@gmail.com wrote:

Thanks for the answer, but i’ve initilized the list and used spin lock for the list in DriverEntry. I’ve noticed that the driver works fine without ioctl implementation.

That doesn’t necessarily mean the existing code is perfect, of course.

You really haven’t given us much to go on. You didn’t show the rest of
the !analyze -v output, so we can’t see whether it was a garbage
address, a null pointer, or a seemingly good address that caused the
problem. If the debug information is correct, the forward link pointer
in your first list entry is bad. That can happen if you write past the
end of the buffer, or if you treat the list entry as one type of struct
when it really is another, or a dozen other, similar problems.

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

extredo · January 28, 2011, 3:36am

Here is the debug output after !analyze -v:

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

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 kernel debugger is available get stack backtrace.

Arguments:

Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 93d43be6, address which referenced memory

Debugging Details:

Failed to load data access DLL, 0x80004005

WRITE_ADDRESS: 00000004
CURRENT_IRQL: 2
FAULTING_IP:

TestDriver!RemoveHeadList+26 [c:\winddk\7600.16385.1\inc\ddk\wdm.h @ 7592]

93d43be6 894804 mov dword ptr [eax+4],ecx

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: TestEngine.exe
MANAGED_STACK: !dumpstack -EE

Failed to load data access DLL, 0x80004005

TRAP_FRAME: 9478c718 -- (.trap 0xffffffff9478c718)
ErrCode = 00000002
eax=00000000 ebx=00000000 ecx=93d49070 edx=00000000 esi=847b8678 edi=846b61c0
eip=93d43be6 esp=9478c78c ebp=9478c794 iopl=0 nv up ei ng nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010292

TestDriver!RemoveHeadList+0x26:

93d43be6 894804 mov dword ptr [eax+4],ecx ds:0023:00000004=????????

Resetting default scope

LAST_CONTROL_TRANSFER: from 828e2e71 to 82871394
STACK_TEXT:

9478c2e4 828e2e71 00000003 be4aab4e 00000065 nt!RtlpBreakWithStatusInstruction
9478c334 828e396d 00000003 00000004 93d43be6 nt!KiBugCheckDebugBreak+0x1c
9478c6f8 8284c7eb 0000000a 00000004 00000002 nt!KeBugCheck2+0x68b
9478c6f8 93d43be6 0000000a 00000004 00000002 nt!KiTrap0E+0x2cf
9478c794 93d453ca 93d49070 0000002c 9478c814 TestDriver!RemoveHeadList+0x26 [c:\winddk\7600.16385.1\inc\ddk\wdm.h @ 7592]
9478cbfc 828424bc 847b8678 84dd9e58 84dd9e58 TestDriver!IoctlDeviceControl+0x15a [.......\drivermanagement.c @ 945]
9478cc14 82a43eee 846b61c0 84dd9e58 84dd9ec8 nt!IofCallDriver+0x63
9478cc34 82a60cd1 847b8678 846b61c0 00000000 nt!IopSynchronousServiceTail+0x1f8
9478ccd0 82a634ac 847b8678 84dd9e58 00000000 nt!IopXxxControlFile+0x6aa
9478cd04 8284942a 0000025c 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
9478cd04 770c64f4 0000025c 00000000 00000000 nt!KiFastCallEntry+0x12a
002ce7d8 770c4cac 753aa08f 0000025c 00000000 ntdll!KiFastSystemCallRet
002ce7dc 753aa08f 0000025c 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc
002ce83c 764aec25 0000025c 9c402408 002ce90c KERNELBASE!DeviceIoControl+0xf6
002ce868 0045bd5f 0000025c 9c402408 002ce90c KERNEL32!DeviceIoControlImplementation+0x80
WARNING: Frame IP not in any known module. Following frames may be wrong.
002ce8e8 702a7abc 00000000 00000000 00000000 0x45bd5f
002cf118 03e85c91 019f3a3c 002cf154 03e83f96 mscorjit!Compiler::gcPtrTableSave+0x16
002cf170 6c561b6c 002cf1bc 00000000 002cf200 0x3e85c91
002cf180 6c572209 002cf250 00000000 002cf220 mscorwks!CallDescrWorker+0x33
002cf200 6c586511 002cf250 00000000 002cf220 mscorwks!CallDescrWorkerWithHandler+0xa3
002cf338 6c586544 0046c030 002cf404 002cf3d0 mscorwks!MethodDesc::CallDescr+0x19c
002cf354 6c586562 0046c030 002cf404 002cf3d0 mscorwks!MethodDesc::CallTargetWorker+0x1f
002cf36c 6c5f0c45 002cf3d0 5f183ff7 00000000 mscorwks!MethodDescCallSite::CallWithValueTypes_RetArgSlot+0x1a
002cf4d0 6c5f0b65 00462ffc 00000001 002cf50c mscorwks!ClassLoader::RunMain+0x223
002cf738 6c5f10b5 00000000 5f18372f 00000001 mscorwks!Assembly::ExecuteMainMethod+0xa6
002cfc08 6c5f129f 013e0000 00000000 5f18377f mscorwks!SystemDomain::ExecuteMainMethod+0x456
002cfc58 6c5f11cf 013e0000 5f183787 00000000 mscorwks!ExecuteEXE+0x59
002cfca0 72dd7c24 00000000 6c560000 002cfcbc mscorwks!_CorExeMain+0x15c
002cfcb0 764b1174 7ffdf000 002cfcfc 770db3f5 MSCOREE!_CorExeMain+0x2c
002cfcbc 770db3f5 7ffdf000 77895394 00000000 KERNEL32!BaseThreadInitThunk+0xe
002cfcfc 770db3c8 72dd7bf0 7ffdf000 00000000 ntdll!__RtlUserThreadStart+0x70
002cfd14 00000000 72dd7bf0 7ffdf000 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND: kb

FOLLOWUP_IP:

TestDriver!RemoveHeadList+26 [c:\winddk\7600.16385.1\inc\ddk\wdm.h @ 7592]
93d43be6 894804 mov dword ptr [eax+4],ecx

FAULTING_SOURCE_CODE:
7588:
7589: Entry = ListHead->Flink;
7590: Flink = Entry->Flink;
7591: ListHead->Flink = Flink;

7592: Flink->Blink = ListHead;
7593: return Entry;
7594: }

SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: TestDriver!RemoveHeadList+26
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: TestDriver
IMAGE_NAME: TestDriver.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4d3c9074
FAILURE_BUCKET_ID: 0xD1_TestDriver!RemoveHeadList+26

BUCKET_ID: 0xD1_TestDriver!RemoveHeadList+26
*** Fatal System Error: 0x000000d1

(0x00000004,0x00000002,0x00000001,0x93D43BE6)
Break instruction exception - code 80000003 (first chance)

Podun_Yu · January 28, 2011, 5:02am

Do you reference the packetInfo object .Maybe this location have been release .

Jeff_Glass · January 28, 2011, 11:07am

You’re accessing a bad pointer on line 7592 in your source. Flink is NULL. The bug check code arguments tell you exactly what’s happening.

Arg1 tells you that you’re accessing memory address 0x00000004. That’s never right.
Then line 3 tells you that it was a write operation.

If you combine that with line 7592 of your source, you can see that Flink is NULL. The dereference to Blink is at Flink + 0x00000004.

**** Arg1: 00000004, memory referenced ****
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 93d43be6, address which referenced memory

FAULTING_SOURCE_CODE:
7588:
7589: Entry = ListHead->Flink;
7590: Flink = Entry->Flink;
7591: ListHead->Flink = Flink;
**** > 7592: Flink->Blink = ListHead; ****
7593: return Entry;
7594:

Tim_Roberts · January 28, 2011, 1:18pm

xxxxx@gmail.com wrote:

Here is the debug output after !analyze -v:
…
TestDriver!RemoveHeadList+26 [c:\winddk\7600.16385.1\inc\ddk\wdm.h @ 7592]
…

TRAP_FRAME: 9478c718 – (.trap 0xffffffff9478c718)
ErrCode = 00000002
eax=00000000 ebx=00000000 ecx=93d49070 edx=00000000 esi=847b8678 edi=846b61c0
eip=93d43be6 esp=9478c78c ebp=9478c794 iopl=0 nv up ei ng nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010292
TestDriver!RemoveHeadList+0x26:
93d43be6 894804 mov dword ptr [eax+4],ecx ds:0023:00000004=???

OK, so the forward link pointer in your head object was NULL. Here is
one way something like this could happen:

packetInfo = ExAllocPool( … );
InsertTailList(&gPacketInfoList, &packetInfo->listEntry);
RtlZeroMemory( packetInfo, sizeof(PACKET_INFO) );
listEntry = RemoveHeadList(&gPacketInfoList);

Someone is zeroing out the link pointer in the head item in your list
after you have added it to the list.

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

extredo · January 30, 2011, 1:40pm

Very helpfull, thanks a lot

Maxim_S_Shatskih · January 30, 2011, 4:54pm

> FAULTING_SOURCE_CODE:

7589: Entry = ListHead->Flink;

One of the worst possible issues with lists is - deallocation of the structure which is still on the list.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com