Question Windows 10 | System Crash with Error Code 03B and 13A (System Service Exception)

Nov 6, 2024
3
1
15
Hello everyone! Lately, i've been experiencing some random freeze-out moments out nowhere which leads to my pc to automatically reboot; both on low and high load times; giving me a couple of 03B and 13A error logs (only happen once for now) at my events reliability monitor / events viewer.

SPECS:
MOBO: ROG X670E-A
CPU: Ryzen 9 7950x
GPU: Gigabyte RTX 4080 Aero
Ram: Kingston Fury Renegade RGB - 64gb (2x32 GB @ 6,000 MTs)
Storage: 3 x M.2 NVMe
PSU: Corsair SF850L

Attached is a link to my minidumps: https://www.mediafire.com/file/fmuls8m5ryaatgw/Mini_Dumps.zip/file

Any help would be greatly appreciated.

Thanks!
 

Lutfij

Titan
Moderator
Welcome to the forums, newcomer!

MOBO: ROG X670E-A
Is this your motherboard;
? If so, what BIOS version are you on for your motherboard?

Storage: 3 x M.2 NVMe
Out of curiosity, did you install your OS while all 3 drives were in your system?

Might want to also run memtest86 on your system, while AMD's E.X.P.O is enabled.
 
Nov 6, 2024
3
1
15
Thanks for the welcome! :)

MOBO and BIOS: That's the one. I'm currently on Bios v2124 (Came from version v2007). The system feel snappy while using the said version, so I haven't thought of upgrading to one of the recent version yet.

Storage: I installed the O.S while the three of them are present in my system.

Memory Test: Haven't tried to run memtes86 since I started experiencing these random errors and reboots, I'll definitely go do that. Should I go for atleast 8 passes for this one? I only tried doing 4 passes several months which gave me a passing result.
 

ubuysa

Distinguished
Running Memtest86 is a wise move, the dumps do suggest that bad RAM could be a potential cause and that has to be eliminated first.

However, the two 0x13A dumps both failed because of a corruption in a memory heap, most likely a buffer overflow. Memory heaps are the units in which apps allocate memory, so these two are possibly a flaky driver which we don't see in the dump.

A suspect driver that we see in the 0x3B dump is easyanticheat.sys, it appears as an uloaded driver. That means the driver was unloaded prior to the BSOD. The EasyAntiCheat tool is a known cause of BSODs and is always suspect whenever we see it. It's not impossible that it's the cause of the 0x13A BSODs also, even though we don't see it in those dumps.

If the Memtest86 RAM test finds no errors then I think the best next step is to enable Driver Verifier to see whather that can catch a misbehavinbg driver...

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. The Driver Verifier generated BSODs are these...
  • 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
  • 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
  • 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
  • 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
  • 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
  • 0xE6: DRIVER_VERIFIER_DMA_VIOLATION
If you see any of these BSOD types then you can disable Driver Verifier early because you'll have caught a misbehaving driver.

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 Verifier 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).
 
  • Like
Reactions: gelo_mp
Nov 6, 2024
3
1
15
Running Memtest86 is a wise move, the dumps do suggest that bad RAM could be a potential cause and that has to be eliminated first.

However, the two 0x13A dumps both failed because of a corruption in a memory heap, most likely a buffer overflow. Memory heaps are the units in which apps allocate memory, so these two are possibly a flaky driver which we don't see in the dump.

A suspect driver that we see in the 0x3B dump is easyanticheat.sys, it appears as an uloaded driver. That means the driver was unloaded prior to the BSOD. The EasyAntiCheat tool is a known cause of BSODs and is always suspect whenever we see it. It's not impossible that it's the cause of the 0x13A BSODs also, even though we don't see it in those dumps.

If the Memtest86 RAM test finds no errors then I think the best next step is to enable Driver Verifier to see whather that can catch a misbehavinbg driver...

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. The Driver Verifier generated BSODs are these...
  • 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
  • 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
  • 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
  • 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
  • 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
  • 0xE6: DRIVER_VERIFIER_DMA_VIOLATION
If you see any of these BSOD types then you can disable Driver Verifier early because you'll have caught a misbehaving driver.

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 Verifier 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).
Thank you for taking the time to help me with this one. As Lutfij and you suggested, I tried to run a couple of memtest86 test; trying out each dram slot with each single stick (4 passes) and dual channel config (8 passes), and got passing result in all of them.

As suggested, I'm gonna run atleast a 48hr driver verifier monitoring this weekend, and keep you guys updated about the results.
 
  • Like
Reactions: ubuysa