Question Windows 11 keeps getting HYPERVISOR_ERROR BSODs after using Virtual Machines ?

[ConorDuey2000]

Hello. I've been dealing with troubles involving virtual machines on my computer for about a year, now. Every time I ran VMWare or WSL, a while after that, even after I close the virtual machine, I get a HYPERVISOR_ERROR BSOD. I don't know the cause of it, but after I stopped using VMWare and WSL for quite some time and resorted to using QEMU and PCem, instead, the BSODs stopped happening. However, I recently decided to start using VMWare and WSL because I thought that having so many Windows updates as time passed by fixed whatever problem I have.

However, I ran VMWare and WSL regularly for a few days, and today, while I was using my computer after I closed VMWare and WSL, I got a HYPERVISOR_ERROR BSOD that was caused by Windows Terminal. I really need a fix for this because I don't wanna buy a new computer to replace my current one just to use VMWare and WSL again. Anyway, here is the minidump and here is the kernel dump.

By the way, I also updated my computer's BIOS, today, just in case that'll solve my problem and I haven't updated it in a while. I have an ASUS TUF GAMING X570-PLUS (WI-FI) motherboard, an AMD CPU, and an Nvidia GeForce RTX 2060 GPU.

 

[ubuysa]

It will be interesting to see whether the BIOS update fixes the problem. On AMD CPUs additional microcode called the AGESA (AMD Generic Encapsulated Software Architecture) is required, and it's essential that the AGESA microcode is kept updated. AGESA microcode ships with BIOS updates, so it's entirely possible that your recent BIOS updates also updated the AGESA microcode - and that may have fixed the problem.

In the kernel dump I have looked through the activities of each of your 16 processors and I see nothing that leaps out. A few processors are accessing storage drives, one thread is specifically accessing an NVMe drive. I have seen badly seated M.2 drives causing all sorts of niggly issues, so I would suggest you remove and re-seat the NVMe drive(s) you have.

I don't see any drivers loaded for third-party anti-malware products, but if you do have one installed I would suggest disabling or uninstalling that. They cause all sorts of problems.

There is a lot of wireless network activity on several processors. The wireless adapter driver (Netwtw08.sys) is called often on multiple processors. The version of this driver that you have is recent but it's worth checking for an updated driver...

6: kd> lmDvm Netwtw08
Browse full module list
start             end                 module name
fffff805`55c00000 fffff805`564f0000   Netwtw08   (no symbols)       
    Loaded symbol image file: Netwtw08.sys
    Image path: \SystemRoot\System32\drivers\Netwtw08.sys
    Image name: Netwtw08.sys
    Browse all global symbols  functions  data
    Timestamp:        Sun Aug  6 17:14:18 2023 (64CFAABA)
    CheckSum:         00881128
    ImageSize:        008F0000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

The only thing of any real note that I can see is that your VMWare drivers are old, dating from 2021. The vmnetadapter.sys VMWare driver is typical...

6: kd> lmDvmvm netadapter
Browse full module list
start             end                 module name
fffff805`56c90000 fffff805`56c9b000   vmnetadapter   (deferred)         
    Image path: \SystemRoot\system32\DRIVERS\vmnetadapter.sys
    Image name: vmnetadapter.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Mar 11 03:23:31 2021 (60497113)
    CheckSum:         000110C5
    ImageSize:        0000B000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

It would be worth looking for an updated version of VMWare if you haven't already.

TBH I think the BIOS (and potential AGESA) update may well be the answer to your problems. I don't know what date your original BIOS was, but according to your motherboard BIOS update page, there have been three BIOS updates during 2023 so far, and two of those contained AGESA updates. See how it goes for a while.

 

[ConorDuey2000]

It will be interesting to see whether the BIOS update fixes the problem. On AMD CPUs additional microcode called the AGESA (AMD Generic Encapsulated Software Architecture) is required, and it's essential that the AGESA microcode is kept updated. AGESA microcode ships with BIOS updates, so it's entirely possible that your recent BIOS updates also updated the AGESA microcode - and that may have fixed the problem.

In the kernel dump I have looked through the activities of each of your 16 processors and I see nothing that leaps out. A few processors are accessing storage drives, one thread is specifically accessing an NVMe drive. I have seen badly seated M.2 drives causing all sorts of niggly issues, so I would suggest you remove and re-seat the NVMe drive(s) you have.

I don't see any drivers loaded for third-party anti-malware products, but if you do have one installed I would suggest disabling or uninstalling that. They cause all sorts of problems.

There is a lot of wireless network activity on several processors. The wireless adapter driver (Netwtw08.sys) is called often on multiple processors. The version of this driver that you have is recent but it's worth checking for an updated driver...

6: kd> lmDvm Netwtw08
Browse full module list
start             end                 module name
fffff805`55c00000 fffff805`564f0000   Netwtw08   (no symbols)      
    Loaded symbol image file: Netwtw08.sys
    Image path: \SystemRoot\System32\drivers\Netwtw08.sys
    Image name: Netwtw08.sys
    Browse all global symbols  functions  data
    Timestamp:        Sun Aug  6 17:14:18 2023 (64CFAABA)
    CheckSum:         00881128
    ImageSize:        008F0000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

The only thing of any real note that I can see is that your VMWare drivers are old, dating from 2021. The vmnetadapter.sys VMWare driver is typical...

6: kd> lmDvmvm netadapter
Browse full module list
start             end                 module name
fffff805`56c90000 fffff805`56c9b000   vmnetadapter   (deferred)        
    Image path: \SystemRoot\system32\DRIVERS\vmnetadapter.sys
    Image name: vmnetadapter.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Mar 11 03:23:31 2021 (60497113)
    CheckSum:         000110C5
    ImageSize:        0000B000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

It would be worth looking for an updated version of VMWare if you haven't already.

TBH I think the BIOS (and potential AGESA) update may well be the answer to your problems. I don't know what date your original BIOS was, but according to your motherboard BIOS update page, there have been three BIOS updates during 2023 so far, and two of those contained AGESA updates. See how it goes for a while.

Yeah. I was thinking that the update might have a chance of solving my problem. I also updated my copy of VMWare to see if that fixes anything.

 

[ConorDuey2000]

Alright. I have an update. I recently got a bluescreen on my computer and I'm not sure if it was because of the virtual machines or not. It was an IRQL_NOT_LESS_OR_EQUAL bluescreen and I don't know the cause of it because when I debugged it in WinDBG, it told me that the process name was "System". I was thinking that maybe some of you can find out what caused that bluescreen. Here is the minidump and here is the kernel dump.

 

[hedwar2011]

I threw the minidump into BlueScreenView:

It makes reference to ntoskrnl.exe.

 

[ConorDuey2000]

I threw the minidump into BlueScreenView:

It makes reference to ntoskrnl.exe.

I know. I still don't know exactly what caused it because most if not all of my bluescreens make references to ntoskrnl.exe.

 

[Colif]

You have had the same error forever, haven't you?

You reported it 3 times now. It makes me think its hardware

bluescreenview always blames ntoskrnl as it is what crashed.
NTOSKRNL = windows kernel. It handles all driver requests, power management, and memory management. It sits between Hardware and Applications. It got blamed but its not the cause

its involved in almost everything windows does.

I won't look at dumps as Ubuysa is your best chance of figuring it out.

 

[ConorDuey2000]

You have had the same error forever, haven't you?

You reported it 3 times now. It makes me think its hardware

bluescreenview always blames ntoskrnl as it is what crashed.
NTOSKRNL = windows kernel. It handles all driver requests, power management, and memory management. It sits between Hardware and Applications. It got blamed but its not the cause

its involved in almost everything windows does.

I won't look at dumps as Ubuysa is your best chance of figuring it out.

I guess I'm either gonna have these problems until I get a new computer in the future or a BIOS update will fix my bluescreen problem. Hopefully, the bluescreen that I just had didn't have to do anything with virtual machines because those bluescreens are typically HYPERVISOR_ERROR bluescreens.

 

[Colif]

Did you update these since you have latest BIOS now? https://www.amd.com/en/support/chipsets/amd-socket-am4/x570 (driver listing from crash suggests no)

irq errors are a pain, I used to think they were the easiest BSOD but now I am not so sure.

Did I ever get you to run memtest?
Try running memtest86 on each of your ram sticks, one stick at a time, up to 4 passes. Only error count you want is 0, any higher could be cause of the BSOD. Remove/replace ram sticks with errors. Memtest is created as a bootable USB so that you don’t need windows to run it

its easy to find your last 3 threads, they show as similar threads under this one.


File: 101323-16421-01.dmp (Oct 14 2023 - 02:50:08)
BugCheck: [IRQL_NOT_LESS_OR_EQUAL (A)]
Probably caused by: memory_corruption (Process: System)
Uptime: 2 Day(s), 18 Hour(s), 13 Min(s), and 46 Sec(s)

report - mostly for me (click run as fiddle to read)

dump isn't showing any system info, bios isn't telling windows what its using. It should know if you updated bios. Chipset drivers might help there

What are full specs?

What AMD CPU?
ASUS TUF GAMING X570-PLUS (WI-FI)
How much ram?
What storage drives?
What PSU?

 

[ConorDuey2000]

Did you update these since you have latest BIOS now? https://www.amd.com/en/support/chipsets/amd-socket-am4/x570 (driver listing from crash suggests no)

irq errors are a pain, I used to think they were the easiest BSOD but now I am not so sure.

Did I ever get you to run memtest?
Try running memtest86 on each of your ram sticks, one stick at a time, up to 4 passes. Only error count you want is 0, any higher could be cause of the BSOD. Remove/replace ram sticks with errors. Memtest is created as a bootable USB so that you don’t need windows to run it

its easy to find your last 3 threads, they show as similar threads under this one.


File: 101323-16421-01.dmp (Oct 14 2023 - 02:50:08)
BugCheck: [IRQL_NOT_LESS_OR_EQUAL (A)]
Probably caused by: memory_corruption (Process: System)
Uptime: 2 Day(s), 18 Hour(s), 13 Min(s), and 46 Sec(s)

report - mostly for me (click run as fiddle to read)

dump isn't showing any system info, bios isn't telling windows what its using. It should know if you updated bios. Chipset drivers might help there

What are full specs?

What AMD CPU?
ASUS TUF GAMING X570-PLUS (WI-FI)
How much ram?
What storage drives?
What PSU?

I've updated my AMD chipset drivers. I haven't ran memtest86, yet, because I don't have the time to do so, yet.

Anyway, my CPU is an AMD Ryzen 7 3800X 8-Core processor, I have 16GB of RAM, I have a 512GB SSD and a 10TB HDD, and I have a power supply by EVGA.

 

[Colif]

well, until you know the ram is not the problem, any BSOD you get could be caused by ram.

You have had Ubuysa, Johnbl & me work on it... there aren't many other people on Tom's who know BSOD as well as the first two. And we don't seem to be getting anywhere

what are codes on Ram? IE, who made it
Who made SSD/hdd? most makers have software you can use to test their drives.

 

[ConorDuey2000]

well, until you know the ram is not the problem, any BSOD you get could be caused by ram.

You have had Ubuysa, Johnbl & me work on it... there aren't many other people on Tom's who know BSOD as well as the first two. And we don't seem to be getting anywhere

what are codes on Ram? IE, who made it
Who made SSD/hdd? most makers have software you can use to test their drives.

I have two 8GB sticks of G.Skill DDR4 RAM, a Samsung 970 EVO M.2 SSD, and a Western Digital Black 7200 RPM HDD.

 

[ubuysa]

Firstly, did you update the BIOS to the latest version (including the AGESA update)?

Secondly, and just for your education, a very large number of BSODs reference ntoskrnl.exe (the Windows kernel) or, as in this dump, ntkrnlmp.exe (the Windows multiprocessor kernel). That's because most drivers run in kernel mode and if a driver fouls up (or the hardware fouls up a driver) the problem is not often detected until the driver retruns control to the kernel and the kernel validates what the driver is asking for. If at that point the kernel finds that the driver has fouled up it will BSOD (because the kernel has no way of knowing whether the foul up will corrupt user data - BSODs occur to protect user data) and the failing module in the dump will then of course be the kernel. That's why you need people with experience in analysing dumps, because it's necessary to be able to interpret what the kernel was doing, which drivers were involved, and where the problem occured.

I've looked at that 0xA mindump you uploaded and whilst it's dangerous making a diagnosis based on only one dump, my belief is that this is most likely a RAM problem.

Here's the key part of the call stack from your recent minidump. This logs all the function calls that led up to the bugcheck and you read it from the bottom up...

9: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffffdb08`cb8e6108 fffff800`76227da9     nt!KeBugCheckEx
01 ffffdb08`cb8e6110 fffff800`76223434     nt!KiBugCheckDispatch+0x69
02 ffffdb08`cb8e6250 fffff800`76023ffb     nt!KiPageFault+0x474
03 ffffdb08`cb8e63e0 fffff800`76027d23     nt!KiSetClockTimer+0x73
04 ffffdb08`cb8e6530 fffff800`7602748a     nt!KeResumeClockTimerFromIdle+0x1b3
05 ffffdb08`cb8e6610 fffff800`760268b1     nt!PpmIdleExecuteTransition+0x9aa
06 ffffdb08`cb8e6a50 fffff800`762174f4     nt!PoIdle+0x361
07 ffffdb08`cb8e6c40 00000000`00000000     nt!KiIdleLoop+0x54

The processor is running the idle loop here, there is no real work for it to do so this is all housekeeping. You can see that wer're getting and resetting a clock timer, and then we get a page fault. This indicates that an invalid memory location was referenced - it was either paged out, not allocated, or the RAM page is bad.

We can see exactly where the page fault occurred in the dump as well, and why...

TRAP_FRAME:  ffffdb08cb8e6250 -- (.trap 0xffffdb08cb8e6250)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000022b213a676e rbx=0000000000000000 rcx=0000022b213a676e
rdx=00000000000001d8 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80076023ffb rsp=ffffdb08cb8e63e0 rbp=ffffdb08cb8e64e0
 r8=0000000000000000  r9=fffff78000000294 r10=0000fffff800761c
r11=ffff91fcd8200000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up di pl nz na pe nc
nt!KiSetClockTimer+0x73:
fffff800`76023ffb 4c89b4f7188e0000 mov     qword ptr [rdi+rsi*8+8E18h],r14 ds:00000000`00008e18=????????????????
Resetting default scope

Here you can see that the nt!KiSetClockTimer function is executing the mov instruction using the RDI and RSI registers as pointers to a memory location, but the resulting location is invalid (indicated by the ????????????????). It's not credible that these Windows functions calculated the address location wrongly, so bad RAM is the most likely cause.

Note: It is also remotely possible that the processor (CPU) is the cause. Note that the RSI register is all zeros and that's what has caused the invalid address pointer. Whilst bad RAM is the most likely cause and must be tested, this could be a flaky processor in your CPU. We can test that once you've tested your RAM.

I do note that earlier you said this...

I haven't ran memtest86, yet, because I don't have the time to do so, yet.

Do you see how that might be insulting to those of us who give up our free time to help you fix whatever problem you're having? What if we said that we don't have the time to help you? I have plenty of other things I could be doing on this sunny and warm Sunday.

Please test your RAM. We really can't move on until we are confident that RAM is not the problem...
If you have more than one stick of RAM then remove one stick and run on just one for a couple of days - or until you get another BSOD. Then swap RAM sticks and run on just the other RAM stick for a couple of days. This will clearly show whether one stick is flaky.

-or-

Download Memtest86 (free), use the imageUSB.exe tool extracted from the download to make a bootable USB drive containing Memtest86 (1GB is plenty big enough). Do this on a different PC if you can, because you can't fully trust yours at the moment. Then boot that USB drive on your PC, Memtest86 will start running as soon as it boots. If no errors have been found after the four iterations of the 13 different tests then restart Memtest86, and do another four iterations. Even a single error is a failure.

 

[Colif]

ntkrnlmp.exe (the Windows multiprocessor kernel)

i always did wonder what that meant

 

[ConorDuey2000]

I'm still getting HYPERVISOR_ERROR bluescreens. Even after updating the BIOS and even after updating Windows. At this point, I'm thinking of buying a new computer because I've tried everything from A to Z except for buying a new computer and nothing has solved this problem. Apparently, after debugging my latest HYPERVISOR_ERROR bluescreen, it told me that Winamp was the cause of the bluescreen. Anyway, here is the minidump and here is the kernel dump. I'm gonna need some expert debuggers for this.

 

[ubuysa]

WinAmp was the process in control at the time of the BSOD but the kernel can be accessed from any address space (it's mapped into all address spaces) so the process in control is often irrelevant - as it is in this case.

This still looks like bad RAM to me. Her'es your entire call stack...

ffff9e84`fcabc938  fffff807`3fddc83b nt!MmFreeVirtualMemory+0x2fb
ffff9e84`fcabc978  fffff807`3fd676b4 nt!NtAllocateVirtualMemory+0x104
ffff9e84`fcabca78  fffff807`3fddc505 nt!NtFreeVirtualMemory+0x95
ffff9e84`fcabcad8  fffff807`3fa274e8 nt!KiSystemServiceCopyEnd+0x28

You read it from the bottom up, and you can see it's exclusively dealing with virtual memory allocations - that strongly suggests a RAM issue.

You need to either run Memtest86 (and run it twice so you do 8 iterations of the 13 different tests) or remove one RAM stick for a day or two, then swap sticks and run on just the other for a day or two.

It's really not possible for us to go any further until you've checked your RAM.

 

[Colif]

Have you tested your ram or just run on one stick like suggested above and see if you still get BSOD

WE not going to look at dumps until we know ram is okay. Its a complete waste of time for all of us until then. If you don't have time, buy new ram and see if it makes any difference. Beats buying an entire new pc.

 

[ConorDuey2000]

WinAmp was the process in control at the time of the BSOD but the kernel can be accessed from any address space (it's mapped into all address spaces) so the process in control is often irrelevant - as it is in this case.

This still looks like bad RAM to me. Her'es your entire call stack...

ffff9e84`fcabc938  fffff807`3fddc83b nt!MmFreeVirtualMemory+0x2fb
ffff9e84`fcabc978  fffff807`3fd676b4 nt!NtAllocateVirtualMemory+0x104
ffff9e84`fcabca78  fffff807`3fddc505 nt!NtFreeVirtualMemory+0x95
ffff9e84`fcabcad8  fffff807`3fa274e8 nt!KiSystemServiceCopyEnd+0x28

You read it from the bottom up, and you can see it's exclusively dealing with virtual memory allocations - that strongly suggests a RAM issue.

You need to either run Memtest86 (and run it twice so you do 8 iterations of the 13 different tests) or remove one RAM stick for a day or two, then swap sticks and run on just the other for a day or two.

It's really not possible for us to go any further until you've checked your RAM.

Have you tested your ram or just run on one stick like suggested above and see if you still get BSOD

WE not going to look at dumps until we know ram is okay. Its a complete waste of time for all of us until then. If you don't have time, buy new ram and see if it makes any difference. Beats buying an entire new pc.

Well, I have done everything from A to Z except for checking my RAM and running Memtest86. I've never had the time to run that program. Thanks to ubuysa suggesting that it might be bad RAM that's causing the BSODs, I'll make time in my computer using schedule to run Memtest86. I'm planning on upgrading my RAM on Christmas, anyway, so I'll have plenty of time to run Memtest86.

I've also deleted the two dumps from my Google Drive since as Colif said, there's no point in people looking at my dumps if they don't know if the RAM is okay or not.

 

[Colif]

Bad ram makes everything it touches look bad. You can replace drivers all you like but most of the time, the problem just appears to be something else. Every process has to go through ram so if its bad, it taints everything.

Not trying to be mean, but until you know its not the problem, its pointless looking at dump files.

 

[ubuysa]

Yes, but there are often subtle clues

Bad ram makes everything it touches look bad.

Not trying to be mean, but until you know its not the problem, its pointless looking at dump files.

Yes, but there are often subtle clues in dumps (especially if you have many) that can point either towards RAM or towards something else. These dumps are pointing strongly at RAM - that's why there is no point looking any further until the RAM is checked.

 

[Colif]

I get that. I wish you had been here a year ago when he first asked. Might have saved some time