What does this error mean?
What does this error mean?
Hello, over the recent months I've experienced numerous BSOD issues. I've checked every forum and tried all possible solutions without success. That's why I'm here to hopefully resolve these problems permanently.
Hardware:
Motherboard: Asus Prime B450M-A
CPU: AMD Ryzen 5-3600
RAM: CORSAIR - Vengeance RGB Pro (32GB, 16GBx2) DDR4 3200MHz
SSD1: Kingston SA400 240GB
HDD2: SeagaTe 1000GB
GPU: Nvidia RTX 2060 6GB
OS: Windows 11
My dumpfiles: https://www.mediafire.com/file/rn8r8jfgq...h.rar/file
I'm hoping someone can assist me, I suspect a hardware issue but I need confirmation.
Welcome to the forums! Please note the PSU model and age as well; some Ryzen boards can be sensitive with RAM, especially certain Corsair models. We aim to identify the cause of the issue. I’m afraid these are not actual dump files.
Code details:
On Thu 14/03/2024 05:55:59 your computer experienced a crash or a problem was logged
crash dump file: C:\Windows\Minidumps\031424-7250-01.dmp
This likely resulted from the following module: ntoskrnl.exe (nt+0x4177F0)
Bugcheck code: 0xA (0xFFFFF80100005920, 0x2, 0x1, 0xFFFFF8015CE333EA)
Error: IRQL_NOT_LESS_OR_EQUAL
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This suggests that either Microsoft Windows or a kernel-mode driver interacted with paged memory at DISPATCH_LEVEL or similar, possibly pointing to another unidentified driver.
These are concise summaries of the dumps. Please upload the .dmp files with the mentioned suffix in the specified folder, and we can review them together.
Here is the information you provided:
Your full setup details are as follows:
- Image link: https://imgur.com/a/mXnbZBg
- View link: https://imgur.com/a/mXnbZBg
- Minidumps file: https://www.mediafire.com/file/v2n2z79ek...s.rar/file
The question clarifies your intent and asks about specific technical details regarding your system setup.
I didn't start my PC because the RAM wasn't working. I bought Corsair's RAM instead.
No mixing, I'm using the default DOCP. Should I turn it off?
I updated everything, but the AMD bus still won't update—I don't know why.
No, I never tried that. Should I do it?
Yes, I already ran a sfc /scannow a long time ago and can try again.
Yes, I'm using Windows Defender.
I bought this PC in July 2020; everything else is the same age except the RAMs, which I didn't realize. I thought it was the best choice for my budget.
I need to mention that I had to disable Hyper-V in the BIOS, but it keeps crashing with HYPERVISOR_ERROR since Windows 11 (about 6-7 months).
I understand that the two RAM modules were included in a kit or package, correct? Avoid mixing them. Yes, you can verify whether disabling the DOCP feature prevents the BSODs. Are you referring to the chipset driver? It seems like you're wondering why an update isn't applying. Did you download the most recent driver from the Asus website, and when attempting setup or update, you encountered an error?
If you mean resetting the BIOS to its default settings, don't worry—reverting won't harm. However, any adjustments such as the DOCP profile you enabled will be lost unless you reapply them later.
You should reset the CMOS, then insert one of the RAM sticks according to the motherboard manual for single RAM operation (specifically in slot A2, which is the second from the CPU), boot the system, and enter BIOS settings. Check if it's recognized, save the changes, turn off the second RAM stick in its correct position (slot B2, the fourth from the CPU), and restart.
This approach shouldn't cause any problems. You might also consider running DISM to repair the Windows image if needed. You can find instructions here.
-Yes it was a pack.
-I turned on DOCP thinking it would fix the BSOD, but I guess nothing will change, I'll still do it.
-This model : "amd_chipset_software_6.01.25.342". It says update worked but the AMD Bus still shows up.
-Okay when I'm back home I'll check everything you suggested and let you know if the BSOD persists.
-I'll also try DISM.
-Ok, but honestly I was planning to buy a new PC next year, I won't repeat the same mistake, thanks.
-Same thing, I've had about 4-5 BSODs a day for the past few months. Before it was just one per day.
-I've already tried something similar – the Driver verifier – which said it was "logi_surrond.sys" or something like that, but after removing everything it didn't help. I'll look into the Event Viewer as you recommended.
I think I'll start with a hardware check, then move to DISM, etc...
Thanks again for your help, you don't realize how exhausted I am from all these BSOD attempts.
Hyper-V and the Windows hypervisor represent distinct technologies. Internally, Windows employs virtual machines managed by the Windows hypervisor, which stands apart from Hyper-V itself—this latter tool enables users to deploy virtual machines. The 0x20001 BSOD indicated an issue with the Windows hypervisor, not with Hyper-V. These error logs are quite diverse, and my interpretation leans toward hardware rather than driver-related causes. I completely agree with @Satan-IR that a weak power supply unit could be the underlying factor. I also share their concerns about RAM, though I remain uncertain about the adequacy of the cooler.
If you have previously activated Driver Verifier, it might be beneficial to re-enable it with the appropriate settings. To activate it correctly, follow these steps:
1. Create a System Restore point or capture a disk image of your system drive using software like Acronis or Macrium Reflect. This process may trigger a BSOD during boot because some drivers are loaded at startup. If this occurs, you risk getting stuck in a boot-BSOD cycle.
- If caught in the boot-BSOD loop, use the Windows installation media to perform a system restore and revert to the saved point. This will clear Driver Verifier and allow normal booting again. Alternatively, restore from the image you created.
Please do not skip this procedure—it is essential for resolving the BSOD issue.
2. Launch the Driver Verifier setup by typing 'verifier' in the Run command box or a command prompt.
3. On the initial screen, select the option labeled 'Create custom settings (for code developers)' and proceed to the next step.
4. In the subsequent dialog, enable 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
Click the Next button after confirming.
5. In the following dialog, choose 'Select driver names from a list' (the final option) and click Next.
6. On this next screen, select the 'Provider' heading to organize drivers in that column, which helps isolate Microsoft drivers.
7. Verify all drivers that do not list Microsoft as the provider—this includes third-party ones.
8. Then, within the same dialog, confirm the following Microsoft drivers (only these):
- Wdf01000.sys
- ndis.sys
- fltMgr.sys
- Storport.sys
These are key Microsoft components that manage lower-level third-party drivers.
9. Click Finish and restart your PC. Driver Verifier will be activated.
Keep in mind that Driver Verifier remains enabled after reboots and shutdowns, and it can only be manually disabled. We anticipate BSODs to help identify unstable drivers. Ensure you capture all minidumps while Driver Verifier is active, and disable any disk cleanup tools during this period.
10. Allow Driver Verifier to run for 48 hours. Use your PC normally during this time, but aim to trigger a BSOD. Test games and applications you typically use, especially those known to cause BSODs. If Windows does not automatically restart after each BSOD, simply reboot and continue testing.
Note: Enabling Driver Verifier incurs performance costs, as it performs additional checks each time a third-party driver is loaded. This trade-off is necessary to detect unstable drivers. Remember, Driver Verifier only tests drivers that are currently loaded—ensure all third-party drivers are activated via apps, features, and devices.
11. To disable Driver Verifier, run the command 'verifier /reset' in the Run command box or a command prompt and restart your PC.
To verify if Driver Verifier is active, open a command prompt and type 'verifier /query'. If drivers appear, it is enabled; if not, it is not running.
12. When Driver Verifier is turned off, go to the folder C:\Windows\Minidump and locate all .dmp files from when Driver Verifier was active (check timestamps). You can compress these files or upload them to the cloud with a public link.
Driver Verifier will then highlight any unstable third-party drivers you installed. If you haven’t experienced BSODs (codes 0xC1, 0xC4, 0xC6, 0xC9, 0xD6, 0xE6) after 48 hours, it is unlikely the issue stems from a driver problem.
We hadn't realized you had used Driver Verifier before, and it highlighted a driver—possibly related to a Logitech headset—as problematic.
I also examined the dumps; the 5 files revealed four distinct error types, which I believe could indicate a hardware fault.
Ubuysa is correct about this. One of the dumps mentioned a Windows Hyper-V issue.
A range of different BSODs strongly suggests a hardware problem. I recommend you carefully follow the steps @ubuysa shared so we can confirm if a problematic driver is at play. I also want to stress the importance of checking the Windows/System image or creating a restore point, as skipping these could lead to a BSOD loop.