Why is my computer showing a blue screen with an error code?
Why is my computer showing a blue screen with an error code?
Those three dumps still strongly suggest a RAM problem - or of course, a motherboard RAM slot problem. One dump is a PAGE_FAULT_IN_NONPAGED_AREA bugcheck, which means a page fault (invalid page) was encountered whilst addressing a page in the non-paged pool. In the raw call stack we can see a memory error in private memory (nt!MiResolvePrivateZeroFault+0x1af) and whilst the kernel is recovering from that we get a page fault in the kernel (nt!KiPageFault+0x369) - that's the one that caused the BSOD. The second dump is a MEMORY_MANAGEMENT bugcheck with an exception code indicating an invalid page table entry (PTE). In the call stack we can see that an address space had ended normally and cleanup was in progress for the memory it had used. The BSOD happened when the nt!MiDeleteVa+0x2316e2 function was called. Notice that very large offset into the function (0x2316e2). That's outside the range of the module, which is only 0x104700 bytes long - that's why we got the BSOD. Quite where that offset came from we can't tell but all the functions called are in Windows modules, so it's not a software error. The third dump is a KERNEL_LOCK_ENTRY_LEAKED_ON_THREAD_TERMINATION bugcheck indicating that a thread was terminated before all of its locks had been released. In the raw call stack we can see the process ending normally and memory cleanup starting. The BSOD happens on the nt!KeCleanupThreadState+0x246428 function call. Notice again that large offset (0x246428), that's also beyond the end of the nt!KeCleanupThreadState module, which also has a length of only 0x1047000 bytes. This call stack also contains only functions in Windows modules, so it's not a software error. That Prime95 ran well does suggest that it's not a CPU problem, but that said, Prime95 also stresses RAM on a couple of the tests and I would have expected that to fail. It is just possible that these BSODs could have a bad third-party driver causing them. It might just be that a third-party driver trashed a critical system structure or screwed-up a queue or list and that problem wasn't encountered until some time later when we got a BSOD in a different thread. We wouldn't see the faulty driver in any of the dumps because it was long gone. Because of that, and before you spend any money, it's well worth enabling 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 when they 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).
Thanks for getting back to me! I just bought new RAM sticks from Patriot, called Viper Steel 2x8GB running at PC4-25600 speeds with low CL values of 16-18-18-36 and a voltage of 1.35 volts. The product number is PVS416G320C6K. I looked everywhere for something that fits my computer right now, but couldn't find any match on the compatibility list even though the specs were similar to what I bought. They listed PV416G320C6K under memory support page with matching timings and CL values too. Maybe the motherboard slots are causing the trouble? If it is that problem, finding a replacement board will be hard because of cost and where they sell them. But I keep a full backup copy of my disk every day so if something goes wrong with loops, nothing bad will happen to me. I am going to try Driver Verifier soon and will tell you what happens in the next few days. Thanks for your help and all that great detail!
So, a quick little update about that BSOD in the last three days. On 13th of December -> I installed new memory sticks around noon. Didn't have any problems all day, even no browser crashes. Just a little bit of use. On 14th of December -> Turned on Driver Verifier around 11 o'clock and no issues all day. Normal use and some light gaming (the game wasn't too tough). On 15th of December -> DV was still on, played BG3, normal use and some gaming (a heavy title, BG3). So I'll start connecting the drives in a few days coming up (one drive per day to check for any issues). Hope RAM was the problem, but yeah I will give another update in two or three days and hope to wrap it all up.
I just took out the DV, and it's been running for a few days with no problems. Yes, that actually sounds pretty good at the moment. It went from two or three times a day down to zero in the last four days. My next update will come in three days, so I hope everything stays fine until then.
So far, everything looks fine. I've put all the drives in and it's running without problems. So, let's close this as fixed. To be real honest, I built some PCs before but never had any issues with RAMs, not even on the QVL list. That was a lesson learned if you know what I mean. If you have time, please share your sources so I can learn how to read minidumps a bit more. Thanks.