Author Topic: IRQL_NOT_LESS_OR_EQUAL ntoskrnl.exe BSOD in windows 7  (Read 2026 times)

0 Members and 1 Guest are viewing this topic.

Offline sidball

  • Newbie
  • *
  • Posts: 12
IRQL_NOT_LESS_OR_EQUAL ntoskrnl.exe BSOD in windows 7
« on: July 28, 2019, 01:14:32 AM »
I'm using avast free v19.6.2383 (build 19.6.4546.511) in windows 7 SP1 64 bit. Recently I got same IRQL_NOT_LESS_OR_EQUAL ntoskrnl.exe BSOD two times in 12 days interval. I'm not sure what caused it, but when both BSOD events happened, I had a browser opened with html5 video running (but I usually browse websites with streaming video when using the PC, so it might not be related at all).

I checked the kernel dump file and run windbg to analyze the file. Here is the result:

Code: [Select]
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

Use !analyze -v to get detailed debugging information.

BugCheck A, {98, 2, 0, fffff8000406fa34}

Unable to load image \SystemRoot\system32\drivers\aswMonFlt.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for aswMonFlt.sys
*** ERROR: Module load completed but symbols could not be loaded for aswMonFlt.sys
Probably caused by : luafv.sys ( luafv!LuafvPreReleaseForSectionSynchronization+83 )

Followup: MachineOwner

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

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.
Arg1: 0000000000000098, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff8000406fa34, address which referenced memory

Debugging Details:

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff8000429f100


fffff800`0406fa34 0fbaa19800000014 bt      dword ptr [rcx+98h],14h




PROCESS_NAME:  stardict.exe

TRAP_FRAME:  fffff8800b705a40 -- (.trap 0xfffff8800b705a40)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa800c4c0e38 rbx=0000000000000000 rcx=0000000000000000
rdx=fffffa800c4c0e38 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8000406fa34 rsp=fffff8800b705bd0 rbp=fffffa800b4eb000
 r8=fffff800041e6840  r9=0000000000000000 r10=0000000000000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
fffff800`0406fa34 0fbaa19800000014 bt      dword ptr [rcx+98h],14h ds:d220:00000000`00000098=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff800040a3e69 to fffff80004095aa0

fffff880`0b7058f8 fffff800`040a3e69 : 00000000`0000000a 00000000`00000098 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`0b705900 fffff800`040a1c88 : 00000000`00000000 00000000`00000098 fffff8a0`12a68a00 fffffa80`0cc1c820 : nt!KiBugCheckDispatch+0x69
fffff880`0b705a40 fffff800`0406fa34 : fffffa80`0cc1c820 fffffa80`0cc1c820 fffffa80`0b4eb010 fffffa80`07a0fcb0 : nt!KiPageFault+0x448
fffff880`0b705bd0 fffff800`04071403 : fffffa80`0cc1c820 fffffa80`0b4eb010 fffffa80`0bda4478 00000000`00000000 : nt!CcChangeBackingFileObject+0x54
fffff880`0b705c10 fffff880`070791c3 : fffff8a0`1006d280 fffff8a0`14f59500 00000000`00000000 fffffa80`0b4eb010 : nt!FsRtlChangeBackingFileObject+0x27
fffff880`0b705c40 fffff880`012020f7 : 00000000`00000000 fffffa80`0b4eb530 fffff880`0b705ea8 00000000`00000000 : luafv!LuafvPreReleaseForSectionSynchronization+0x83
fffff880`0b705c70 fffff880`012019e2 : fffff880`0b705db0 f4636553`0b705d00 fffff8a0`03d64e00 00000000`000000fe : fltmgr!FltpPerformPreCallbacks+0x50b
fffff880`0b705d80 fffff800`0404d123 : fffffa80`073d68e0 fffffa80`0cc1c801 fffff880`0b705ef8 fffff880`0b706118 : fltmgr!FltpPreFsFilterOperation+0x2d2
fffff880`0b705e10 fffff800`04309116 : fffff880`01204200 00000000`00000000 fffffa80`0cc1c820 fffff880`01201710 : nt!FsFilterPerformCallbacks+0xd3
fffff880`0b705e70 fffff800`041a6691 : 00000000`00000000 00000000`08000000 00000000`08000000 00000000`00000002 : nt!FsRtlReleaseFile+0xb6
fffff880`0b706110 fffff880`0669ba7f : 00000000`00000000 fffff880`0b706640 00000000`00000000 6e4d7641`012047e5 : nt!FsRtlCreateSectionForDataScan+0x171
fffff880`0b7061a0 00000000`00000000 : fffff880`0b706640 00000000`00000000 6e4d7641`012047e5 fffffa80`00000005 : aswMonFlt+0x11a7f


fffff880`070791c3 4c8b5e10        mov     r11,qword ptr [rsi+10h]


SYMBOL_NAME:  luafv!LuafvPreReleaseForSectionSynchronization+83

FOLLOWUP_NAME:  MachineOwner


IMAGE_NAME:  luafv.sys


FAILURE_BUCKET_ID:  X64_0xA_luafv!LuafvPreReleaseForSectionSynchronization+83

BUCKET_ID:  X64_0xA_luafv!LuafvPreReleaseForSectionSynchronization+83

Followup: MachineOwner

Here is the dump file link:

According to the analysis, luafv.sys might be the culprit, but this is a driver part of windows os, and I googled that it's for UAC file virtualization. But then I saw the stack info, there is this line at the last line:

Code: [Select]
fffff880`0b7061a0 00000000`00000000 : fffff880`0b706640 00000000`00000000 6e4d7641`012047e5 fffffa80`00000005 : aswMonFlt+0x11a7f
Note that the second BSOD dump also has exactly same stack info too, it just differs in the memory address.

So I'm wondering if the BSOD is related to avast shield?
« Last Edit: July 29, 2019, 10:39:31 PM by sidball »

Offline kwiq

  • Avast team
  • Sr. Member
  • *
  • Posts: 254
Re: IRQL_NOT_LESS_OR_EQUAL ntoskrnl.exe BSOD in windows 7
« Reply #1 on: July 31, 2019, 12:30:48 PM »
Hi sidball,
It seems to be win7 specific behaviour.
Thank you for dump file we found a workaround to avoid this kind of BSOD.