Win 10 guest freeze after heavy write load

[doubleP]

When I start my VM its boots and login to desktop fine. But if I install new software on it or update the OS its freeze after some times. I have notice that on my host the dirty memory increases fast after short time while I install something on the guest. After time the host want to sync the data to the drives. While the sync the guest hangs. If the sync takes too many time the guest freeze.
For test I have change the graphic controller to VMSVGA. Therefore I can see a BSOD at the moment when the OS freeze. The BSOD message is CRITICAL_PROCESS_DIED. But normally I use the VBoxSVGA.

Host: Arch Linux 64 (Up-to-date)
Kernel: 5.16.2
RAM: 64GB

Guest: Windows 10 64
21H1
Guest additions is installed

VB: 6.1.32

Please tell me if you need more information.

[fth0]

Please try if setting System > Acceleration > Paravirtualization Interface to Default or Hyper-V makes a difference.

[doubleP]

Hi fth0,
thanks for reply.

I have testet Default, Hyper-V and KVM as paravirtualisation. It makes no difference. Normally I use the default.

[mpack]

You have assigned 4 out of 4 cores cores to the VM, leaving 0 cores for the host. Btw VirtualBox is a host app, so this is not good.

Try reducing VM cores to 2.

[doubleP]

Okay I have reset paravirtualisation to default and reduces the cores to 2. But the result are the same.

BTW Virtualbox provide up to 8 cores to set in my case. Because I have 8 virtual cores by the Intel HT-Techonolgy therefore I thought set to 4 cores are okay.

[mpack]

There is no such thing as a "virtual core". Core means actual silicon, and "virtual actual silicon" makes no sense.

Your host CPU has 4 cores. 2 of those should be retained for the host, that leaves 2 for the guest.

00:10:57.431866 GIM: HyperV: Guest indicates a fatal condition! P0=0xef P1=0xffffc585caba9140 P2=0x0 P3=0x0 P4=0x0
00:10:57.431891 GIMHv: BugCheck ef {ffffc585caba9140, 0, 0, 0}
00:10:57.431892 CRITICAL_PROCESS_DIED
00:10:59.772267 VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be unresponsive. Last heartbeat received 4 seconds ago
00:11:02.233397 VMMDev: Guest Log: VBoxGuest: BugCheck! P0=0xef P1=0xffffc585caba9140 P2=0x0 P3=0x0 P4=0x0

A device or driver inside the guest is dying. I have no idea which, though I suspect "heavy write load" is a clue, which may indicate a problem with the cache. I see that the GAs are slightly out of date, it may be worthwhile to update them.

[doubleP]

Okay that makes sense to me with the silicon cores.
I had restore my snapshot with an older GA version but now I have updated to 6.1.32 but with the same result.

Maybe I explain my assumption with the heavy write load:
I look in /proc/meminfo at the "Dirty" and "Writeback" values of the host. When VB is off everything looks fine. Both values <1MB. When I start VB and windows boots up until desktop the dirty memory increases to ~10MB and after a while the host flush it to writeback and the memory sync to the drives. To this time is everything okay too. When I create big files (>1GB) or start an big software installation at the guest OS than the dirty memory at the host increases like expected. When the dirty memory reach the limit or the timeout is exceeded the host want to flush the data to the drives. At this moment the guest OS hangs. When the host only sync small sizes(<200MB) of the memory the guest is responsible after the sync. But when the size of the memory is too big(>600MB) the sync takes too much time and the guest OS crashes. The host is uneffected.

My turnaround at the moment is to stop the VM every few seconds and wait for sync at the host.

[fth0]

00:00:00.894316 VirtualBox VM 6.1.32 r149290 linux.amd64 (Jan 18 2022 20:32:19) release log
00:00:00.894318 Log opened 2022-01-27T18:13:26.806541000Z
[...]
00:10:57.431892 CRITICAL_PROCESS_DIED

Regarding the CRITICAL_PROCESS_DIED error, you could search the Windows Event Viewer for log messages around 2022-01-27T18:24 UTC (19:24 if your located in the UTC+1 timezone ).

[doubleP]

I have looked and there is no event at that time point. The last logged event was at 19:20 and was an information event about key changes and the next is the reboot event.