Question I am about to lose my mind - - - - NTOSKRNL.exe, IRQL_NOT_LESS_OR_EQUAL_THAN ?

Toggle sidebar Toggle sidebar
C

chris9486

Distinguished
Jan 11, 2013
24
1
18,510
Hi,
I wondered if I could get some help with this. I have been through extensive troubleshooting using Microsoft Forums, but it seems even the agents/ms moderator experts can't help. Nobody is replying to me now.

I am at an advanced stage of troubleshooting now, but I wondered if anyone could look at my mini dumps please?

I have a mix of dumps from the BSOD and some with driver verifier active. (https://1drv.ms/f/s!AqYnBBWuivs3gqJ4d3c4m-lpXQLq9Q?e=LDFWeM) Some one suggested it was my bluetooth adaptor, onboard. But I disabled this and still got errors.

My hardware
AMD Ryzen 5 3600
Gigabyte B450 I Aorus Pro Wifi-CF (latest BIOS installed)
Gigabyte Radeon RX 570 4GB GDDR5
2 x 8GB Kingston KHX2400C15
Kingston 256GB SSD
Western Digital 2TB

Steps I have taken.

  1. Fresh installation of Windows 11, updated, and updated all motherboard drivers available. Graphics card updated too. BIOS updated.
  2. Malwarebytes scan completed and just brought up issues with chrome.
  3. DISM.EXE has been completed.
  4. SFC /SCANNOW has been completed.
  5. RAM tested with MEMTEST x86, came back clear.
  6. Memory diagnostic tool run, came back clear.
  7. Seatools run for my hard drives, came back clear.
  8. Disabled bluetooth and wifi adaptor as it was mentioned it was the issue on the microsoft boards.
  9. Monitored my temps using HWINFO with nothing troubling coming back.
  10. Used a version of Windows 11 from UUP, dated back in May.
  11. Removed one stick of RAM and then swapped with the other to try identify an issue.
  12. Bought new RAM to test from a local shop. (they kindly let me return it)
  13. Disconnected 2TB hard drive.
  14. Borrowed a 750w psu that was almost brand new from a friend.
  15. Borrowed an ITX motherboard, new condition, from the same friend. (clean install of windows, new compound on the processor etc)
  16. Borrowed a graphics card from the same friend, a GeForce.
  17. Removed all peripherals, switched to a USB keyboard and mouse.

I may have tried some things but missed them out, I’ve gone through that much!

After trying all of the above, nothing has worked. I am not sure what else there is that I can do. I don’t want to go out and buy a new SSD because I don’t know if this will work. My 2TB drive has too much data on it for me to back it up or erase it for me to switch to that to install Windows.

Please can anyone help?
 
Last edited:
To me, not clear what problem you are troubleshooting? Perhaps provide background on the symptoms that brought you to all of the troubleshooting you list?
 
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.
 
  • Like
Reactions: satrow and Colif
ubuysa said:
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.
Click to expand...
Thank you! This is the most comprehensive answer I've had to date.

Both sets of RAM tested are on the QVL. I tested the same RAM on the replacement motherboard. Still BSOD.

My SSD is a 2.5 inch drive.

I've borrowed a 4TB USB hard drive from a friend to back up my 2TB. I'm going to erase that and then try a clean install on the 2TB. I'll be sure to remove the SSD.

I just need it to copy the data over without it going to a BSOD. I'm ending up doing it in sections and I'm on my 5th now.

I'll let you know how I got on.
 
ubuysa said:
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.
Click to expand...
My 2nd attempt to complete this.

I've uploaded new dump files.

I went ahead and installed Win 11 on my 2TB drive with the SSD disconnected. During setup, I got a BSOD with the same errors - the earlier dump file. The 2nd dump file is from when I tried to write this post and I got the same error.

My SSD is a Kingston V300. It wasn't showing in the 1.5 version. Having just re-read the page there's the 1.1 version for older drives.

I think it is safe to say I can eliminate my SSD drive. I have gone ahead and ordered some Corsair vengence RAM from Amazon. It is on the QVL for my motherboard/CPU combination. I am not 100% sure the RAM I used previously was even decent quality.

Back to the RAM I have installed, it is not showing any errors on memory diagnostic tool, MEMTEST 86 and I get a BSOD with just 1 of the sticks in and alternated. Can both sticks of RAM be bad at the same time, and also not show any errors on diagnostic tools?

Edit: I have done some more digging on the QVL list - which I usually check (I used to work for an IT company building desktops for schools and educational institutes), and I have found an issue. My current RAM is not on the QVL for this board. I did a bit more digging - I never delete my emails with purchase receipts on - going back to the purchase receipt, the RAM MFR# on my invoice is on the QVL - so it looks like they have delivered the incorrect RAM that I ordered. With it being Jan 2020 when I bought the hardware, there won't be much I can do about that now.

Can non QVL RAM work for 3 yrs and then just both sticks give up at the same time?
 
Last edited:
chris9486 said:
Can non QVL RAM work for 3 yrs and then just both sticks give up at the same time?
Click to expand...
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?
 
Nothing has changed in the house electrical wise. Its been several years since we had a new fusebox. I will try it somewhere else.

I will try running safe mode after work today. See if it will still BSOD.

I don't think the motherboard is the problem, as I still got a BSOD with the replacement motherboard. So it's something to do with my hardware, as I used my RAM, SSD, graphics card etc and still got the BSOD.

The new RAM arrives tomorrow so I will try one bank at a time.
 
Last edited:
ubuysa said:
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?
Click to expand...

New RAM arrived yesterday, corsair vengeance that's on the QVL. One stick is dead, great start. I know it's dead because with it plugged into my motherboard, it just won't boot up. All of the fans go onto full speed and stay that way, with nothing appearing on my monitor. Put the single 8GB in and left an 11hr youtube video running. BSOD after about 9hrs.

I'm convinced now it's my CPU. I've changed every other part for testing and the one constant has been my CPU. I don't think it's heat related as my temps run solid at 37 to 45 degrees Celsius. That's well within the operating range.

I've tested/swapped my motherboard, my RAM x 2, my PSU, graphics card, tried installing Windows on a different drive with all other drives removed. All through these tests, I have kept the same CPU.

I've not been able to get into safe mode. I can't get any USB devices to work so I can't select the Safe mode option when it boots up.

My house has two electric socket rings separated in the consumer unit. Upstairs and downstairs. If I tried it on a different ring, would that be classed trying it elsewhere? It's currently on the upstairs ring.

Latest dump is here MiniDumps
 
Last edited:
It's definitely worth trying it on a different ring. That's not quite as good as running it somewhere else but it's probably good enough.

If you think it's the CPU you might just try removing and reseating it? A bit of a faff repasting and all but you never know...
 
ubuysa said:
It's definitely worth trying it on a different ring. That's not quite as good as running it somewhere else but it's probably good enough.

If you think it's the CPU you might just try removing and reseating it? A bit of a faff repasting and all but you never know...
Click to expand...
I'm not sure if reseating will make much of a difference. When I used the new motherboard to test it was reseated then, back into my regular motherboard. I checked all pins and repasted it.

I'm getting to the point where I'm just fed up now because it just doesn't seem to be solvable. Because it's my mb, cpu or ram or a combination, I've just priced up new ones. But first I'm getting the cpu, as it's compatible with my current board. Meaning I can swap out the cpu and check to see if the new one stops the bsods. The new one is an apu so I can remove my graphics card also.

If it solves the problem, great all I needed was a new cpu. If it doesn't, I just need to buy a new mb and RAM.
 
You seem to have a very good handle on troubleshooting this. I don't have anything new to suggest, though others more hardware knowledgeable than I might do. Let us know how you get on.
 
ubuysa said:
You seem to have a very good handle on troubleshooting this. I don't have anything new to suggest, though others more hardware knowledgeable than I might do. Let us know how you get on.
Click to expand...
Without jinxing it, my processor was broken.

New processor in, all my old hardware. It has run 36 hrs without a BSOD. Before I would get one within 24 hrs. I noticed one of my CPU pins was slightly bent, I am not sure when this happened but I doubt it is the reason. It wouldn't run 3 years fine with a bent pin, and then all of a sudden stop working. I am guessing it got bent from the frustration of me moving hardware between boards.

Thank you for the help, without it, I would have been looking at drivers still by now. I am surprised that nobody on the MS forums could tell me what the source of the issue was (hardware). Everyone was telling me it was software based.
 
  • Like
Reactions: ubuysa
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom