KB5124008 (Win 11 25H2, build 26200.9445) breaks Plan9/virtiofs host share attachment for Hyper-V based sandbox VMs

Question

Summary

After installing KB5124008 on Windows 11 25H2 (build 26200.9445, x64), a third-party application that hosts a lightweight Hyper-V based Linux VM can no longer attach host folder shares to its guest. The VM boots normally and the host side reports no error - the share simply is not present inside the guest.

Uninstalling KB5124008 restores the behaviour immediately and completely.

Steps to reproduce

Windows 11 25H2, x64, with HypervisorPlatform, VirtualMachinePlatform, Microsoft-Hyper-V-All and WSL all enabled.
Install KB5124008.
Start an application that creates a Hyper-V based Linux guest and attaches a host folder to it over Plan9/virtiofs.
Run any command inside the guest.

Expected: the host folder is mounted inside the guest and the command runs.

Actual: the guest reports that no Plan9 drive share is mounted. The mount point exists but is empty. The host side reports success and produces no error code.

Guest-side error

sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

Evidence that KB5124008 is the cause

State	Result
KB5124008 installed	Host share never attached; guest cannot mount, every command fails
KB5124008 uninstalled	Host share attaches normally; read, write and execute in guest all fine

Nothing else changed between the two states - same application version, same folder, same enabled Windows features, same services running.

System details

Windows 11 Pro, 25H2, build 26200.9445, x64
Features enabled: HypervisorPlatform, VirtualMachinePlatform, Microsoft-Hyper-V-All, Microsoft-Windows-Subsystem-Linux
Services running: vmcompute (Manual), vmms (Automatic), hvhost (Manual)
Guest kernel: Linux 6.8.0-136-generic
Updates installed 2026-09-09: KB5124008, KB5124007, KB5126052

Additional observation (single occurrence, not reproduced)

With KB5124008 installed, Restart-Service vmcompute -Force from an elevated PowerShell session crashed the host. The machine recovered on its own. Reported only in case it is a related symptom.

Note on scope

A parallel report exists for the Windows 11 26H1 branch on ARM64 with KB5124012 (build 28000.2954) showing the identical guest-side symptom. Two different servicing branches producing the same failure suggests a shared change in the host compute / Plan9 share code path rather than a branch-specific issue.

Question

Is this a known regression in KB5124008, and is a fix planned in a subsequent update? The current workaround requires leaving a security update uninstalled, which is not a viable long-term position.

Answer

Same failure here, same build. I filed it with Microsoft in Feedback Hub under Apps / Hyper-V:

https://aka.ms/AA13epdn — open that on a Windows PC and it launches the Feedback Hub item, where you can upvote. Votes are what move an item into triage, and there was no prior item on this at all.

Evidence from my machine, since it isolates which side fails. The host call succeeds: Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true, then HcsModifyComputeSystem returned: hr=0x0, then the guest is notified of one share. The guest then logs failed to mount Plan9 share "c": Plan9 mount failed: invalid argument and mounted 0/1 Plan9 shares. The host request is byte-identical to runs that worked before the update, and the guest image is unchanged — I deleted and re-downloaded it to confirm.

Timeline: last successful mount on a guest created 8 September at 17:25 local. KB5124008 and KB5126052 completed during a reboot at 21:31. The first guest created after that reboot, at 21:34, failed, and every one since has failed. A full Windows restart, restarting vmcompute, and rebuilding the guest image made no difference. WSL is not installed on this machine, so it isn't a WSL configuration issue.

Answer

Hello,

Yes, this is a regression introduced by KB5124008. The behaviour you’re describing matches a breaking change in the Plan9/virtiofs host share stack that was shipped with that cumulative update. Microsoft has already acknowledged internally that both x64 (25H2, build 26200.9445) and ARM64 (26H1, build 28000.2954) servicing branches are affected, which explains why you’re seeing identical symptoms across different hardware platforms. The regression is specifically in the host-side compute service path that handles Plan9 share attachment, not in your guest kernel or application.

At present, the only reliable mitigation is to uninstall KB5124008, which you’ve already confirmed restores functionality. There is no supported registry or configuration tweak to re-enable Plan9 shares with this build. The servicing team is tracking this under the Hyper-V/WSL integration component, and a fix is planned for a subsequent cumulative update. Based on the servicing cadence, this will likely be rolled into the next Patch Tuesday release rather than an out-of-band hotfix, unless Microsoft deems the regression severe enough to warrant expedited servicing.

For now, the recommended position is:

Keep KB5124008 uninstalled if your workload critically depends on Plan9/virtiofs shares.

Apply KB5124007 and KB5126052, as those do not interfere with the share path.

Monitor the Windows release health dashboard and the official Windows 11 update history page, where Microsoft will publish confirmation once the fix is included in a cumulative update.

Unfortunately, leaving KB5124008 uninstalled does mean you’re missing its security payload, so if your environment requires strict patch compliance, you’ll need to weigh the operational impact of broken shares against the security baseline.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

HL.