This is what I see for device verifier being on for the dumpfiles. Only the newest 3 has driver verifier turned on. The first two does not
Let me know if I need to switch my RAM or switch to a different capacity RAM that could help maybe?
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
.zip dump file: https://drive.google.com/file/d/1r4i-TIIkrmbFzS6mmtHa9buEZwk8-pJA/view?usp=sharing
I have a lot of BSOD recently from IRQL, Resource not owned, DPC Watchdog, and Kernel Security Check Failure. This started happening occassionally about 2 months ago and become more and more frequent. There is no major update like BIOS or driver that I believe caused the problem
From Windbg, it has been narrowed down to be a thread exception problem where a program tries to access or release a thread it has no access to. I ran verifier for 24 hours to get the same types of BSOD at the same frequency.
There is no driver verifier violation from BSOD and in the dump files (using recommended verifier settings) from windbg, so perhaps the driver is not the issue. Often the debugger say the culprit is various programs from sysinternals, my VPN, or a random .exe process. I did a full reinstall using media creation tool that removes all apps and personal files. I thought this was a problem with corrupted windows file that sfc or dism or chkdsk could not repair or detect. I still have the problem of getting BSOD every few hours (sometimes every few minutes) after the reinstall, but windbg gives a more consistent blame: ntkrnlmp.exe
This is followed with nt!ExpReleaseResourceSharedForThreadLite+(Hex number)
I have the newest bios from HP and windows is up to date
BSOD can happen instantly or is followed by severe lag a few seconds before it happens. There is no overheating by the CPU (hover around 70C, can spike to 90C but drop down to 60C quickly). Did windows memory integrity check, both RAM stick pass. Have not done memtest86 and prefer not to unless there is a strong reason of RAM problem
HP hardware diagnostic did not return any error (the one you run without going into windows)
A good pattern I see is that sfc /scannow ocassionally reports and repairs a corrupted file (but not all the time, even after a BSOD)
The following is the CBS folder with the log. Maybe the file that it repairs can help solve the problem: https://drive.google.com/drive/folders/1XEZLPCoyGIBh0-KF-kHr1eH6SJc8vgcR?usp=sharing
My computer is an HP Laptop about 3 years old, AMD Ryzen 5500u, 32 GB RAM (2 x 16GB Crucial 3200MHz) DDR4, no dedicated GPU, 2TB Crucial SSD (new SSD, no bad sectors.. BSOD also happens before I upgraded my SSD)
BIOS: UEFI
BIOS Version/Date: AMI F.30, 4/21/2023
Processor AMD Ryzen 5 5500U with Radeon Graphics, 2100 Mhz, 6 Core(s), 12 Logical Processor(s)
SMBIOS Version 3.3
Windows Version 10.0.19045 Build 19045 (Windows Home)
System Model HP Laptop 14-fq1xxx
Let me know if any of the links are not working of if the dump file is corrupted
Thx
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
I do think there is a problem with your RAM since nothing else is being indicated, do you have any XMP profile set on your RAM in BIOS?
No. I don't have that option in the BIOS (or DOCP). I don't see a way to modify the RAM's timing, any profile, or modify speed in the BIOS. I only have UEFI BIOS, Boot setup, and diagnostic as options before boot. If there ever was, it is not in the current BIOS version
The only thing I can do is to continue to analyse your dump files, which will hopefully indicate the underlying case of the crashes, otherwise, it may be best to get your hardware tested for faults or incompatibilities.
Meanwhile, should I try to do memtest86 again on the CT16G4SFD832A (1.5 years old)?
An hour ago I switched the 1.5 years old RAM to CT16G4SFRA32A.C16FP (16GB, not used in the last few days, bought 3 weeks ago). It seems to be more stable, with no BSODs so far and running WDV. Does that tell us something?