Question PC crashes to a black screen then reboots, typically when I play League of Legends and CS2 ?

[Crinot51]

You don't fancy uploading the logs then?

That dump is identical to the earlier one, except that CS2.exe was the process in control. I think now, in addition to uploading the logs, you need to enable Driver Verifier...

Driver Verifier subjects selected drivers (typically all third-party drivers) to extra tests and checks every time they are called. These extra checks are designed to uncover drivers that are misbehaving. If any selected driver fails any of the Driver Verifier tests/checks then Driver Verifier will BSOD. The resulting minidump should contain enough information for us to identify the flaky driver. It's thus essential to keep all minidumps created whilst Driver Verifier is enabled.

To enable Driver Verifier do the following:

1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.

If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.

Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.

2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.

3. On that initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.

4. On the second dialog check (click) the checkboxes for the following tests...

• Special Pool
• Force IRQL checking
• Pool Tracking
• Deadlock Detection
• Security Checks
• Miscellaneous Checks
• Power framework delay fuzzing
• DDI compliance checking

Then click the Next button.

5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.

6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).

7. Now check (click) ALL drivers that DO NOT have Microsoft as the provider (ie. check all third-party drivers).

8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...

• Wdf01000.sys
• ndis.sys
• fltMgr.sys
• Storport.sys

These are high-level Microsoft drivers that manage lower-level third-party drivers that we otherwise wouldn't be able to trap. That's why they're included.

9. Now click Finish and then reboot. Driver Verifiier will be enabled.

Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.

Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.

10. Leave Driver Verifier running for 48 hours, use your PC as normal during this time, but do try and make it BSOD. Use every game or app that you normally use, and especially those where you have seen it BSOD in the past. If Windows doesn't automatically reboot after each BSOD then just reboot as normal and continue testing.

Note: Because Driver Verifier is doing extra work each time a third-party driver is loaded you will notice some performance degradation with Driver Verifier enabled. This is a price you'll have to pay in order to locate any flaky drivers. And remember, Driver Verifier can only test drivers that are loaded, so you need to ensure that every third-party driver gets loaded by using all apps, features and devices.

11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.

Should you wish to check whether Driver Verfier is enabled or not, open a command prompt and enter the command verifier /query. If drivers are listed then it's enabled, if no drivers are listed then it's not.

12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Zip these files up if you like, or not as you choose. Upload the file(s) to the cloud with a link to it/them here (be sure to make it public).

I did driver verifier before and it found nothing on the previous run. Also it's impossible to play CS2 with verifier running, not sure if that is required or if it just has to be open. I'll open it now to see if it catches anything.

 

[ubuysa]

Driver Verfier needs to be run with the specific options I asked for. Running it with the default options isn't good enough.

 

[Crinot51]

Driver Verfier needs to be run with the specific options I asked for. Running it with the default options isn't good enough.

I ran it with the specific options you specified back on November 10th and it found nothing. I'm currently running it again with the specified options but wanted to mention this since we had done this test already and it came back with nothing.

I do want to add that my current RAM is on the QVL for this Motherboard

Amazon.com

I have the RAM linked above but the 32GB version.

 

[Crinot51]

You don't fancy uploading the logs then?

That dump is identical to the earlier one, except that CS2.exe was the process in control. I think now, in addition to uploading the logs, you need to enable Driver Verifier...

Driver Verifier subjects selected drivers (typically all third-party drivers) to extra tests and checks every time they are called. These extra checks are designed to uncover drivers that are misbehaving. If any selected driver fails any of the Driver Verifier tests/checks then Driver Verifier will BSOD. The resulting minidump should contain enough information for us to identify the flaky driver. It's thus essential to keep all minidumps created whilst Driver Verifier is enabled.

To enable Driver Verifier do the following:

1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.

If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.

Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.

2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.

3. On that initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.

4. On the second dialog check (click) the checkboxes for the following tests...

• Special Pool
• Force IRQL checking
• Pool Tracking
• Deadlock Detection
• Security Checks
• Miscellaneous Checks
• Power framework delay fuzzing
• DDI compliance checking

Then click the Next button.

5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.

6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).

7. Now check (click) ALL drivers that DO NOT have Microsoft as the provider (ie. check all third-party drivers).

8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...

• Wdf01000.sys
• ndis.sys
• fltMgr.sys
• Storport.sys

These are high-level Microsoft drivers that manage lower-level third-party drivers that we otherwise wouldn't be able to trap. That's why they're included.

9. Now click Finish and then reboot. Driver Verifiier will be enabled.

Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.

Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.

10. Leave Driver Verifier running for 48 hours, use your PC as normal during this time, but do try and make it BSOD. Use every game or app that you normally use, and especially those where you have seen it BSOD in the past. If Windows doesn't automatically reboot after each BSOD then just reboot as normal and continue testing.

Note: Because Driver Verifier is doing extra work each time a third-party driver is loaded you will notice some performance degradation with Driver Verifier enabled. This is a price you'll have to pay in order to locate any flaky drivers. And remember, Driver Verifier can only test drivers that are loaded, so you need to ensure that every third-party driver gets loaded by using all apps, features and devices.

11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.

Should you wish to check whether Driver Verfier is enabled or not, open a command prompt and enter the command verifier /query. If drivers are listed then it's enabled, if no drivers are listed then it's not.

12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Zip these files up if you like, or not as you choose. Upload the file(s) to the cloud with a link to it/them here (be sure to make it public).

Was there something else you wanted me to upload besides the minidump? You had mentioned some logs but I wasn't sure what you meant or how to get them for you.

I am still currently running the driver verifier at this time.

 

[Crinot51]

Was there something else you wanted me to upload besides the minidump? You had mentioned some logs but I wasn't sure what you meant or how to get them for you.

I am still currently running the driver verifier at this time.

New crash dump: https://www.mediafire.com/file/0wsx16yieg318sn/112023-6593-01.dmp/file

Had an error code of KMODE_EXCEPTION_NOT_HANDLED

I'm slowly starting to think something is wrong with the MB or DIMM slots on my PC.

 

[ubuysa]

Sorry, I didn't realise you'd run Driver Verifier with the correct options already. This latest dump also points at RAM, I'll explain why.

Firstly the exception code in the dump is 0xC0000005...

FAILURE_BUCKET_ID:  0x1E_c0000005_W_nt!RtlpSanitizeContextFlags

That's an memory access violation and it means that the page that was referenced is either not allocated, paged-out (and not on the page file), or the RAM holding the page is bad. This is often seen in flaky third-party drivers that either screw-up their memory allocations or their memory pointers, but the only function calls on the call stack (which is a history of the function calls leading up to the bugcheck) are Windows kernel functions and they never screw-up memory allocations or memory pointers. That just leaves bad RAM.

In addition, if you look at the basic call stack you can see apparent calls to function addresses for which we have no symbols (we just see the address)...

0: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffffe582`fce3ee08 fffff803`65c7a3fb     nt!KeBugCheckEx
01 ffffe582`fce3ee10 fffff803`65c1186c     nt!KiDispatchException+0x14108b
02 ffffe582`fce3f4d0 fffff803`65c0d2bd     nt!KiExceptionDispatch+0x12c
03 ffffe582`fce3f6b0 fffff803`65aaa31e     nt!KiPageFault+0x43d
04 ffffe582`fce3f846 f80365e6`53420000     nt!RtlpSanitizeContextFlags+0x4a
05 ffffe582`fce3f84e 00000000`0001ffff     0xf80365e6`53420000
06 ffffe582`fce3f856 d5882381`4b100000     0x1ffff
07 ffffe582`fce3f85e 00000000`3000ffff     0xd5882381`4b100000
08 ffffe582`fce3f866 00000000`00000000     0x3000ffff

Those non-symbol addresses at the bottom of the stack there are clearly invalid. They are all non-canonical (not in the usable address range) and some of them are not even full 64-bit addresses. This is strongly indicative of bad RAM - but you've replaced the RAM with QVL certified RAM, so it';s not the RAM sticks themselves. It's not a rogue third-party driver either, because Driver Verifier didn't BSOD any of them, so all that's left is the board.

Are you sure you're running the latest BIOS update for your board? AMD CPUs also required microcode called AGESA (AMD Generic Encapsulated Software Architecture) which is shipped in BIOS updates. The latest BIOS update for your board is dated 27th October 2023 and it does contain an AGESA update (1.2.0.1B), IMO you want to be on that BIOS version.

 

[Crinot51]

Sorry, I didn't realise you'd run Driver Verifier with the correct options already. This latest dump also points at RAM, I'll explain why.

Firstly the exception code in the dump is 0xC0000005...

FAILURE_BUCKET_ID:  0x1E_c0000005_W_nt!RtlpSanitizeContextFlags

That's an memory access violation and it means that the page that was referenced is either not allocated, paged-out (and not on the page file), or the RAM holding the page is bad. This is often seen in flaky third-party drivers that either screw-up their memory allocations or their memory pointers, but the only function calls on the call stack (which is a history of the function calls leading up to the bugcheck) are Windows kernel functions and they never screw-up memory allocations or memory pointers. That just leaves bad RAM.

In addition, if you look at the basic call stack you can see apparent calls to function addresses for which we have no symbols (we just see the address)...

0: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffffe582`fce3ee08 fffff803`65c7a3fb     nt!KeBugCheckEx
01 ffffe582`fce3ee10 fffff803`65c1186c     nt!KiDispatchException+0x14108b
02 ffffe582`fce3f4d0 fffff803`65c0d2bd     nt!KiExceptionDispatch+0x12c
03 ffffe582`fce3f6b0 fffff803`65aaa31e     nt!KiPageFault+0x43d
04 ffffe582`fce3f846 f80365e6`53420000     nt!RtlpSanitizeContextFlags+0x4a
05 ffffe582`fce3f84e 00000000`0001ffff     0xf80365e6`53420000
06 ffffe582`fce3f856 d5882381`4b100000     0x1ffff
07 ffffe582`fce3f85e 00000000`3000ffff     0xd5882381`4b100000
08 ffffe582`fce3f866 00000000`00000000     0x3000ffff

Those non-symbol addresses at the bottom of the stack there are clearly invalid. They are all non-canonical (not in the usable address range) and some of them are not even full 64-bit addresses. This is strongly indicative of bad RAM - but you've replaced the RAM with QVL certified RAM, so it';s not the RAM sticks themselves. It's not a rogue third-party driver either, because Driver Verifier didn't BSOD any of them, so all that's left is the board.

Are you sure you're running the latest BIOS update for your board? AMD CPUs also required microcode called AGESA (AMD Generic Encapsulated Software Architecture) which is shipped in BIOS updates. The latest BIOS update for your board is dated 27th October 2023 and it does contain an AGESA update (1.2.0.1B), IMO you want to be on that BIOS version.

I’m currently running the latest Bios for my board. I just recently checked their site and grabbed the BIOS dated for 10/27/2023. It may have been mentioned before, but I am using known good ram from a previous PC build, where I never experienced these blue screen crashes the same goes for the GPU that is currently in my new system. The only thing left in my new system that is not from my old build is the CPU and the motherboard.

Here is a photo of my BIOS: https://www.mediafire.com/view/kz4yl7gjm03jetm/image0.jpeg/file

Any idea on how to proceed?

 

[Crinot51]

Just had another crash today with an error code of: SYSTEM_SERVICE_EXCEPTION. I was playing CS2 when the crash occured.

112323-7093-01

MediaFire is a simple to use free service that lets you put all your photos, documents, music, and video in a single place so you can access them anywhere and share them everywhere.

www.mediafire.com

 

[ubuysa]

Well, again this dump has all the hallmarks of bad RAM. The failure bucket shows a stack pointer error and a 0xC000005 exception code (memory access violation)...

FAILURE_BUCKET_ID:  0x3B_c0000005_STACKPTR_ERROR_nt!KiInsertQueueApc

The failing function is a Window function - there are no third-party drivers on the call stack - and the invalid memory access can be clearly seen (the ????????????????)

2: kd> .frame /r a
0a ffffe40a`9419f958 fffff804`045085a8     nt!KiInsertQueueApc+0x51
rax=03efc1f88a440845 rbx=ffffd10790386080 rcx=ffffd10790386318
rdx=fffff8040459ac28 rsi=ffffa680f9f69101 rdi=0000000000000000
rip=fffff80404508a91 rsp=ffffe40a9419f958 rbp=ffffffffffffffff
 r8=fffff8040459ac28  r9=0000000000000000 r10=0000000000000200
r11=ffffd10790386308 r12=0000000000000001 r13=00000249e12f0080
r14=0000000000000000 r15=ffffa680f9f69180
iopl=0         nv up ei ng nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040282
nt!KiInsertQueueApc+0x51:
fffff804`04508a91 483910          cmp     qword ptr [rax],rdx ds:002b:03efc1f8`8a440845=????????????????

You can see there that the CMP (compare) instruction was comparing memory locations pointed to by the RAX and RDX registers. The address in the RDX register looks to be ok, but the address in the RAX register is non-canonical (ie. not valid as a memory address).

Under normal circumstances I'd suggest that a third-party driver may be responsible for the bad RAX address, but we've already checked all those. The process that was in control at the time was steamerrorreporter64.exe, so perhaps this is a problem with Steam? That might explain why it BSODs on two different games. The failing function is trying to insert an APC (an asynchronous procedure call) and that could be a user-mode issue. Is there an update for Steam available?

 

[Crinot51]

Well, again this dump has all the hallmarks of bad RAM. The failure bucket shows a stack pointer error and a 0xC000005 exception code (memory access violation)...

FAILURE_BUCKET_ID:  0x3B_c0000005_STACKPTR_ERROR_nt!KiInsertQueueApc

The failing function is a Window function - there are no third-party drivers on the call stack - and the invalid memory access can be clearly seen (the ????????????????)

2: kd> .frame /r a
0a ffffe40a`9419f958 fffff804`045085a8     nt!KiInsertQueueApc+0x51
rax=03efc1f88a440845 rbx=ffffd10790386080 rcx=ffffd10790386318
rdx=fffff8040459ac28 rsi=ffffa680f9f69101 rdi=0000000000000000
rip=fffff80404508a91 rsp=ffffe40a9419f958 rbp=ffffffffffffffff
 r8=fffff8040459ac28  r9=0000000000000000 r10=0000000000000200
r11=ffffd10790386308 r12=0000000000000001 r13=00000249e12f0080
r14=0000000000000000 r15=ffffa680f9f69180
iopl=0         nv up ei ng nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040282
nt!KiInsertQueueApc+0x51:
fffff804`04508a91 483910          cmp     qword ptr [rax],rdx ds:002b:03efc1f8`8a440845=????????????????

You can see there that the CMP (compare) instruction was comparing memory locations pointed to by the RAX and RDX registers. The address in the RDX register looks to be ok, but the address in the RAX register is non-canonical (ie. not valid as a memory address).

Under normal circumstances I'd suggest that a third-party driver may be responsible for the bad RAX address, but we've already checked all those. The process that was in control at the time was steamerrorreporter64.exe, so perhaps this is a problem with Steam? That might explain why it BSODs on two different games. The failing function is trying to insert an APC (an asynchronous procedure call) and that could be a user-mode issue. Is there an update for Steam available?

Hey thanks for replying, So I ended up swapping back to my old PC.. got tired of my new one crashing constantly. I currently have the GPU and RAM from the build that was BSODing and have had 0 crashes.

I'm almost certain it has to be the MB from the new build, I tried two different RAM kits (one of which I had used for years with no crashes) and both were repeatedly crashing without fail. So my best guess after all this testing is that the DIMM slots were damaged somehow.

 

[ubuysa]

That would certainly account for the constant 'bad RAM' dumps we were seeing.