BSOD loop occurs at startup with the error IRQL_NOT_LESS_OR_EQUAL, yet safe mode can be accessed.
BSOD loop occurs at startup with the error IRQL_NOT_LESS_OR_EQUAL, yet safe mode can be accessed.
The problem arose from combining two RAM kits, but the motherboard only supports 2x16 or 2x32 configurations, not 4x16. After replacing the RAM units, no BSOD has occurred so far. A persistent BSOD during startup displayed the error IRQL_NOT_LESS_OR_EQUAL, which started suddenly after a shutdown. I was able to boot into Safe Mode from the blue screen and everything appeared normal there. I have dump files available for review if needed.
I attempted several fixes: updated BIOS, ran sfc /scannow and chkdsk, disabled GPU in safe mode, analyzed dump files with WinDBG pointing to specific system files, tried the Intel diagnostic tool but it wouldn’t run in safe mode, performed an overnight memtest86 which passed, and disconnected all other peripherals. Safe mode with networking didn’t provide internet access.
System details:
- CPU: 13900K
- Motherboard: ROG STRIX Z790F LGA1700
- GPU: MSI 4090
- RAM: GSkillz Trident Z5 (16GB x 4) 6400MT/s CL32-39-39-102 1.40V
- Cooler: Lian Li Galahad 240
- Power Supply: MSI MPG A1000G PCIE 5.0 Gold (1000W)
- Storage: SK Hynix Platinum P41 2TB M2 (system drive)
If it can reliably boot into Safe Mode, does that suggest a driver issue? What should I do next?
I don't believe we can be absolutely sure the CPU is the issue, but the clues we have clearly point toward it. If this were my situation, I would replace the CPU next—though I think you should verify that your cooler is powerful enough, since otherwise the replacement might fail too. Keep in mind that if you've already cooked the CPU because of poor cooling, the warranty could be voided.
The dump files are available. I didn't run MemTest with one RAM stick at a time; I used all four simultaneously, and the test completed once everything was connected. The chipset driver is up to date. I also got a quick update—after an image recovery, I was able to boot into Windows 11. However, the BSOD still occurs, so I'm trying to identify the root cause. Also, the Intel Processor diagnostic tool worked fine. Thank you again!
No issue, happy to assist. I'll examine the dumps to see if I can locate anything useful.
One stick at a time, as in shutting down, disabling the PSU, removing RAM sticks, inserting one into the slot specified in the motherboard manual (likely slot A2, second from the CPU), booting with MemTest86, running at least four passes, checking for faulty RAM, then turning it off and removing the module. Repeat with all other three sticks.
Great approach—BIOS and chipset versions are up to date.
If the recovery process succeeded, it could indicate system files were damaged and fixed during recovery. This might also suggest a RAM issue or general data corruption, as files can become corrupted if something disrupts them (especially if the problem was real).
Just wondering, why test the ram stick 1 by 1 if all of them were already tested together? Are you suggesting that even though they passed the test together, they might still fail on their own? It seems a bit unusual to me. I'm just getting started with all this hardware stuff, so I might be asking a simple question. Also, is there a tool to check all the harddrives like memtest86? I've only used the chkdsk command and it shows no problems for all drives. But I've noticed the PC running disk scans before starting Windows a few times now, so I'm a bit worried.
No matter what, everyone begins learning about this at some point. It's normal for things to fail together when tested one by one, and sometimes a single bad RAM stick appears as errors. However, using tools such as Windows Memory Diagnostic or MemTest86 isn't completely foolproof. Occasionally, these methods still miss faulty RAM.
You can also employ utilities like CrystalDiskInfo, HDTune, or HDSentinel to assess drive health by examining SMART data. If the drive shows issues like bad sectors or reallocated areas—common in SSDs where data shifts from damaged to healthy cells—then you can identify the problem.
Manufacturers often supply their own software to monitor storage health and perform tests. I’ll review the dumps once more to check for any issues. It might be a bit of work, but it’s better than ignoring potential problems.
Thank you for clarifying this to me. I'll re-test the RAM as you recommended over the weekend. My Chrome occasionally crashes without a clear reason, which could also point to a RAM problem. Either way, I'll test again and let you know the results.
For the RAM, I'm using the GSkillz Trident Z5 (16GB x 4, 6400MT/s, CL32-39-39-102, 1.40V). I'm not running it at full speed because the system becomes unstable when I enable the XMP profile in Bios. At this time, I'm only testing at 6000.
I'll also check the SSD recommendations you mentioned. I understand it might be costly to replace all faulty components, but it's really frustrating and unsettling when I'm unsure what's causing the issue.
I just wanted to log another BSOD that occurred while using Excel. The PC then entered a disk repair mode before launching Windows (see attached screenshot and dump file in the folder).
Both Chrome and Excel displayed unusual behavior after the image recovery I carried out (crash and restart without cause).
🙁
WinDBG findings from the latest minidump:
PROCESS_NAME: System
READ_ADDRESS: fffff80555f1d470: Unable to get MiVisibleState
Unable to get NonPagedPoolStart
Unable to get NonPagedPoolEnd
Unable to get PagedPoolStart
Unable to get PagedPoolEnd
unable to get nt!MmSpecialPagesInUse
000000000000fffe
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.
EXCEPTION_CODE_STR: c0000005
EXCEPTION_PARAMETER1: 0000000000000000
EXCEPTION_PARAMETER2: 000000000000fffe
EXCEPTION_STR: 0xc0000005
STACK_TEXT:
ffffcc05`56dd51b0 fffff80555f1d470: 00000000`0000000c ffffcc05`56dd7fff
00000000`aa46c4b4 ffff988d`3afdc268 : Ntfs!NtfsGetCachedLengthInsertionPoint+0xbcfc1
ffffcc05`56dd5220 fffff805`58149600 : ffffe00a`12198348 ffffcc05`56dd0000 00000000`aa46c4b4 00000000`0000000c : Ntfs!NtfsInsertCachedLcnAtIndex+0x40
ffffcc05`56dd52b0 fffff805`581492e0 : ffffe00a`12198348 00000000`0dd0ed08 ffffe00a`2553d8a0 ffffe00a`12198300 : Ntfs!NtfsInsertCachedLcn+0x2fc
ffffcc05`56dd5360 fffff805`582c379f : ffffe00a`12198348 ffffcc05`56dd55d0 00000000`0dd0ed08 00000000`00000000 : Ntfs!NtfsInsertCachedRunInTier+0x5c
ffffcc05`56dd5400 fffff805`582c3267 : 00000000`00000000 ffffe00a`255271b0 fffff805`00000007 : Ntfs!NtfsScanEntireBitmap+0x52b
ffffcc05`56dd5820 fffff805`582d8533 : ffffe00a`12198348 ffffcc05`56dd5a40 00000000`00000020 ffffe00a`01d181c6 : Ntfs!NtfsBackgroundBitmapScanWorker+0x17
ffffcc05`56dd5850 fffff805`55434f85 : ffffe00a`01d1ebb0 ffffe00a`01d18040 ffffe00a`01d1ebb0 ffffe00a`00000000
OS: Ntfs!NtfsGetCachedLengthInsertionPoint+0xbcfc1
MachineOwner
The disk checking could stem from Windows failing to shut down correctly. I would run RAM tests using MemTest86 with the maximum number of passes for each plugged-in module, possibly needing to do this overnight as it may take several hours. Additionally, I would verify the storage condition just in case. The debugger reports an error: (NTSTATUS) 0xc0000005, indicating the instruction attempted to access invalid memory. This typically points to driver or hardware problems such as RAM. When opening the dump in the debugger, it notes "Probably caused by hardware_ram (PAGE_NOT_ZERO)." I would execute SFC /scannow via an elevated Command Prompt—select CMD from the Windows menu, right-click it, and run as administrator. Then input SFC /scannow and press Enter. The system file checker will assess Windows files, repairing any issues and requiring a reboot afterward. Even though MemTest produces an error or fails, I would test with another RAM module to see if the BSOD persists.