Claude Cowork Issue - vfpext driver file missing from System32\drivers despite Hyper-V fully enabled (Windows 10 Pro)

Question

Subject: vfpext driver file missing from System32\drivers despite Hyper-V fully enabled (Windows 10 Pro)

OS: Windows 10 Pro

Build: 10.0.26200.8655 (confirmed via DISM output)

Issue:

The Hyper-V VFP switch extension driver (vfpext.sys) is missing from C:\Windows\System32\drivers, even though Hyper-V and all its sub-features are enabled and the driver file is present in the WinSxS component store. This is preventing a third-party application (Claude Desktop's "Cowork" feature) from functioning, as it depends on the full Hyper-V Host Compute Service stack (HNS, vmcompute, vfpext).

Symptoms:

• Get-Service vfpext returns: "Cannot find any service with service name 'vfpext'"
• Test-Path "C:\Windows\System32\drivers\vfpext.sys" returns False
• HNS and vmcompute services ARE present and running normally

Confirmed present in component store:

Get-ChildItem -Path "C:\Windows\WinSxS" -Recurse -Filter "vfpext.sys" returns multiple valid entries, including a recent one:

C:\Windows\WinSxS\amd64_microsoft-windows-hyper-v-vfpext_31bf3856ad364e35_10.0.26100.8521_none_9c6e9b959bce5329\vfpext.sys (dated 6/9/2026)

So the driver payload exists but is not being deployed to the live system.

Steps already taken (all unsuccessful):

1. Confirmed Windows 10 Pro edition (supports full Hyper-V)
2. Enabled Microsoft-Hyper-V feature via PowerShell: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
3. Restarted computer
4. Confirmed all Hyper-V sub-features show State: Enabled via Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V* (including Microsoft-Hyper-V-Services, which should provide vfpext)
5. Ran DISM /Online /Cleanup-Image /RestoreHealth — completed successfully, no effect
6. Ran sfc /scannow — found and repaired corrupt files, restarted computer, no effect on vfpext
7. Re-checked Test-Path and Get-Service vfpext after each restart — still missing

Request:

Please advise on how to properly re-register or force deployment of the vfpext driver from the component store, or let me know if this is a known servicing-level issue with a specific fix. Happy to provide additional logs (CBS.log, DISM logs) if helpful.

Answer 1

Thanks for the detailed pointers. Here's what I found:

Get-VMSwitchExtension -VMSwitchName * shows only 2 extensions on the Default Switch (Microsoft Windows Filtering Platform, Microsoft NDIS Capture) — the "Microsoft Windows VFP Forwarding Extension" is missing entirely.

pnputil /enum-drivers | findstr /i vfp returns completely empty — no VFP driver package is present in the driver store at all.

Get-ComputerInfo shows WindowsVersion 2009, OsBuildNumber 26200.

So it looks like this isn't a file-deployment issue but that the VFP component itself was never installed/registered on this system, despite Hyper-V and its listed sub-features all showing "Enabled." Any idea how to force this specific component to install, or whether there's a package I need to add manually?

Answer 2

This does not look like a simple file deployment problem.

vfpext.sys is not a standalone kernel driver service that you can normally query with Get-Service vfpext. The Virtual Filtering Platform (VFP) extension is part of the Hyper-V virtual switch networking stack and is typically bound through Hyper-V networking components rather than exposed as a conventional Windows service. Therefore, Get-Service vfpext returning "service not found" is not, by itself, evidence of a broken Hyper-V installation.

The more important detail is that you are running Windows 10 Pro build 10.0.26200.8655 while the WinSxS payload you found belongs to the 26100 component baseline. A successful DISM /RestoreHealth and sfc /scannow indicate that the component store is considered healthy and Windows does not currently believe vfpext.sys should be materialized in C:\Windows\System32\drivers. In modern Windows builds, not every binary present in WinSxS is deployed to the live driver directory unless the corresponding component, driver package, or network binding is actually staged and installed.

The first thing I would check is whether the Hyper-V Virtual Switch Extension is registered at all:

Get-VMSwitchExtension

Get-VMSwitchExtension -VMSwitchName *

and whether the driver package exists in the driver store:

pnputil /enum-drivers | findstr /i vfp

If VFP is absent from both, this points to a servicing/package registration issue rather than a missing file copy operation.

Because HNS and vmcompute are running normally, this is unlikely to be a general Hyper-V failure. It may instead be an application assumption that vfpext.sys must physically exist in System32\drivers, which is not guaranteed on newer builds. Before attempting manual file copies from WinSxS (not recommended), I would collect Get-VMSwitchExtension, pnputil /enum-drivers, and Get-ComputerInfo | Select WindowsVersion, OsBuildNumber output to determine whether the VFP component is actually installed or whether the third-party application is performing an outdated detection check.