Question BSOD when PC is idle or not doing much ?

[Poynter]

Since updating from Windows 10 to Windows 11 sometime last year I have been experiencing regular BSOD crashes. The crash message is typically either HYPERVISOR_ERROR or PAGE_FAULT_IN_NON_PAGED_AREA although other error messages do occur. These crashes rarely, if ever, happen when I am doing something serious such as playing a game and they typically occur if I am doing nothing, using EDGE to visit a web site, looking at news feeds or working in file explorer. In fact a HYPERVISOR_ERROR has just occured when I was posting this question and I include the WinDbg output of the dump file below.

I have tried all of the normal things that are recommended (SFC/SCANNOW, DISM, update drivers, memtest86, chkdsk, GPU stress test and even reinstall Windows 11) but none of them have resolved the problem of helped to throw any light on what is going on. I have also checked component operating temperatures using CPUID HWMonitor and nothing seems abnormal (CPU is currently 42 degC and GPU 39 degC). The WinDbg output from the most recent crash is given below - this one is more helpful than most - it highlights amdppm.sys as the module name but it's worth noting that I have tried re-installing AMD drivers before but without solving the problem.

My summary PC spec is AMD Ryzen 3600, Tomahawk B450 Max motherboard, Nvidia GTX 1660 GPU and 16 GByte RAM.

If anyone can suggest what might be causing this I would be most grateful.


************* Preparing the environment for Debugger Extensions Gallery repositories **************
ExtensionRepository : Implicit
UseExperimentalFeatureForNugetShare : true
AllowNugetExeUpdate : true
NonInteractiveNuget : true
AllowNugetMSCredentialProviderInstall : true
AllowParallelInitializationOfLocalRepositories : true

EnableRedirectToV8JsProvider : false

-- Configuring repositories
----> Repository : LocalInstalled, Enabled: true
----> Repository : UserExtensions, Enabled: true

>>>>>>>>>>>>> Preparing the environment for Debugger Extensions Gallery repositories completed, duration 0.000 seconds

************* Waiting for Debugger Extensions Gallery to Initialize **************

>>>>>>>>>>>>> Waiting for Debugger Extensions Gallery to Initialize completed, duration 0.016 seconds
----> Repository : UserExtensions, Enabled: true, Packages count: 0
----> Repository : LocalInstalled, Enabled: true, Packages count: 41

Microsoft (R) Windows Debugger Version 10.0.27553.1004 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\052624-8406-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available


************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 22621 MP (12 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Kernel base = 0xfffff802`0f000000 PsLoadedModuleList = 0xfffff802`0fc13130
Debug session time: Sun May 26 17:57:13.098 2024 (UTC + 1:00)
System Uptime: 0 days 0:46:30.935
Loading Kernel Symbols
...............................................................
................................................................
................................................................
............
Loading User Symbols

Loading unloaded module list
........
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff802`0f417f80 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:ffff8801`b1ccdcb0=0000000000020001
6: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

HYPERVISOR_ERROR (20001)
The hypervisor has encountered a fatal error.
Arguments:
Arg1: 0000000000000011
Arg2: 00000000002f4152
Arg3: 000000000000100f
Arg4: ffffe70000a05cd0

Debugging Details:
------------------


KEY_VALUES_STRING: 1

Key : Analysis.CPU.mSec
Value: 2515

Key : Analysis.Elapsed.mSec
Value: 4565

Key : Analysis.IO.Other.Mb
Value: 0

Key : Analysis.IO.Read.Mb
Value: 0

Key : Analysis.IO.Write.Mb
Value: 0

Key : Analysis.Init.CPU.mSec
Value: 327

Key : Analysis.Init.Elapsed.mSec
Value: 3879

Key : Analysis.Memory.CommitPeak.Mb
Value: 104

Key : Bugcheck.Code.LegacyAPI
Value: 0x20001

Key : Bugcheck.Code.TargetModel
Value: 0x20001

Key : Dump.Attributes.AsUlong
Value: 808

Key : Dump.Attributes.KernelGeneratedTriageDump
Value: 1

Key : Failure.Bucket
Value: 0x20001_11_2f4152_amdppm!HvRequestIdle

Key : Failure.Hash
Value: {8420b585-745b-2d4d-14e5-01d3ca4497c4}

Key : Hypervisor.Enlightenments.ValueHex
Value: 1497cf94

Key : Hypervisor.Flags.AnyHypervisorPresent
Value: 1

Key : Hypervisor.Flags.ApicEnlightened
Value: 1

Key : Hypervisor.Flags.ApicVirtualizationAvailable
Value: 0

Key : Hypervisor.Flags.AsyncMemoryHint
Value: 0

Key : Hypervisor.Flags.CoreSchedulerRequested
Value: 0

Key : Hypervisor.Flags.CpuManager
Value: 1

Key : Hypervisor.Flags.DeprecateAutoEoi
Value: 0

Key : Hypervisor.Flags.DynamicCpuDisabled
Value: 1

Key : Hypervisor.Flags.Epf
Value: 0

Key : Hypervisor.Flags.ExtendedProcessorMasks
Value: 1

Key : Hypervisor.Flags.HardwareMbecAvailable
Value: 1

Key : Hypervisor.Flags.MaxBankNumber
Value: 0

Key : Hypervisor.Flags.MemoryZeroingControl
Value: 0

Key : Hypervisor.Flags.NoExtendedRangeFlush
Value: 0

Key : Hypervisor.Flags.NoNonArchCoreSharing
Value: 1

Key : Hypervisor.Flags.Phase0InitDone
Value: 1

Key : Hypervisor.Flags.PowerSchedulerQos
Value: 0

Key : Hypervisor.Flags.RootScheduler
Value: 0

Key : Hypervisor.Flags.SynicAvailable
Value: 1

Key : Hypervisor.Flags.UseQpcBias
Value: 0

Key : Hypervisor.Flags.Value
Value: 4853999

Key : Hypervisor.Flags.ValueHex
Value: 4a10ef

Key : Hypervisor.Flags.VpAssistPage
Value: 1

Key : Hypervisor.Flags.VsmAvailable
Value: 1

Key : Hypervisor.RootFlags.AccessStats
Value: 1

Key : Hypervisor.RootFlags.CrashdumpEnlightened
Value: 1

Key : Hypervisor.RootFlags.CreateVirtualProcessor
Value: 1

Key : Hypervisor.RootFlags.DisableHyperthreading
Value: 0

Key : Hypervisor.RootFlags.HostTimelineSync
Value: 1

Key : Hypervisor.RootFlags.HypervisorDebuggingEnabled
Value: 0

Key : Hypervisor.RootFlags.IsHyperV
Value: 1

Key : Hypervisor.RootFlags.LivedumpEnlightened
Value: 1

Key : Hypervisor.RootFlags.MapDeviceInterrupt
Value: 1

Key : Hypervisor.RootFlags.MceEnlightened
Value: 1

Key : Hypervisor.RootFlags.Nested
Value: 0

Key : Hypervisor.RootFlags.StartLogicalProcessor
Value: 1

Key : Hypervisor.RootFlags.Value
Value: 1015

Key : Hypervisor.RootFlags.ValueHex
Value: 3f7


BUGCHECK_CODE: 20001

BUGCHECK_P1: 11

BUGCHECK_P2: 2f4152

BUGCHECK_P3: 100f

BUGCHECK_P4: ffffe70000a05cd0

FILE_IN_CAB: 052624-8406-01.dmp

TAG_NOT_DEFINED_202b: *** Unknown TAG in analysis list 202b


DUMP_FILE_ATTRIBUTES: 0x808
Kernel Generated Triage Dump

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: System

STACK_TEXT:
ffff8801`b1ccdca8 fffff802`0f545101 : 00000000`00020001 00000000`00000011 00000000`002f4152 00000000`0000100f : nt!KeBugCheckEx
ffff8801`b1ccdcb0 fffff802`0f46ed58 : 00000000`00000100 fffff802`0f20d14c ffff8801`b1cd6340 ffff8801`b1ccdd30 : nt!HvlSkCrashdumpCallbackRoutine+0x81
ffff8801`b1ccdcf0 fffff802`0f425f82 : 00000000`00000100 ffff8801`b1ccdef0 00000000`00000000 00000000`00000000 : nt!KiProcessNMI+0x261e28
ffff8801`b1ccdd30 fffff802`0f425cee : 00000000`00000100 ffff8801`b1ccdef0 00000000`00000000 00000000`00000000 : nt!KxNmiInterrupt+0x82
ffff8801`b1ccde70 fffff802`0ab20003 : fffff802`0f3cb587 fffff802`0f3c6920 fffff802`0f2df5d8 00000000`00000000 : nt!KiNmiInterrupt+0x26e
ffffcc8d`c4aa74c8 fffff802`0f3cb587 : fffff802`0f3c6920 fffff802`0f2df5d8 00000000`00000000 fffff802`0f2e3a7d : 0xfffff802`0ab20003
ffffcc8d`c4aa74d0 fffff802`0f544355 : 00000000`00000001 fffff802`0f3c693b 00000006`88db5b3b 00000000`00000000 : nt!HvcallInitiateHypercall+0x57
ffffcc8d`c4aa7550 fffff802`38239d5d : 00000000`000100de fffff802`0f2df5d8 ffffbc84`f5ce5168 fffff802`0f2da237 : nt!HvlRequestProcessorHalt+0x35
ffffcc8d`c4aa7580 fffff802`382318d3 : 00000000`00000000 00000000`00000001 ffffbc84`f5ce5168 00000000`00000000 : amdppm!HvRequestIdle+0x2d
ffffcc8d`c4aa75d0 fffff802`0f2e1456 : 00000000`00000000 ffff8801`b1c91180 00000000`00000000 ffff8801`b1c91180 : amdppm!AcpiCStateIdleExecute+0x23
ffffcc8d`c4aa7600 fffff802`0f2e0fcb : ffffbc84`f5ce5718 00000000`00000000 00000000`ffffffff ffffcc8d`c4aa7ab0 : nt!PpmIdleExecuteTransition+0x426
ffffcc8d`c4aa7a50 fffff802`0f41cf44 : 00000000`00000000 ffffbc84`ee35a040 ffffbc84`f9150080 ffffbc85`0050b080 : nt!PoIdle+0x68b
ffffcc8d`c4aa7c40 00000000`00000000 : ffffcc8d`c4aa8000 ffffcc8d`c4aa2000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x54


SYMBOL_NAME: amdppm!HvRequestIdle+2d

MODULE_NAME: amdppm

IMAGE_NAME: amdppm.sys

IMAGE_VERSION: 10.0.22621.3593

STACK_COMMAND: .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET: 2d

FAILURE_BUCKET_ID: 0x20001_11_2f4152_amdppm!HvRequestIdle

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {8420b585-745b-2d4d-14e5-01d3ca4497c4}

Followup: MachineOwner
---------

 

[Poynter]

Thanks for the suggestion. I will try that. I have previously tried disabling virtualization by switching SVM off in the BIOS (this got rid of HYPERVISOR crashes but not the others such as PAGE_FAULT). However, I havn't tried leaving SVM on in the BIOS and disabling it via PowerShell. I will post a reply once I have tried it out for a while.

 

[Poynter]

I am running Windows 11 home and I found the command

Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor

only works on Windows 11 Pro. However, the following script works in Windows 11 home under a normal admin command prompt:

@Echo off
:: Disable Hyper-V
bcdedit /set hypervisorlaunchtype off

:: Restart your PC to apply the change
shutdown /r /t 0

 

[Colif]

amdppm.sys

thats actually part of windows. It might appear to be from AMD but its part of windows power management.

Can you follow option one on the following link - here - and then do this step below: Small memory dumps - Have Windows Create a Small Memory Dump (Minidump) on BSOD - that creates a file in c windows/minidump after the next BSOD

1. Open Windows File Explore
2. Navigate to C:\Windows\Minidump
3. Copy the mini-dump files out onto your Desktop
4. Do not use Winzip, use the built in facility in Windows
5. Select those files on your Desktop, right click them and choose 'Send to' - Compressed (zipped) folder
6. Upload the zip file to the Cloud (OneDrive, DropBox . . . etc.)
7. Then post a link here to the zip file, so we can take a look for you . . .

page fault could be a driver error.

 

[ubuysa]

The Windows Hypervisor runs independently of Hyper-V (though it uses the same technology of course). I really would like to see the dump file rather than just the analyze -v output (which is just a small aspect of dump analysis). However, there is a big clue in the output you have posted...

FAILURE_BUCKET_ID:  0x20001_11_2f4152_amdppm!HvRequestIdle

The failure occurred in the amdppm.sys driver, this is the Processor Power Manager driver for AMD CPUs (Intel CPUs use the similar intelppm.sys driver). We thus know that the BSOD happened during processor power management. In addition, the failing function (HvRequestIdle) is the Hypervisor requesting that a processor be set to the ide state. From a power management perspective this also lowers the power level of the processor in order to save power and reduce heat. This is done by changing the C-State of the processor from C0, the full-power running state, to either C3 or C4, the lower power idle (sleep) states.

I've seen many times before that some CPUs don't handle low power C-States well - from my experience AMD CPUs seem to suffer more from this than Intel CPUs - though I've seen it on both. It may be that Windows 11 tries to use a deeper C-State than Windows 10 (there are 10 C-State levels, but not all CPUs support all of them) and that's why you're seeing this now.

The way to test whether this is the issue or not is to enter the UEFI BIOS setup, locate the CPU Management section and disable all C-States for all cores. This will stop all processors changing C-State from C0, even when idle.

If your UEFI BIOS doesn't support disabling C-States then an alternative, but less reliable, technique is to modify the Windows power profile you're using (probably Balanced) and change the processor power management values in there so that BOTH the maximum and minimum processor state are 99%. That also stops the processors entering a lower power state.

See whether that stops these BSODs.

 

[Poynter]

Thanks for your reply; sorry for the delay in coming back to you. I am going to try to re-set the BIOS as suggested above. As you said, I assumed that amdppm.sys was an AMD driver without actually checking it out! Unfortunately, the original dump file got deleted by mistake - I think by CCleaner. However, I have had another Hypervisor BSOD last night and I have shared the DropBox link below. I hope that it can be opened!

https://www.dropbox.com/scl/fi/cdkd...9-01.zip?rlkey=x65tge53i366o8o5tjqrtdkpb&dl=0

 

[Colif]

ccleaner has a terrible habit of destroying evidence.


File: 053124-8859-01.dmp (Jun 1 2024 - 03:54:16)
BugCheck: [HYPERVISOR_ERROR (20001)]
Probably caused by: ntkrnlmp.exe (Process: System)
Uptime: 0 Day(s), 0 Hour(s), 39 Min(s), and 46 Sec(s)

report

BIOS info missing which hints at an outdated BIOS, I would update it.
https://www.msi.com/Motherboard/B450-TOMAHAWK-MAX/support

updating chipset drivers may help as well - https://www.amd.com/en/support/downloads/drivers.html/chipsets/am4/b450.html

Ubuysa probably be more specific

 

[Poynter]

Thanks - I have downloaded the AMD updated drivers and installed them and I have also installed the AMD Power Plan. I will leave it for a few days to see if this makes the PC more stable. If not, I will look again at disabling C-states but, on a first look, I could not see an option to do this in the MSI Tomahawk B450 Max bios.

 

[Poynter]

After downloading the AMD drivers and power plan, the system continued to freeze, occasionally leading to a BSOD crash, often presenting a HYPERVISOR_ERROR. I checked the BIOS for C_states and discovered they were already disabled. Out of curiosity, I enabled them, hoping the AMD drivers and power plan would cooperate with the C_states, but this rendered the system completely unstable, causing four BSOD crashes in 15 minutes. Consequently, I have uninstalled all AMD driver updates, including the power plan, and have disabled both SVM (to prevent HYPERVISOR_ERRORS) and C_states in the BIOS.

It might have been wiser to take these steps one at a time to identify the cause of the problem, but my priority was to achieve a somewhat stable system. Considering that Power Plans could be linked to the crashes, I've activated the Ultimate Performance using the PowerShell command 'powercfg -duplicatescheme e9a42b02-d5df-448d-aa00-03f14749eb61', which prevents the PC from sleeping. So far, this has resulted in a more stable machine without any BSOD crashes. Nonetheless, I will need to test it further to determine if the issue has been fully resolved.

PS - I asked co-pilot about the problem and it said that it might be something to do with Windows 11 which was a relatively new operating system! I suspect the Microsoft would say that this is the opinion of CoPilot and not the corporation.

 

[ubuysa]

Two things come to mind...

1. It's well worth checking the CPU BIOS entries to make sure that everything is standard. Unless you have good reason most items should be set to Auto. Question any setting that you can't explain.
2. Try starting Windows in Safe Mode and see whether it will BSOD in that state.

 

[Poynter]

Thanks for your help. I went into the MSI BIOS and searched under CPU and all states are set to Auto. However, disabling SVM and C-States in the BIOS and removing the AMD power plan and replacing it with the Windows Ultimate Performance seems to have made things much better.

 

[Colif]

don't need the amd power plans any more, windows balanced is good enough for most people.

 

[Poynter]

Good to know that AMD power plans are not needed any more. I will leave my PC on Windows Ultimate Performance until I am sure that is stable with no BSOD crashes (or at least not very many). After that I will try going back to balanced to see if that is ok.

 

[ubuysa]

Good to know that AMD power plans are not needed any more. I will leave my PC on Windows Ultimate Performance until I am sure that is stable with no BSOD crashes (or at least not very many). After that I will try going back to balanced to see if that is ok.

Note that Ultimate Performance also stops processors entering the low power states when idle.

I'd really like to know whether you see these issues in Safe Mode. Safe Mode loads a stripped-down version of Windows, with only critical services and drivers loaded. Typically no third-party drivers or services are loaded. If it fails in Safe Mode then you can be pretty certain that the cause is hardware.

 

[Poynter]

I can try this. I have now discovered that the changes that I have made have much reduced but not eliminated the BSOD crashes - although HYPERVISOR_ERRORS have gone. I will try safe mode but I will probably need to leave it on for several hours, and perhaps try it for a few days to find out if the problems still occur.

I have done my best to find out if it is a hardware problem. MEMTEST86 does not flag anything up and nor does CHKDSK. GPU benchmarks seem ok and I can’t see any sign of overheating on the app that I am using. Power supplies are more difficult to rule out but the calculators that I have used say that it is ok.

I will try safe mode and post the result once I find out if crashes are still occurring. Thanks again.

 

[Colif]

Ultimate Performance's price is increased heat and maybe fan noise. If you don't care that CPU always running full speed, that is fine... I like mine running cool when its not doing anything for me.

have much reduced but not eliminated the BSOD crashes

share any new dumps you get as they might show us more.

 

[Poynter]

So ....

I tried running Windows 11 on safe mode to find out if it froze or BSOD but after 6 hours it didn't crash. Of course, one can't do much in safe mode (or at least I can't) so that doesn't totally rule out a hardware problem but I suppose that it points to software. The last BSOD I got just before I tried the safe mode test was IRQL_NOT_LESS_OR_EQUAL and I have posted a link to the zipped minidump file below. I also have a Kernel dump of the same thing but at 254 MByte zipped it is may be too large to post.

I do intend to go back to a Balanced power plan when I can but I first want to understand what is causing the crashes.

 

[Poynter]

Sorry - I forgot to post the link to the dump file:

https://www.dropbox.com/scl/fi/90lb...8-01.zip?rlkey=qa8huar8ln9wnp874ty9s2kys&dl=0

 

[Colif]

254 MByte zipped it is may be too large to post.

it might help ubuysa more than minidump. I seen bigger files uploaded. Draw line at a few gb though.
I need to make a new VM to convert them in as I only have 30gb of space and its easy to fill up with windows alone, so large dump files are a problem right now... give next one 100gb, remove problem.