Windows 10 KB5016616 update in guest causes hang on boot

[ScottB_NJ]

When installing this month's Windows 10 cumulative update (KB5016616), I'm finding that the VM hangs when restarting to finalize the patch. Specifically this is occurring just after the guest's window expands to full size, when the background is black, just before any of the normal Windows "Please Wait" messaging. The VM is not frozen, but the bouncing ball animation will continue "forever" (at least 15 minutes) with very little disk activity. Restarting the guest does not help. Safe Mode does not help. The only way out I've found is to do a System Restore in the guest to back before the patch was installed.

In the attached log -- which covers only the faulty restart -- the hang occurs at line 1335 just after "Display::i_handleDisplayResize" is reported. Prior to the patch install, the log would have continued with the Guest Additions reporting its version, the OS version, and so on.

I also tried increasing the video memory as high as 192 MB and even enabling 3-D acceleration. Neither of these changes made any difference in the boot behavior.

Here are my particulars:

• Host OS: Ubuntu 20.04.5 (64-bit) -- 24 GB RAM
• VirtualBox 6.1.36 (installed from .DEB)
• Guest OS: Windows 10 Pro 21H2 (64-bit) -- 6100 MB RAM, 4 processors
• VirtualBox Guest Additions 6.1.36

Is there anything else I can try?

Thanks,
Scott

[mpack]

Maybe try increasing the graphics RAM? 27MB is rather weedy, I'm surprised the setting dialog wasn't giving you warnings about it. You have plenty of RAM, so max this parameter out. I would also enable 3D acceleration if your host supports it.

[AndyCot]

The 7.0 beta 1 GUI setting snow allow you to go up to 256 like the CLI used to in 6.x, so try 256MB.

[mpack]

256MB should not be necessary, as 128MB is already ~5 times the presently configured amount. I'm also not sure it's a good idea to promote an early beta to a potential beginner. Anyway please keep discussion of the beta to the appropriate forum.

[ScottB_NJ]

Maybe try increasing the graphics RAM? 27MB is rather weedy, I'm surprised the setting dialog wasn't giving you warnings about it. You have plenty of RAM, so max this parameter out. I would also enable 3D acceleration if your host supports it.

3D Acceleration caused painting problems within Windows, so I'm guessing my video card is not up to the task. However, enabling 3D and then disabling it allowed me to increase the graphics RAM to 256MB. Unfortunately it made no difference in the outcome; Windows is still hanging as I described earlier.

I'm including another log because this one captures a normal boot (prior to the patch install) and then a failed boot (after the patch install).

[scottgus1]

3D Acceleration caused painting problems within Windows

Some of these problems are known. With 3D enabled, disable Settings > Personalization > Colors > Transparency Effects in your Windows 10 VM.

unactivated Windows 10 has the same setting here:
Ease of Access > Display > Simplify and personalize Windows > Show transparency in Windows

[fth0]

The major difference between the working and not-working situation is that inside the guest OS, VBoxService.exe couldn't (successfully?) be started in the latter case. I'd suggest to investigate what keeps VBoxService.exe from running ...

[ScottB_NJ]

I'd suggest to investigate what keeps VBoxService.exe from running ...

I followed some of your suggestions to TomMainz in the similar MacOS thread, and a few things I thought of:

• Uninstalling Guest Additions prior to installing KB5016616 still causes the same hangup.
• Shutting down the VM rather than rebooting after installing KB5016616 still causes the same hangup.
• Using MSCONFIG to select Diagnostic Startup mode (only essential system services) after installing KB5016616 still causes the same hangup.
• Disabling USB and Networking features in the VM settings does not resolve the hangup.

Whatever this hangup is, it is occurring relatively early in the Windows boot process. I attempted to look at logs by booting into the Windows Recovery Environment and using WEVTUTIL, but found only system shutdown messages (from just after the patch installation) in the System and Application logs.

[fth0]

Kudos for having good ideas and investigating yourself. Some further ideas to try:

I've just read that KB5016616 is known to have audio related issues. For a test, disable audio in the VM configuration.

Reproduce the issue and shut down the VM to the powered-off state. Start the VM, let it run/hang for 2 minutes and shut it down again. Do the same but wait for 10 minutes instead. Provide a zip file containing the VBox.log and VBox.log.1 files. The VirtualBox statistics in the log files may give an indication what the VM is doing in the 8 additional minutes. Additionally, use your favorite task manager on your host OS and the status bar icons at the bottom of the VM's window to monitor what the guest OS may be doing during the experiments.

[ScottB_NJ]

For a test, disable audio in the VM configuration.

That's an easy one; this VM has never had audio enabled.

let it run/hang for 2 minutes and shut it down again. Do the same but wait for 10 minutes instead.

In the attached logs, the 10 minute test will appear to have occurred first. The reason is that Windows invokes an automatic repair process on the second and subsequent boot attempts. When the repair fails, I have to select "Continue to Windows 10" which will appear in the log as a 'RESETTING' state. I just wanted to make sure the tests both had that automatic repair phase.

During the hang time, there is very little activity in the host's System Monitor or on the guest's status bar. I think the disk icon blinks red about once every 30 seconds. Memory consumption is stable. Some host CPU time is consumed driving the "circling ball" animation but it doesn't even reach 1% in the monitor.

[fth0]

The log files match your descriptions:

CPU: All vCPUs are more or less in a halted state, and the RIP is identical. This looks like the Windows guest OS is waiting for some event to occur.

Disk I/O: ~2 GB have been read from the virtual hard disk, and ~300 MB / ~15 MB have been written. Because of the automatic repair process, I'm not sure if the difference of ~285 MB can be attributed to the runtime difference.

Network I/O: There hasn't been much activity, which could match the early hang.

Memory et. al.: I've looked at a lot of statistics, but didn't see anything unusual.

Now the question is what to do next? There are endless ways to modify the VM configuration by stripping/adding/changing things. Additionally, VirtualBox provides a built-in VM debugger, which can also display the statistics in realtime. And you can pretend that the hang happens on a physical PC and act accordingly (like you already did).

PS: There's one thing I don't understand: The VBox.log files indicate that on the first boot, VBoxGuest.sys 6.1.4 is being started. Do you have any idea where that may come from?

[lordavatar1234]

Note - I experienced this issue with a 64 bit Windows 10 21H2 VM, configured with EFI boot, with the KB5016616 update. Waiting to install the KB5017308 (September 9 2022 Cumulative Update), did not resolve the issue, as the new patch just caused it to reoccur (i.e. patch applies fine, but system stalls / hangs on boot). My Setup is as follows -

Ubuntu 22.04 Host - 5.15.x HWE Kernel
Virtual Box 6.1.38, with extensions installed.

I was able to resolve the matter, by reinstalling Windows 10 21H2 on the VM from Microsoft's installation medium, and letting it update afterwards to the latest patch level. I had, previously, installed Intel ATA IDE / SATA drivers, Intel Chipset INF drivers, and Virtio-Net drivers in the Guest OS before I ran update / patches and ran into the boot issue. Given that there were no problems with the clean reinstall (i.e. using the default Microsoft chipset and storage controller drivers) and subsequent application of the updates, I'd suggest that you uninstall any third party drivers in the Windows 10 Guest before installing the latest patch sets. Otherwise, if that does not work, you can always backup your data from the VM, and do a clean reinstall of Windows 10 21H2 to it.

[scottgus1]

I had, previously, installed Intel ATA IDE / SATA drivers, Intel Chipset INF drivers, ... in the Guest OS

The VM doesn't have Intel ATA or Chipset devices in it. No need for these 3rd-party drivers, and they'll probably bung up the VM.

The 'hardware' made by the VM is natively supported by the OS's installed in the VM, provided the VM template is selected compatibly with the OS chosen. The only extra drivers needed by the VM OS are in the Guest Additions.

[Hazrelle]

Not sure if it may be related to your issue.
I've noticed some hang on boot with the Windows Logo. While the graphics during the boot process is not always perfect, the hanging was not so long previsouly.
I've a Win10 guest whose performance decreased since few days, especially after upgrading VirtualBox to 6.1.38 r153438 with matching guest additions.
With a dedicated host's SSD for guests, Intel Core i7-6820HQ and a 64Go RAM (20 for the Win10 guest) it was a bit unusual especially that this guest is running very well since 6 months.
My VM had nested Hardware Virtualization set on and disabling it seems better now.

VBoxManage modifyvm vmname --nested-hw-virt off

Give it a try maybe.
Regards

[lordavatar1234]

I agree that 3rd party chipset and sata / ata drivers are typically not required. However -

The 'hardware' made by the VM is natively supported by the OS's installed in the VM, provided the VM template is selected compatibly with the OS chosen. The only extra drivers needed by the VM OS are in the Guest Additions.

This is not entirely true. If you want to use any paravirtualized devices with the VM (i.e. Virtio-Net as a networik adapter for instance), you have to install said drivers separately in Windows Guests, as those drivers are not included with Windows. The Virtual Box manual explicitly mentions this -

"The Paravirtualized network adapter (virtio-net) is special. If you select this adapter, then Oracle VM VirtualBox does not virtualize common networking hardware that is supported by common guest operating systems. Instead, Oracle VM VirtualBox expects a special software interface for virtualized environments to be provided by the guest, thus avoiding the complexity of emulating networking hardware and improving network performance. Oracle VM VirtualBox provides support for the industry-standard virtio networking drivers, which are part of the open source KVM project.

The virtio networking drivers are available for the following guest operating systems:

Linux kernels version 2.6.25 or later can be configured to provide virtio support. Some distributions have also back-ported virtio to older kernels.

For Windows 2000, XP, and Vista, virtio drivers can be downloaded and installed from the KVM project web page:

http://www.linux-kvm.org/page/WindowsGuestDrivers. "

See - https://www.virtualbox.org/manual/ch06.html