Problems with BSOD Hypervisor Error

terumimain

Member
Joined
Jan 27, 2024
Posts
5
Hello,

I've been having problems with this BSOD for quite awhile and it's making me crazy, if i have hyper-v enabled, every like 5 to 20 minutes i will have a bsod saying, HYPERVISOR ERROR, or SYNTHETIC WATCHDOG TIMEOUT.
I read it on google and other forums that this could be a hardware problem, but if i don't enable hyper-v, the computer literally works 100% fine, it's only when hyper-v is enabled that i have the bsod, i even did a fresh install of windows 11 pro, and i still have the same problem.
I've done almost everything that i could think of, and this problem still persists, if someone could help me i definetly would appreciate it! i need hyper-v for some stuff that i've been doing and this problem is making me crazy.
i will put my computer specs and the minidump files below:

CPU: AMD FX(tm)-8300 Eight-Core Processor 3.32 GHz;
RAM: 16,0 GB (4 ram sticks, 4gb each);
Motherboard: Gigabyte GA-78LMT-USB3 R2 (rev 1.0);
Power Supply: Hoopson FNT-500W;
Graphics Card: GALAXY GTX 1050 2gb.

appreciate any help.
 

Attachments

Hello and welcome to the forum!

It would help greatly if you could follow the BSOD Posting Instructions, run the data collection tool there and upload the zip file. That gives us all of the troubleshooting data we're likely to need.

There is one common thread running through all your dumps; they all fail with a STACKPTR_ERROR. These are memory pointers that point to a structure called a stack - they are used for storing temporary data. This error indicates that a stack pointer is no longer pointing at the proper memory address. Often this is a driver foul-up and sometimes it's a RAM error. Since your system is fine with Hyper-V disabled we can probably discount a RAM problem, so we're looking for a driver that fouls-up only when running under Hyper-V. This is going to be a third-party driver of course, Microsoft drivers have been so well and so extensively tested that they can be considered faultless.

There is a second common theme that runs through most of your dumps; there is a network access taking place. In addition in some dumps I can see storage drive accesses and graphics driver accesses as well - it looks as though most dumps failed during a video streaming operation? The graphics driver nvlddmkm.sys is referenced in some dumps, but the version of this driver you have is very current...
Code:
0: kd> lmvm nvlddmkm
Browse full module list
start             end                 module name
fffff801`298a0000 fffff801`2d2c8000   nvlddmkm T (no symbols)          
    Loaded symbol image file: nvlddmkm.sys
    Image path: nvlddmkm.sys
    Image name: nvlddmkm.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Jan 18 08:57:27 2024 (65A8CBD7)
    CheckSum:         03903636
    ImageSize:        03A28000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

However, a couple of dumps also specifically reference your LAN driver (rt640x64.sys)...
Code:
6: kd> lmvm rt640x64
Browse full module list
start             end                 module name
fffff802`9fd90000 fffff802`9fea8000   rt640x64 T (no symbols)          
    Loaded symbol image file: rt640x64.sys
    Image path: rt640x64.sys
    Image name: rt640x64.sys
    Browse all global symbols  functions  data
    Timestamp:        Tue May 11 06:30:41 2021 (6099FA61)
    CheckSum:         0011EFE0
    ImageSize:        00118000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
This driver, as you can see, is getting quite old now, so it's not impossible that this driver is the cause of the system hangs that cause your BSODs. Even though this driver is only specifically referenced in only two dumps it will have been called in all of the dumps that were performing a networking operation (and that's most of them).

I took a look at your motherboard website to see whether there was an updated driver there, and MSI do not support Windows 10 on this motherboard, only up to Windows 7, so there is no later driver. You're running Windows 10 on unsupported hardware, so you might expect to have some issues.

I did wonder whether you might be able to source an updated driver from Realtek (it's a driver for a Realtek 8136/8168/8169 adapter) but a quick search seems to suggest that only Windows 7 drivers are available for this LAN adapter. Where did the driver you have come from? Are there any optional Windows updates for your LAN adapter? Be very wary of using tools like DriverEasy to find updated drivers, they are not reliable.

If you have a WiFi adapter available, even a USB adapter, you might try using that instead of the LAN adapter to see whether that's stable with Hyper-V. That would at least help to confirm whether it's the LAN adapter that is at fault. If you try this then first disable the LAN adapter (in Device Manager) and then reboot, so that the rt640x64.sys driver is not loaded.

In any case, please upload the SysnativeBSODCollectionApp output, there may be more clues in there.
 
Hello and welcome to the forum!

It would help greatly if you could follow the BSOD Posting Instructions, run the data collection tool there and upload the zip file. That gives us all of the troubleshooting data we're likely to need.

There is one common thread running through all your dumps; they all fail with a STACKPTR_ERROR. These are memory pointers that point to a structure called a stack - they are used for storing temporary data. This error indicates that a stack pointer is no longer pointing at the proper memory address. Often this is a driver foul-up and sometimes it's a RAM error. Since your system is fine with Hyper-V disabled we can probably discount a RAM problem, so we're looking for a driver that fouls-up only when running under Hyper-V. This is going to be a third-party driver of course, Microsoft drivers have been so well and so extensively tested that they can be considered faultless.

There is a second common theme that runs through most of your dumps; there is a network access taking place. In addition in some dumps I can see storage drive accesses and graphics driver accesses as well - it looks as though most dumps failed during a video streaming operation? The graphics driver nvlddmkm.sys is referenced in some dumps, but the version of this driver you have is very current...
Code:
0: kd> lmvm nvlddmkm
Browse full module list
start             end                 module name
fffff801`298a0000 fffff801`2d2c8000   nvlddmkm T (no symbols)         
    Loaded symbol image file: nvlddmkm.sys
    Image path: nvlddmkm.sys
    Image name: nvlddmkm.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Jan 18 08:57:27 2024 (65A8CBD7)
    CheckSum:         03903636
    ImageSize:        03A28000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

However, a couple of dumps also specifically reference your LAN driver (rt640x64.sys)...
Code:
6: kd> lmvm rt640x64
Browse full module list
start             end                 module name
fffff802`9fd90000 fffff802`9fea8000   rt640x64 T (no symbols)         
    Loaded symbol image file: rt640x64.sys
    Image path: rt640x64.sys
    Image name: rt640x64.sys
    Browse all global symbols  functions  data
    Timestamp:        Tue May 11 06:30:41 2021 (6099FA61)
    CheckSum:         0011EFE0
    ImageSize:        00118000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
This driver, as you can see, is getting quite old now, so it's not impossible that this driver is the cause of the system hangs that cause your BSODs. Even though this driver is only specifically referenced in only two dumps it will have been called in all of the dumps that were performing a networking operation (and that's most of them).

I took a look at your motherboard website to see whether there was an updated driver there, and MSI do not support Windows 10 on this motherboard, only up to Windows 7, so there is no later driver. You're running Windows 10 on unsupported hardware, so you might expect to have some issues.

I did wonder whether you might be able to source an updated driver from Realtek (it's a driver for a Realtek 8136/8168/8169 adapter) but a quick search seems to suggest that only Windows 7 drivers are available for this LAN adapter. Where did the driver you have come from? Are there any optional Windows updates for your LAN adapter? Be very wary of using tools like DriverEasy to find updated drivers, they are not reliable.

If you have a WiFi adapter available, even a USB adapter, you might try using that instead of the LAN adapter to see whether that's stable with Hyper-V. That would at least help to confirm whether it's the LAN adapter that is at fault. If you try this then first disable the LAN adapter (in Device Manager) and then reboot, so that the rt640x64.sys driver is not loaded.

In any case, please upload the SysnativeBSODCollectionApp output, there may be more clues in there.
Hello, Thanks for the answer!

I will put the file that i got below, but before that, one weird thing is, i'm actually using windows 11 pro, and it's a fresh install of windows 11 pro, i didn't use any programs like drivereasy, because if i recall, windows 11 already updates all drivers (atleast it was like that on windows 10), the only one that i had to update was the nvidia drivers, because they came pretty old.

I already installed all windows updates (even all the additional ones) and i don't really know where this realtek driver is coming from. this is a fresh install and the only thing i have downloaded now, it's Steam, my browser, and the culprit which actually is using hyper-v, Google Play Games Beta, i have other stuff too, but it doesn't really involve hyper-v and it's mostly microsoft stuff like office and teams.

About the video streaming emulation, i don't really know what it could be, i don't stream or do stuff like that, and it's completely random when the bsod happens, i thought it could be the Google Play Games Beta, so i uninstalled it and activated hyper-v, but even then, it still crashes.

About the lan driver, i got a new cable, the one that i had before was pretty old, i had it for 7 years i think, i changed to a new one 2 days ago, because that one broke. maybe it could be this? i don't know.

Before i forget. Thanks for the answer! even just knowing what it could be is already helping because i spended like 2 days straight trying to solve this, having a answer this close is already encouraging!
 

Attachments

Hello and welcome to the forum!

It would help greatly if you could follow the BSOD Posting Instructions, run the data collection tool there and upload the zip file. That gives us all of the troubleshooting data we're likely to need.

There is one common thread running through all your dumps; they all fail with a STACKPTR_ERROR. These are memory pointers that point to a structure called a stack - they are used for storing temporary data. This error indicates that a stack pointer is no longer pointing at the proper memory address. Often this is a driver foul-up and sometimes it's a RAM error. Since your system is fine with Hyper-V disabled we can probably discount a RAM problem, so we're looking for a driver that fouls-up only when running under Hyper-V. This is going to be a third-party driver of course, Microsoft drivers have been so well and so extensively tested that they can be considered faultless.

There is a second common theme that runs through most of your dumps; there is a network access taking place. In addition in some dumps I can see storage drive accesses and graphics driver accesses as well - it looks as though most dumps failed during a video streaming operation? The graphics driver nvlddmkm.sys is referenced in some dumps, but the version of this driver you have is very current...
Code:
0: kd> lmvm nvlddmkm
Browse full module list
start             end                 module name
fffff801`298a0000 fffff801`2d2c8000   nvlddmkm T (no symbols)        
    Loaded symbol image file: nvlddmkm.sys
    Image path: nvlddmkm.sys
    Image name: nvlddmkm.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Jan 18 08:57:27 2024 (65A8CBD7)
    CheckSum:         03903636
    ImageSize:        03A28000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

However, a couple of dumps also specifically reference your LAN driver (rt640x64.sys)...
Code:
6: kd> lmvm rt640x64
Browse full module list
start             end                 module name
fffff802`9fd90000 fffff802`9fea8000   rt640x64 T (no symbols)        
    Loaded symbol image file: rt640x64.sys
    Image path: rt640x64.sys
    Image name: rt640x64.sys
    Browse all global symbols  functions  data
    Timestamp:        Tue May 11 06:30:41 2021 (6099FA61)
    CheckSum:         0011EFE0
    ImageSize:        00118000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
This driver, as you can see, is getting quite old now, so it's not impossible that this driver is the cause of the system hangs that cause your BSODs. Even though this driver is only specifically referenced in only two dumps it will have been called in all of the dumps that were performing a networking operation (and that's most of them).

I took a look at your motherboard website to see whether there was an updated driver there, and MSI do not support Windows 10 on this motherboard, only up to Windows 7, so there is no later driver. You're running Windows 10 on unsupported hardware, so you might expect to have some issues.

I did wonder whether you might be able to source an updated driver from Realtek (it's a driver for a Realtek 8136/8168/8169 adapter) but a quick search seems to suggest that only Windows 7 drivers are available for this LAN adapter. Where did the driver you have come from? Are there any optional Windows updates for your LAN adapter? Be very wary of using tools like DriverEasy to find updated drivers, they are not reliable.

If you have a WiFi adapter available, even a USB adapter, you might try using that instead of the LAN adapter to see whether that's stable with Hyper-V. That would at least help to confirm whether it's the LAN adapter that is at fault. If you try this then first disable the LAN adapter (in Device Manager) and then reboot, so that the rt640x64.sys driver is not loaded.

In any case, please upload the SysnativeBSODCollectionApp output, there may be more clues in there.
Hello. sorry for quoting the response again, but i think i got some new information about the bsod.

I completely uninstalled the old lan driver that i was using and restarted the pc so the driver would install again, after that i enabled hyper-v again, but the same problem still persisted, one of the bsods happened while i tried to install a game on Google Play Games Beta, and the other happened after 5 minutes on a clean boot, i will put the new minidump files below:
 

Attachments

Windows Error Reporting: shows problems with Radar Pre_Leak_64 involving tbs_browser.exe, nikke.exe, GGST-Win64-Shipping.exe,opera.exe,HD-Player.exe
Hello.

what would you recommend me to do with this radar pre_leak_64 problem? is there something i should do with these files that you highlighted?
 
is there something i should do with these files that you highlighted?
No, I would just ignore any errors shown by WER since they'll be unrelated to your crashes. The last three crashes were all because your hardware doesn't understand how to handle NMIs and since these crashes do not occur with Hyper-V disabled then I doubt your hardware supports modern virtualisation.
 
No, I would just ignore any errors shown by WER since they'll be unrelated to your crashes. The last three crashes were all because your hardware doesn't understand how to handle NMIs and since these crashes do not occur with Hyper-V disabled then I doubt your hardware supports modern virtualisation.
Is the virtualization that you're talking about the one that shows on the task manager? because i enabled it on my bios and it shows up as enabled on the task manager.

Captura de Tela (1).png
 
because i enabled it on my bios and it shows up as enabled on the task manager.
Yes, Windows 11 is far more dependent on virtualisation than previous iterations of Windows which is part of the reason why the processor requirement was set so high. If you need to run Hyper-V, then you're going to at least need to get a supported processor which will mean a new motherboard as well.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top