Windows x86 10 guest hangs after KB5019959 update

[virtual_name]

Hi,

My x86 Windows 10 guest on Windows 10 host hangs after reboot before login GUI after KB5019959 update. It happens consistently and I had to power off and let guest Windows to roll back the update. Is this a known issue? I couldn't find anything from googling.

Thanks all for the help.

[mpack]

Please provide a VM log file. Make sure the VM is fully shut down, then right click it in the manager UI. Select "Show Log" and save "VBox.log" (no other file) to a zip file. Attach the zip here.

[virtual_name]

Here is the log after hang and power off.

[mpack]

You have Hyper-v enabled.

00:00:04.710586 HM: HMR3Init: Attempting fall back to NEM: VT-x is not available
00:00:04.775324 NEM: info: Found optional import WinHvPlatform.dll!WHvQueryGpaRangeDirtyBitmap.
00:00:04.775407 NEM: WHvCapabilityCodeHypervisorPresent is TRUE, so this might work...

See HMR3Init: Attempting fall back to NEM (Hyper-V is active).

[virtual_name]

Thank you for the quick reply and suggestion. I have turned off the hyper-v from bcdedit in host:

Windows Boot Loader
-------------------
identifier {8a9589b4-d92c-11eb-95ab-cc3d4e149185}
device partition=C:
path \Windows\system32\winload.efi
description Windows 10
locale en-US
inherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
recoverysequence {8a9589b5-d92c-11eb-95ab-cc3d4e149185}
displaymessageoverride Recovery
recoveryenabled Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \Windows
resumeobject {8a9589b3-d92c-11eb-95ab-cc3d4e149185}
nx OptIn
bootmenupolicy Standard
hypervisorlaunchtype Off

But it has the same problem: windows keep spinning the circle during boot. Not sure why it worked perfectly before guest update if it's host hyper-v issue. It was set to "auto".

Attached is the new hang log after powering off the guest. Thanks.

[mpack]

Does the VM not show you an error message? One is certainly recorded in the log.

00:00:09.082718 VM: Raising runtime error 'DrvVD_DEKMISSING' (fFlags=0x6)
00:00:09.082778 Changing the VM state from 'RUNNING' to 'SUSPENDING'
...
00:00:09.401764 Console: VM runtime error: fatal=false, errorID=DrvVD_DEKMISSING message="VD: The DEK for this disk is missing"

The DEK error implies that this disk is encrypted by VirtualBox. The lack of a DEK would not be caused by any Windows Update, it would be caused by... I'm not sure what. Somehow you have cloned a hard drive but manually edited away the DEK? Note that when it says "fatal=false", that is not necessarily good news. I assume it means that the VM is happy to continue, it doesn't mean that the guest OS can still boot.

To complicate matters you appear to have a couple of snapshots layered on top of the encrypted disk, so fixing this is unlikely until we get to the bottom of the problem.

I'm afraid you're going to have to tell me why this VM appears to have some kind of incomplete encryption remnants.

[virtual_name]

The only thing I did was to update Windows guest and reboot. I have no idea why DEK has error. The snapshot was for easier recovery to the original Windows. The hang happened w/o snapshot as well, consistently. I did the update about 5-10 times, and all resulted to the rollback by Windows because the update failure. Tried Virutalbox 7 and had the same issue.

It sounds like Virtualbox will have issue for encrypted disk after this guest update based on this hang behavior. Do you want to see the log w/o snapshot? Thanks.

[mpack]

If you are convinced that the KB5019959 update is relevant then you should be able to start Windows in safe mode and roll it back. Myself, I don't see how an update inside the guest could possibly cause your .vbox file - stored on the host - to be modified such that the stored DEK is removed. To be plain, that makes no sense.

I'm not sure what you're offering re "log w/o snapshot". I would be very wary of doing anything with snapshots until the DEK problem has been fixed. That said, if you make a proper backup of the VM then the situation at least can't get any worse.

[virtual_name]

Just double check the log when Windows guest works correctly before the update, I also see the DEK missing message, so I guess it's just a false alarm. I feel restarting might get to this message because I don't need to type the password.
"Console: VM runtime error: fatal=false, errorID=DrvVD_DEKMISSING message="VD: The DEK for this disk is missing""

[fth0]

DEK problem

I don't see any "real" DEK problem here.

What we're seeing in the windows-2022-12-04-11-06-37.log file is the normal behavior of starting a VM with an encrypted disk image when the password has to be entered manually:

If you look at the timestamps, you can guess where the user was asked to enter the password, and the primary disk was used successfully afterwards. Additionally, you can see the KeyStore attributes in the [Devices/ahci/.../Crypt/] sections in the log file, so they were present in the corresponding .vbox file.

[mpack]

Ah, I see. I understand now.

I have no use for encrypted disks myself so I freely agree that I am not familiar with what they look like in a log.