This error indicates a BSOD related to amdppm.sys.
This error indicates a BSOD related to amdppm.sys.
Hello. I've experienced several BSODs recently following a Windows update (probably).
I've attempted to upgrade to the latest BIOS, reinstall Windows, updated chipset drivers, and run various CMD commands such as chkdsk and sfc /scannow. Also tried disabling HyperV.
I'm unsure what's happening and wonder if the processor might be failing.
Here is the dump file.
It appears to be a hypervisor issue (not fully documented).
The control was directed to an unusual kernel address which triggered the bugcheck.
Consider updating the BIOS to the latest version.
ROG STRIX B650E-F GAMING WIFI | ROG Strix | Gaming Motherboards | ROG - Republic of Gamers | ROG Global
The device is designed for the future with 12 + 2 power stages, DDR5 memory, and PCIe® 5.0 connectivity. It features three M.2 slots with heatsinks, a USB 3.2 Gen 2x2 port, WiFi 6E, AI Networking, Two-Way AI Noise Cancelation, and Aura Sync RGB lighting.
Check the BIOS for voltage readings on the 3.3V, 5V, and 12V lines—they should be within ±5%.
If the hypervisor error persists, install the AMD RyzenMaster driver as it may resolve known CPU issues. The BIOS update should also apply the necessary CPU patches, eliminating the need for the RyzenMaster driver.
Note: The firmware is outdated (2023).
After updating the BIOS, refresh the CPU chipset drivers, remove any ASUS utilities, and disable the ASUS AI Suite if present.
Bios is currently the latest update. Voltages are normal as well. Virtualization remains disabled and it still crashes. XMP is off, Hyper_V is disabled, Ryzenmaster and chipset driver are installed. A 4-hour Memtest5 test was completed without any errors. Here is another dump file.
You may want to revisit this software:
RzDev_022b.sys from Mar 22 18:38:31 2021
and
RzCommon.sys from Sep 25 20:29:57 2023
some razer driver, you could remove it, update the firmware and reinstall.
There was no clear reason pointing to it as the issue, but this driver didn’t pass verification checks, making it questionable.
In both dump files, an unexpected call outside any module triggered the bug. I recommend checking the BIOS settings to ensure the ASUS Armory crate isn’t active. After Windows starts, examine the running services and processes to confirm no ASUS Armory crate service is active.
(The first bug check began from a kernel address, while the second came from a user mode address)
It seems the first was a BIOS call and the second a call from a .exe or service back to the BIOS.)
You might need to supply a kernel memory dump to demonstrate the source of the problem. (Even then, it’s unusual since it isn’t coming from a file or driver)
Additionally, this driver is also installed:
AVoluteSS3Vad.sys from Aug 6 2019
It appears to handle 3D sound effects; I faced many issues on my system until I removed this driver. You may wish to disable or update it.
Here’s the only update I’m aware of:
https://www.catalog.update.microsoft.com...luteSS3Vad
To disable the driver, you can download and run
microsoft autoruns64.exe and simply disable it for testing.
https://learn.microsoft.com/en-us/sysint...s/autoruns
I have now refreshed the Razer drivers. The AvoluteSS3VAD.sys drivers were uninstalled and the armoury crate disabled, and I checked that the service isn't running. Thank you for your patience so far—I'll let you know if it crashes again.
Received yet another BSOD. Attached are the temporary files and the dump.
This issue occurred while Chrome was active, with something beginning to operate from an unusual source. Perhaps disabling Chrome extensions would help. I plan to switch your memory dump format to kernel and supply the memory.dmp file. It will be larger but will display all running processes.
Notes:
- The process appears to be AVoluteSS3Vad.sys, still active.
- Recent updates: RzDev_022b.sys (Aug 3), RzCommon.sys (Sep 25).
- You might enable verifier.exe testing to speed up bugcheck if the fault lies in a driver.
- Open cmd as administrator and run:
verifier.exe /standard /all /bootmode oneboot
Following the instructions at https://learn.microsoft.com/en-us/window...mmand-line can be useful.
- This command will only keep verifier active during the next boot and automatically turn it off afterward. Otherwise, run cmd.exe as admin and execute:
verifier.exe /reset
(or your system may become slow until you issue the command)
- It seems AVoluteSS3Vad.sys fails verification testing; consider disabling this driver via Microsoft Authorizes64 before testing.
- You can also exclude a driver from testing by adding /driver.exclude in the verifier command, for example:
verifier.exe /standard /all /driver.exclude avolutess3vad.sys /bootmode oneboot
This would run standard tests excluding the problematic driver.
Other observations:
- Issues with mouse light controls, AIO coolers, fan lights, and RAM indicators are common.
- Logi_lamparray.sys (Apr 15) often affects mouse light control, AIO coolers, fans, and RAM lights.
- Updating device firmware may resolve the problem.
- Running a stress test such as prime95 could help identify specific CPU issues; Intel offers its own diagnostic tool, and AMD likely has a similar utility.
- In your case, the control points are shifting across different system areas.
Kernel, user mode, and what seems to be a kernel heap area are not linked to any recognized module.
Additional details:
- vwifibus.sys (Wi-Fi bus driver)
- vwififlt.sys (Wi-Fi filter driver)
- vwifimp.sys (network miniport driver)
These appear to be virtual drivers; their behavior depends on BIOS virtualization settings.
Check the last two posts in this thread for more context:
https://learn.microsoft.com/en-us/answer...lue-screen
Hi. Sorry for the late response. Full disclosure this is a PC I built for a friend and he brought it to me yesterday so I could test. Funny thing though is that it has not crashed since even with stress tests running. Y-cruncher stress test, OCCT and furmark.
It must then be some driver of what he is using at home causing issues. We will try testing this.
He's still not getting it back. The system has crashed twice, only during idle mode, which is unusual. Kernel-Power 41 (63) shows all data as zeros. Should I consider using a different power supply?