IRQL_NOT_LESS_OR_EQUAL crash with FSD

NTFSD
1

Hi, I got a IRQL_NOT_LESS_OR_EQUAL and I cant figure out the exact root cause of the crash. This crash occurs while Ctls+S is pressed twice while saving Word files.

Here are the details:

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: 804fef20, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000000

CURRENT_IRQL: 2

FAULTING_IP:
nt!KiDeliverApc+142
804fef20 391b cmp dword ptr [ebx],ebx

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: svchost.exe

TRAP_FRAME: a8eddab8 – (.trap ffffffffa8eddab8)
ErrCode = 00000000
eax=a8eddb38 ebx=00000000 ecx=89a2184a edx=00000000 esi=89a21760 edi=89bf6cb8
eip=804fef20 esp=a8eddb2c ebp=a8eddb60 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
nt!KiDeliverApc+0x142:
804fef20 391b cmp dword ptr [ebx],ebx ds:0023:00000000=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 804fef20 to 80543a70

STACK_TEXT:
a8eddab8 804fef20 badb0d00 00000000 89bf6cb8 nt!KiTrap0E+0x238
a8eddb60 806e5ef2 00000000 00000000 a8eddb78 nt!KiDeliverApc+0x142
a8eddb60 806e591a 00000000 00000000 a8eddb78 hal!HalpApcInterrupt+0xc6
a8eddbe8 a8ebcb47 00000000 891ec320 a8ebcc14 hal!KfReleaseSpinLock+0x1a
WARNING: Stack unwind information not available. Following frames may be wrong.
a8eddc78 a8eb5527 891ec268 89b66d40 a8eb5590 abcd+0xdb47
a8eddcb8 80578fb3 891ec268 89b66d40 8798fd50 abcd+0x6527
a8eddd38 805409ac 00000db4 000007ec 00000000 nt!NtNotifyChangeDirectoryFile+0x227
a8eddd38 7c91eb94 00000db4 000007ec 00000000 nt!KiFastCallEntry+0xfc
0071fb58 7c91dc8b 7c83168b 00000db4 000007ec ntdll!KiFastSystemCallRet
0071fb5c 7c83168b 00000db4 000007ec 00000000 ntdll!NtNotifyChangeDirectoryFile+0xc
0071fba4 74ff173e 00000db4 0035f718 00000868 kernel32!ReadDirectoryChangesW+0x92
0071fbd4 74ff16c0 0035f6e4 74ff14d4 00000000 trkwks!CObjIdIndexChangeNotifier::StartListening+0x45
0071fc48 74ff1512 0035f6e4 74ff14d4 00000000 trkwks!CObjIdIndexChangeNotifier::DoWork+0xff
0071fc80 7c937911 0035f6e4 00000000 000ead68 trkwks!ThreadPoolCallbackFunction+0x52
0071fccc 7c93a1bb 74ff14d4 0035f6e4 00000000 ntdll!RtlpWaitOrTimerCallout+0x73
0071fcf8 7c93a109 000ead68 0071fee4 00000000 ntdll!RtlpProcessWaitCompletion+0x112
0071ffb4 7c80b683 00000000 00000000 7c812a5b ntdll!RtlpWaitThread+0x277
0071ffec 00000000 7c939fae 00000000 00000000 kernel32!BaseThreadStart+0x37

STACK_COMMAND: kb

FOLLOWUP_IP:
ofant+db47
a8ebcb47 5e pop esi

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: abcd

IMAGE_NAME: abcd.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45cb74bf

SYMBOL_NAME: abcd+db47

FAILURE_BUCKET_ID: 0xA_abcd+db47

BUCKET_ID: 0xA_abcd+db47

Followup: MachineOwner

From the disassembly of KiDeliverAPC:

804fee07 64a124010000 mov eax,fs:[00000124] <----- eax pointing to the currently executing thread.
804fee0d 8bf0 mov esi,eax <---- esi is now pointing to currently executing thread.
804fee0f 8b8634010000 mov eax,[esi+0x134]
804fee15 8945e4 mov [ebp-0x1c],eax
804fee18 8b4644 mov eax,[esi+0x44]
804fee1b 898e34010000 mov [esi+0x134],ecx
804fee21 8d8ee8000000 lea ecx,[esi+0xe8]
804fee27 8d55d8 lea edx,[ebp-0x28]
804fee2a 8945e8 mov [ebp-0x18],eax
804fee2d ff1510814d80 call dword ptr [nt!_imp_KeAcquireInStackQueuedSpinLock (804d8110)]
804fee33 c6464900 mov byte ptr [esi+0x49],0x0
804fee37 8d5e34 lea ebx,[esi+0x34] <------ Storing the current thread ApcState in ebx.
804fee3a e9e1000000 jmp nt!KiDeliverApc+0x142 (804fef20)

-Next we jump to the following instruction where we encounter an exception and bug check.

804fef20 391b cmp [ebx],ebx

1: kd> .trap a8eddab8
ErrCode = 00000000
eax=a8eddb38 ebx=00000000 ecx=89a2184a edx=00000000 esi=89a21760 edi=89bf6cb8
eip=804fef20 esp=a8eddb2c ebp=a8eddb60 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
nt!KiDeliverApc+0x142:
804fef20 391b cmp [ebx],ebx ds:0023:00000000=??? <------------ (Exception)ApcState is not valid hence the bug check.

1: kd> dt nt!_kthread 89a21760 -b
nt!_KTHREAD
+0x000 Header : _DISPATCHER_HEADER
+0x000 Type : 0x6 ‘’
+0x001 Absolute : 0 ‘’
+0x002 Size : 0x70 ‘p’
+0x003 Inserted : 0 ‘’
+0x004 SignalState : 0
+0x008 WaitListHead : _LIST_ENTRY [0x89a21768 - 0x89a21768]
+0x000 Flink : 0x89a21768
+0x004 Blink : 0x89a21768
+0x010 MutantListHead : _LIST_ENTRY [0x89a21770 - 0x89a21770]
+0x000 Flink : 0x89a21770
+0x004 Blink : 0x89a21770
+0x018 InitialStack : 0xa8ede000
+0x01c StackLimit : 0xa8edb000
+0x020 Teb : 0x7ffdb000
+0x024 TlsArray : (null)
+0x028 KernelStack : 0xa8eddb5c
+0x02c DebugActive : 0 ‘’
+0x02d State : 0x2 ‘’
+0x02e Alerted : “”
[00] 0 ‘’
[01] 0 ‘’
+0x030 Iopl : 0 ‘’
+0x031 NpxState : 0xa ‘’
+0x032 Saturation : 0 ‘’
+0x033 Priority : 8 ‘’
+0x034 ApcState : _KAPC_STATE <------------ APC state in our thread is valid.
+0x000 ApcListHead :
[00] _LIST_ENTRY [0x89a21794 - 0x89a21794]
+0x000 Flink : 0x89a21794
+0x004 Blink : 0x89a21794
[01] [0x89a2179c - 0x89a2179c]
+0x000 Flink : 0x89a2179c
+0x004 Blink : 0x89a2179c
+0x010 Process : 0x891a9a30
+0x014 KernelApcInProgress : 0 ‘’
+0x015 KernelApcPending : 0 ‘’
+0x016 UserApcPending : 0 ‘’

I reffered the details listed on http://www.osronline.com/showThread.cfm?link=36233.

We need to figure out - how did ebx get zeroed? It was loaded once at the top
of the KiDeliverApc function. There is no other function call within this code path, and as per the above link KiDeliverApc function itself never touches ebx after loading it.

2

> 804fee2d ff1510814d80 call dword ptr

[nt!_imp_KeAcquireInStackQueuedSpinLock (804d8110)]
804fee33 c6464900 mov byte ptr [esi+0x49],0x0
804fee37 8d5e34 lea ebx,[esi+0x34] <------
Storing the current thread ApcState in ebx.
804fee3a e9e1000000 jmp nt!KiDeliverApc+0x142 (804fef20)

-Next we jump to the following instruction where we encounter an exception
and bug check.

804fef20 391b cmp [ebx],ebx

If your analysis is correct ( and I think it is correct ) then I can propose
the following scenario in case of multiple CPUs

804fee37 8d5e34 lea ebx,[esi+0x34] <------
Storing the current thread ApcState in ebx.
804fee3a e9e1000000 jmp nt!KiDeliverApc+0x142 (804fef20)

At that point some IRQ comes and processed, CPUs registers are pushed on the
stack
doIrq() on CPU_A
{
…
place “ebx” on the stack
…
}

while executing doIrq() on CPU_A some routine is called on another CPU_B(
for example - an Irp completion code ), and this routine should have been
synchronized with the thread which is currently on CPU_A, but the
synchronization has not been performed, and this routine has a pointer which
points to CPU_A thread’s stack and write 0x0 using this pointer ( for
example - STATUS_SUCCESS code in Irp->UserIosb). When IRQ processing is
completed the ebx register is restored from the stack and have the zero
value ( i.e. STATUS_SUCCESS code ).

retFromIrq()
{
…
restore “ebx” from the stack
…
}

One of the reasons may be, for example, a lack of checking for
STATUS_PENDING when calling an underlying driver or a system function.

–
Slava Imameyev, xxxxx@hotmail.com

wrote in message news:xxxxx@ntfsd…
> Hi, I got a IRQL_NOT_LESS_OR_EQUAL and I cant figure out the exact root
> cause of the crash. This crash occurs while Ctls+S is pressed twice while
> saving Word files.
>
> Here are the details:
>
> 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: 804fef20, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 00000000
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> nt!KiDeliverApc+142
> 804fef20 391b cmp dword ptr [ebx],ebx
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xA
>
> PROCESS_NAME: svchost.exe
>
> TRAP_FRAME: a8eddab8 – (.trap ffffffffa8eddab8)
> ErrCode = 00000000
> eax=a8eddb38 ebx=00000000 ecx=89a2184a edx=00000000 esi=89a21760
> edi=89bf6cb8
> eip=804fef20 esp=a8eddb2c ebp=a8eddb60 iopl=0 nv up ei ng nz na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010282
> nt!KiDeliverApc+0x142:
> 804fef20 391b cmp dword ptr [ebx],ebx
> ds:0023:00000000=???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 804fef20 to 80543a70
>
> STACK_TEXT:
> a8eddab8 804fef20 badb0d00 00000000 89bf6cb8 nt!KiTrap0E+0x238
> a8eddb60 806e5ef2 00000000 00000000 a8eddb78 nt!KiDeliverApc+0x142
> a8eddb60 806e591a 00000000 00000000 a8eddb78 hal!HalpApcInterrupt+0xc6
> a8eddbe8 a8ebcb47 00000000 891ec320 a8ebcc14 hal!KfReleaseSpinLock+0x1a
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> a8eddc78 a8eb5527 891ec268 89b66d40 a8eb5590 abcd+0xdb47
> a8eddcb8 80578fb3 891ec268 89b66d40 8798fd50 abcd+0x6527
> a8eddd38 805409ac 00000db4 000007ec 00000000
> nt!NtNotifyChangeDirectoryFile+0x227
> a8eddd38 7c91eb94 00000db4 000007ec 00000000 nt!KiFastCallEntry+0xfc
> 0071fb58 7c91dc8b 7c83168b 00000db4 000007ec ntdll!KiFastSystemCallRet
> 0071fb5c 7c83168b 00000db4 000007ec 00000000
> ntdll!NtNotifyChangeDirectoryFile+0xc
> 0071fba4 74ff173e 00000db4 0035f718 00000868
> kernel32!ReadDirectoryChangesW+0x92
> 0071fbd4 74ff16c0 0035f6e4 74ff14d4 00000000
> trkwks!CObjIdIndexChangeNotifier::StartListening+0x45
> 0071fc48 74ff1512 0035f6e4 74ff14d4 00000000
> trkwks!CObjIdIndexChangeNotifier::DoWork+0xff
> 0071fc80 7c937911 0035f6e4 00000000 000ead68
> trkwks!ThreadPoolCallbackFunction+0x52
> 0071fccc 7c93a1bb 74ff14d4 0035f6e4 00000000
> ntdll!RtlpWaitOrTimerCallout+0x73
> 0071fcf8 7c93a109 000ead68 0071fee4 00000000
> ntdll!RtlpProcessWaitCompletion+0x112
> 0071ffb4 7c80b683 00000000 00000000 7c812a5b ntdll!RtlpWaitThread+0x277
> 0071ffec 00000000 7c939fae 00000000 00000000 kernel32!BaseThreadStart+0x37
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> ofant+db47
> a8ebcb47 5e pop esi
>
> SYMBOL_STACK_INDEX: 4
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: abcd
>
> IMAGE_NAME: abcd.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 45cb74bf
>
> SYMBOL_NAME: abcd+db47
>
> FAILURE_BUCKET_ID: 0xA_abcd+db47
>
> BUCKET_ID: 0xA_abcd+db47
>
> Followup: MachineOwner
> ---------
>
>
> From the disassembly of KiDeliverAPC:
> -------------------------------------------------------
> 804fee07 64a124010000 mov eax,fs:[00000124] <----- eax pointing
> to the currently executing thread.
> 804fee0d 8bf0 mov esi,eax <---- esi
> is now pointing to currently executing thread.
> 804fee0f 8b8634010000 mov eax,[esi+0x134]
> 804fee15 8945e4 mov [ebp-0x1c],eax
> 804fee18 8b4644 mov eax,[esi+0x44]
> 804fee1b 898e34010000 mov [esi+0x134],ecx
> 804fee21 8d8ee8000000 lea ecx,[esi+0xe8]
> 804fee27 8d55d8 lea edx,[ebp-0x28]
> 804fee2a 8945e8 mov [ebp-0x18],eax
> 804fee2d ff1510814d80 call dword ptr
> [nt!_imp_KeAcquireInStackQueuedSpinLock (804d8110)]
> 804fee33 c6464900 mov byte ptr [esi+0x49],0x0
> 804fee37 8d5e34 lea ebx,[esi+0x34] <------
> Storing the current thread ApcState in ebx.
> 804fee3a e9e1000000 jmp nt!KiDeliverApc+0x142 (804fef20)
>
> -Next we jump to the following instruction where we encounter an exception
> and bug check.
>
> 804fef20 391b cmp [ebx],ebx
>
> 1: kd> .trap a8eddab8
> ErrCode = 00000000
> eax=a8eddb38 ebx=00000000 ecx=89a2184a edx=00000000 esi=89a21760
> edi=89bf6cb8
> eip=804fef20 esp=a8eddb2c ebp=a8eddb60 iopl=0 nv up ei ng nz na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010282
> nt!KiDeliverApc+0x142:
> 804fef20 391b cmp [ebx],ebx
> ds:0023:00000000=??? <------------ (Exception)ApcState is not valid
> hence the bug check.
>
>
> 1: kd> dt nt!_kthread 89a21760 -b
> nt!_KTHREAD
> +0x000 Header : _DISPATCHER_HEADER
> +0x000 Type : 0x6 ‘’
> +0x001 Absolute : 0 ‘’
> +0x002 Size : 0x70 ‘p’
> +0x003 Inserted : 0 ‘’
> +0x004 SignalState : 0
> +0x008 WaitListHead : _LIST_ENTRY [0x89a21768 - 0x89a21768]
> +0x000 Flink : 0x89a21768
> +0x004 Blink : 0x89a21768
> +0x010 MutantListHead : _LIST_ENTRY [0x89a21770 - 0x89a21770]
> +0x000 Flink : 0x89a21770
> +0x004 Blink : 0x89a21770
> +0x018 InitialStack : 0xa8ede000
> +0x01c StackLimit : 0xa8edb000
> +0x020 Teb : 0x7ffdb000
> +0x024 TlsArray : (null)
> +0x028 KernelStack : 0xa8eddb5c
> +0x02c DebugActive : 0 ‘’
> +0x02d State : 0x2 ‘’
> +0x02e Alerted : “”
> [00] 0 ‘’
> [01] 0 ‘’
> +0x030 Iopl : 0 ‘’
> +0x031 NpxState : 0xa ‘’
> +0x032 Saturation : 0 ‘’
> +0x033 Priority : 8 ‘’
> +0x034 ApcState : _KAPC_STATE <------------
> APC state in our thread is valid.
> +0x000 ApcListHead :
> [00] _LIST_ENTRY [0x89a21794 - 0x89a21794]
> +0x000 Flink : 0x89a21794
> +0x004 Blink : 0x89a21794
> [01] [0x89a2179c - 0x89a2179c]
> +0x000 Flink : 0x89a2179c
> +0x004 Blink : 0x89a2179c
> +0x010 Process : 0x891a9a30
> +0x014 KernelApcInProgress : 0 ‘’
> +0x015 KernelApcPending : 0 ‘’
> +0x016 UserApcPending : 0 ‘’
>
> I reffered the details listed on
> http://www.osronline.com/showThread.cfm?link=36233.
>
> We need to figure out - how did ebx get zeroed? It was loaded once at the
> top
> of the KiDeliverApc function. There is no other function call within this
> code path, and as per the above link KiDeliverApc function itself never
> touches ebx after loading it.
>