Issue with synthetic watchdog timeout and hypervisor error during BSOD
Issue with synthetic watchdog timeout and hypervisor error during BSOD
I changed the motherboard BIOS immediately after buying it. However, there are issues with the sound card drivers. johnbl mentioned that the problem lies within them. These drivers are for Windows 10. I’m unsure where to find Realtek drivers for Windows 11 for my built-in sound card.
You can attempt the newest driver available in 2024, which is compatible with Windows 10 but may function due to its recent release.
I checked it thoroughly. All parts inside the system unit are spotless. The computer is mine and I maintain it regularly. Just the motherboard is brand new.
Recently, MS has eased the processor requirements, making the official image installation smoother. I set it up using Media Creation Tool.
Tell me about the last dump 011925-27406-01.dmp? This issue arose after removing the Realtek driver and closing Google Chrome.
Things have deteriorated further. I'm unable to access Windows. After starting my computer, I encounter several issues:
1. A black screen with a cursor that moves with the mouse.
2. An infinite bootloader.
3. A bootloader freeze followed by one of two BSODs after a minute.
Thank you for your response!
This is new minidumps. All these errors occurred today when I couldn't even log in. The Realtek sound card driver was already uninstalled yesterday. I'm attaching a screenshot from the BIOS with voltages. The time and date are correct.
basically here is what I see:
service is running a generic host process
it looks like it is doing cleanup on virtual address space allocations
a memory manager internal routine attempts to delete
a virtual address ,
then attempts to delete a range of page table entries
then the hardware virtualization module tries to flush the list of entries.
something tries to read some hive entry (registry)
and fails control is transferred to this location outside of any file:
0xfffff804`197a0000
the system does not like it and calls a non maskable interrupt and it forces the system to shutdown via bugcheck.
(non maskable interrupt is one that can not be turned off)
everything happened very fast (23 seconds)
System Uptime: 0 days 0:00:23.162
here is what I would do next, turn off fast boot in bios, delete the pagefile.sys. this will force the system to create a new one rather than bugchecking while reading one that is corrupted.
if you can get the system to boot, I would tell windows not to make a pagefile.sys on your drive. This will force windows to take some of your memory and create a internal pagefile in RAM
and may allow you to boot. After you can boot up, you will want to check to see if there is a firmware update for your actual drive, see if you can apply a update for your chipset drivers for your disk.
you can use crystaldiskinfo.exe to read the drive info and firmware level and then google to see if it can be updated.
also, installing the old chipset drivers from your motherboard vendor might not have the code leading to the bugcheck. Even getting the amd chipset drivers directly from amd might not have the code that leads to the bugcheck. IE it could just be the Microsoft generic version that bugchecks.
also, most of these old cpus had many security updates that patch a core in the cpu to prevent hacks.
You might also change the memory dump type to kernel or see if you have a file memory.dmp. It is much bigger and has a lot more info in it. Problem, is this is a fast panic memory dump so it may not get created.
will take a quick look at the other bugchecks
second bugcheck: basically
amdppm makes a call to advanced configuration power interface
amdppm!AcpiCStateIdleExecute
it reads something from the hives (registry)
does not like the result and tells calls the hypervisor library and request the system cpu shutdown.
acpi spec is updated over time. the current version is 6.4
it makes calls to your bios but your bios will not have the proper tables since it is so old. you might install the version that matches your motherboard amdppm.sys. at least it will be the version that will match your bios specs.
You might also be able to turn off sleep states in your bios to prevent the calls
this shows the various known bugs in older versions.
https://uefi.org/htmlspecs/ACPI_Spec_6_4...story.html
I am not even sure what spec level was out in 2014/2016
looks like all of the bugchecks start from a call from amdppm.sys
to acpi interface that tells the hypervisor library to shutdown the cpu.
interface specs for acpi tables must have changed so the current generic version of amdppm.sys just will not work with the old bios from 2016. only real hope would be to install the old chipset driver from 2016, or turn off the functions if you can. (C states). I think there might be a registry setting to also turn it off. ( I have used it as a work around for certain bugs in new CPUs releases) will see if i can find it.
found it by google this "how to disable amdppm.sys transitions"
got this for the registry setting:
To disable amdppm.sys transitions, you can follow these steps:
Press Win + R to open the Run window.
Type "regedit" and press Enter to open Registry Editor.
Go to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\amdppm.
Right-click the Start key and change the Value data to 4.
restart computer
it should lock the cpu to one speed. not a good solution and you do not have much time before your system bugchecks
acpi spec:
revision 5.1 was released in July 2014. (your motherboard firmware)
revision is 6.5 release in aug 2022 (version from generic windows 11 file you are using)
most version updates are .1 each release update
Thank you very much for your reply and help!
I checked SSD drives. There are no new firmware on them.
I disabled the swap file and reboot.
And while I was writing this answer, I got BSOD again.
Here is its minidump
. Unfortunately, I did not find memory.dmp in the Windows folder.
I already read about disable amdppm.sys transitions. But I think it's a bad solution.
You wrote that the problem was initially in the Realtek audio driver. But now it has been removed. Could the driver have left something that continues to cause BSOD? Could this problem be related to an old battery on the motherboard?
P.S.
I understand that the processor is quite old. But there are many examples when Win11 works stably on much older models under the AM3 socket.