I have a problem that's making me crazy - an error from NTOSKRNL.exe says "IRQL_NOT_LESS_OR_EQUAL". Did you see this?
I have a problem that's making me crazy - an error from NTOSKRNL.exe says "IRQL_NOT_LESS_OR_EQUAL". Did you see this?
Hey, I'm really stuck here and need some advice. I've tried everything in Microsoft forums, but even the experts say nothing works anymore. No one is replying to me right now. I think things are very advanced for me, so could someone please check my mini dumps? They have a mix of BSOD errors and drivers running "verifier." (https://1drv.ms/f/s!AqYnBBWuivs3gqJ4d3c4...Q?e=LDFWeM)
Someone said it was my Bluetooth or onboard adapter, but I turned them off and still got errors. My PC is an AMD Ryzen 5 3600 on a Gigabyte B450 board with an Aorus Pro WiFi card (I have the latest BIOS). I also have a Radeon RX 570, two sticks of Kingston RAM at 8GB each, a 256GB SSD, and a 2TB Western Digital drive.
Here is what I've done:
1. I did a fresh Windows 11 install and updated everything (motherboard drivers, graphics card, BIOS).
2. I ran malwarebytes, DISM.EXE, SFC /SCANNOW, and RAM tests which all said clear.
3. I used SEATools to check my drives, they were fine.
4. I disabled Bluetooth and WiFi because Microsoft suggested it was the problem.
5. I checked temperatures with HWINFO and saw nothing bad.
I tried swapping one stick of RAM for another from a local shop (they let me return it). I also swapped the hard drive to test it. To make sure this wasn't my hardware, I borrowed a new power supply, an ITX motherboard, a GeForce graphics card, and a USB keyboard/mouse from a friend.
I'm almost done trying things. If nothing works, I don't know what else to try. I really can't go out and buy a new SSD because I am afraid it won't work. My 2TB drive is full of data that I want to keep, so I cannot erase it or back it up yet.
Please help me figure this out!
To me, it's hard to tell exactly what issue you're fixing. Maybe you could share more details about those strange signs or symptoms that led you down this long path of trying different things?
All of your BSODs have exactly the same stop code; 0xA IRQL_NOT_LESS_OR_EQUAL, which means that a n invalid memory reference occurred whilst running at an elevated IRQL. Looking into the dumps they all fail in exactly the same place, in the nt!SwapContext function, and at exactly the same instruction, the XRSTORS [RCX] that restores status from the saved status area pointed to by the RCX register... Code: TRAP_FRAME: fffffe831d6f3f40 -- (.trap 0xfffffe831d6f3f40) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0000000000000005 rbx=0000000000000000 rcx=fffffe831d6f4cc0 rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000 rip=fffff8055b220731 rsp=fffffe831d6f40d0 rbp=000f807fb4bbbdff r8=0000000000000000 r9=00000000000000e6 r10=00000632006080e6 r11=fffffe8319a44f00 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl zr ac po cy nt!SwapContext+0x501: fffff805`5b220731 0fc719 xrstors [rcx] Resetting default scope The contents of the RCX register (0xFFFFFE831D6F4CC0) do apparently point to a memory location that exists... Code: 0: kd> db fffffe831d6f4cc0 fffffe83`1d6f4cc0 7f 02 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ fffffe83`1d6f4cd0 00 00 00 00 00 00 00 00-80 1f 00 00 00 00 00 00 ................ fffffe83`1d6f4ce0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ fffffe83`1d6f4cf0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ fffffe83`1d6f4d00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ fffffe83`1d6f4d10 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ fffffe83`1d6f4d20 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ fffffe83`1d6f4d30 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ This means that we didn't take a page fault per se, but we did access a memory location that doesn't contain what we expected in some way. Certainly the contents of the RCX register pointer doesn't look much like saved status. All of the dumps are identical in this respect, however one of them also contains some other very important information, CHKIMG errors... Code: CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt fffff8014140ea41-fffff8014140ea43 3 bytes - nt!KiSchedulerApc+41 [ 7b fc 29:3b 07 2a ] fffff8014150350e-fffff80141503512 5 bytes - nt!MiDeleteProcessShadow+82 (+0xf4acd) [ d0 be 7d fb f6:f0 f9 f3 e7 cf ] fffff80141503560 - nt!MiDeleteProcessShadow+d4 (+0x52) [ f6:cf ] fffff8014159a543-fffff8014159a544 2 bytes - nt!PpmParkReportParkedCores+53 (+0x96fe3) [ 79 41:39 4c ] fffff8014159a559-fffff8014159a55a 2 bytes - nt!PpmParkReportParkedCores+69 (+0x16) [ 63 41:23 4c ] fffff8014159a56a-fffff8014159a56b 2 bytes - nt!PpmParkReportParkedCores+7a (+0x11) [ 52 41:12 4c ] fffff8014159a578-fffff8014159a579 2 bytes - nt!PpmParkReportParkedCores+88 (+0x0e) [ 44 41:04 4c ] fffff8014159a5ad-fffff8014159a5ae 2 bytes - nt!PpmParkReportParkedCores+bd (+0x35) [ 0f 41:cf 4b ] fffff801415adf0e-fffff801415adf0f 2 bytes - nt!KiBalanceSetManagerDeferredRoutine+3e (+0x13961) [ ae 07:6e 12 ] fffff801415f5c95-fffff801415f5c96 2 bytes - nt!KiTimerExpirationDpc+35 (+0x47d87) [ 27 8a:e7 94 ] fffff801417c820f-fffff801417c8210 2 bytes - nt!KiSoftParkElectionDpcRoutine+ef (+0x1d257a) [ ad 64:6d 6f ] 25 errors : !nt (fffff8014140ea41-fffff801417c8210) The !CHKIMG output indicates corruptions in the images of executable files by comparing the file images in the dump with known good copies from the Microsoft Symbol Server. As you can see from the above, there were corruptions found in several Microsoft modules. If we expand on the first of those (nt!KiSchedulerApc) as an example, you can see these corruptions more clearly... Code: 0: kd> !chkimg -db nt!KiSchedulerApc 25 errors : nt!KiSchedulerApc (fffff8014140ea41-fffff801417c8210) fffff8014140ea40 e8 *3b *07 *2a 00 44 8b 6b 78 83 64 24 30 00 41 81 .;.*.D.kx.d$0.A. ... fffff80141503500 00 00 00 8a d8 0f 84 c8 e9 1e 00 48 bf 00 *f0 *f9 ...........H.... fffff80141503510 *f3 *e7 *cf ff ff 41 bf 00 01 00 00 48 8b cf e8 dd .....A.....H.... ... fffff80141503560 *cf ff ff 48 03 f8 48 8b cf e8 92 dc f3 ff 48 8d ...H..H.......H. ... fffff8014159a540 24 28 e8 *39 *4c 11 00 83 64 24 20 00 48 8d 8d 78 $(.9L...d$ .H..x fffff8014159a550 02 00 00 45 8b c6 33 d2 e8 *23 *4c 11 00 45 8b c6 ...E..3..#L..E.. fffff8014159a560 48 8d 8d 68 01 00 00 33 d2 e8 *12 *4c 11 00 45 8b H..h...3...L..E. fffff8014159a570 c6 48 8d 4d 58 33 d2 e8 *04 *4c 11 00 83 3d 8d b0 .H.MX3...L...=.. ... fffff8014159a5a0 c7 85 70 02 00 00 01 00 20 00 33 d2 e8 *cf *4b 11 ..p..... .3...K. ... fffff801415adf00 33 d2 44 8d 42 5f 48 8d 88 38 ff ff ff e8 *6e *12 3.D.B_H..8....n. ... fffff801415f5c90 00 00 33 d2 e8 *e7 *94 0b 00 f7 05 e5 fc b9 00 00 ..3............. ... fffff801417c8200 00 48 89 83 90 06 00 00 41 b8 80 03 00 00 e8 *6d .H......A......m Each asterisk (*) indicates a byte in the image in the dump (and thus in memory) that varies from the copy fetched from the Microsoft Symbol Server. You can see widespread and random corruption in just this one image. These kinds of corruptions are either caused by bad RAM - such that the copy of the executable read into memory was corrupted by the bad RAM - or, they are caused by a bad system drive - such that the executable on the drive is corrputed. The analysis triage, which is good but imperfect, suggests that this is a memory corruption problem... Code: MODULE_NAME: memory_corruption IMAGE_NAME: memory_corruption MEMORY_CORRUPTOR: LARGE STACK_COMMAND: .cxr; .ecxr ; kb FAILURE_BUCKET_ID: MEMORY_CORRUPTION_LARGE That's not necessarily true, as I've mentioned this could also be a bad system drive. What you can be fairly certain of however, is that this is a hardware problem; either bad RAM, a bad systemn drive, a bad motherboard (unlikely), bad/poorly connected cables, or even a bad PSU. You have tested your RAM and even tried other RAM, so we can probably discount that. It is important however, when you're getting BSODs that could be RAM related, to check that the RAM you're using in on the QVL for your motherboard. This lists the RAM that has been tested with the board and is validated as compatible. RAM not on the QVL may well still work just fine, but it still raises a question mark. You don't say what type of Kingston SSD you have? I assume that's your system drive? If it's an M.2 drive then try removing and re-seating it firmly. I have seen many issues that were resolved by re-seating the M.2 drive. I'm wondering whether that port design is as reliable as we're led to beleive? Kingston don't have a diagnostic tool for their SSDs but they do have an SSD Manager . Download that and post a screenshot of the SMART data. Also check for a firmware update for the drive. If it's a SATA SSD then check all the cables and connector, at both ends. SATA cables do come adrift sometimes. Check also the drive power connector, also at both ends. The only real way to eliminate the SSD as the cause is to try a different SSD. Note: When you install WIndows from scratch always disconnect all drives excvept the system drive (so unplug yourWD drive). This stops the installer from writing the boot data on a different drive.
Thanks so much! That's exactly what I needed too. Both sets of RAM passed the test. I tried using them on the new board, but it still says BSOD. My SSD is a 2.5 inch drive. I borrowed a big USB hard drive from someone else to copy my files onto. I'm going to wipe that one and try a fresh install on my 2TB drive instead. I'll make sure to take out the old SSD while doing this. All I need is for it to copy the data without crashing. I'm breaking the job into small parts, and I've already tried this five times now. Let me tell you how it goes!
Here is a rewrite with simpler words:
I tried again to finish this job. I have uploaded fresh files. I installed Win 11 on my big hard drive (SSD off) while setting things up. It happened a BSOD, and the exact same errors appeared in the old file. The second file came from when I posted this, and it had the same problem. My SSD is a Kingston V300 model. When I first read that page back, there was an older version for slow drives. I think I can rule out my hard drive entirely. I bought some Corsair vengence RAM on Amazon because it fits my motherboard and CPU perfectly. I am not sure if the old RAM was really good quality. On the RAM I put in now, there are no errors shown by the memory test tool or MEMTEST 86. However, sometimes when only one stick is plugged in, a BSOD with an error happens. Can both sticks be broken at once and still show no signs on the tools? Edit: After checking the QVL list more closely, I found something wrong with my board. Back then, I worked for an IT company making computers for schools, so I know how to spot mistakes in RAM. When I looked at the purchase receipt, the manufacturer number was listed there, and it is on the QVL list. So it looks like I received the wrong RAM. The date of the purchase was January 2020, so by now I probably can't fix this anymore. Can non-QVL RAM last for three years before both sticks fail at once?
Any RAM can fail after three years - or three weeks for that matter. That said, I don't think this is a QVL problem per se and clearly it wasn't the Kingston system drive either. I'm now wondering whether a RAM slot on the motherboard might be flaky? Is it possible to try one RAM stick in different slots (if the board allows that)? Another useful test would be start Windows in Safe Mode . I think we're pretty sure that this is a hardware problem but if you can make it BSOD in Safe Mode then we can be all but certain that it's hardware. Based on things you've tried about all that's left is the motherboard. Something else to think about, and something I've seen a couple of times before, is whether this could be environmental?Have you installed a new refrigerator, washing machine, or any other electrically noisy device in your home recently? Is it at all possible to try your PC at someone else's home to be sure it's not something in yours?