Removing a stuck winfsp on Windows: real diagnostics, MSI failures, and forced removal

Removing a Stuck WinFsp on Windows: Real Diagnostics, MSI Failures, and Forced Removal in Practice#

During a routine maintenance window on a critical Windows server, I needed to remove WinFsp (Windows File System Proxy). What should have been a straightforward uninstallation turned into a classic infrastructure challenge: an inconsistent MSI database, protected installation directories, and DLLs locked at the kernel level by active handles.

Attempting to uninstall WinFsp as a regular user application often leads to silent failures or causes the uninstallation wizard to hang. This article provides a layered, step-by-step diagnostic process and a practical runbook for forced removal and system stabilization.

1) Component identification and MSI catalog#

The first step is to verify whether WinFsp is formally registered in the system database and retrieve its unique product identifier (GUID).

# Modern alternative using Get-CimInstance (Recommended)
Get-CimInstance -ClassName Win32_Product | Where-Object { $_.Name -like "*WinFsp*" } | Select-Object Name, Version, IdentifyingNumber

# Classic PowerShell alternative (Get-WmiObject)
Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like "*WinFsp*" } | Select-Object Name, Version, IdentifyingNumber

If the local MSI database is corrupt, standard uninstallation via msiexec /x {GUID} will fail. If the official uninstaller is unavailable, you can obtain the Microsoft Program Install and Uninstall Troubleshooter.

# Option 1: Directly download the Microsoft diagnostic utility
Invoke-WebRequest -Uri "https://support.microsoft.com/en-us/topic/fix-problems-that-block-programs-from-being-installed-or-removed-cca7d1b6-65a9-3d98-426b-e9f927e1eb4d" -OutFile "$env:USERPROFILE\Downloads\MicrosoftProgram_Install_and_Uninstall.meta.diagcab"

# Option 2: Quick installation using the Windows Package Manager (winget) - If available
winget install Microsoft.MicrosoftProgramInstallandUninstall

2) The common trap: service vs. filter driver#

A typical mistake in Windows administration is only checking active services and assuming that the software is stopped. Running:

# Query if the WinFsp Launcher service is active
sc query winfsp

And seeing that the service is inactive does not mean the filesystem hooks are gone. In the case of WinFsp, I/O locks and driver persistence are handled directly in the kernel by the filter driver.

The proper diagnostic should audit the active driver stack. Although the generic driverquery utility lists all loaded drivers on the system, the fltmc (Filter Manager Control) tool is much more precise and appropriate for DFIR auditing because it queries the filesystem filter manager directly:

# List active drivers in the Filter Manager stack (Recommended)
fltmc | findstr /i winfsp

# List general drivers loaded in active memory
driverquery /v | findstr /i winfsp

If the fltmc command returns a line corresponding to WinFsp (such as winfsp), the driver is still loaded in the Windows filesystem filter stack, intercepting low-level I/O calls. To audit all associated services and identify stopped/inoperative services related to WinFsp:

# List all services containing "WinFsp" in their name or display name
Get-Service | Where-Object { $_.Name -like "*WinFsp*" -or $_.DisplayName -like "*WinFsp*" }

# Inspect services associated with filesystem filters
Get-Service | Where-Object { $_.Name -like "*flt*" }

# List any service associated with WinFsp that is stopped on the system
Get-Service | Where-Object { $_.Name -like "*WinFsp*" -and $_.Status -ne "Running" } | Select-Object Name, Status

3) Dependencies, scheduled tasks, and Windows updates#

Before manually deleting registry keys or physical files, verify if other components or active processes depend on the WinFsp library by searching in C:/Program Files:

# Search for references to the executable or library in Program Files
Get-ChildItem "C:\Program Files" -Recurse -Filter "*.exe" -ErrorAction SilentlyContinue | Select-String -Pattern "WinFsp" -SimpleMatch

# Search for corrupted shortcuts on the host's Desktop
Get-ChildItem "$env:USERPROFILE\Desktop" -Recurse -Filter "*.lnk" -ErrorAction SilentlyContinue | Select-String -Pattern "WinFsp"

# Check for environment variables linked to WinFsp
[Environment]::GetEnvironmentVariables("Machine") | Where-Object { $_.Values -like "*WinFsp*" }

It is also important to check for active automated tasks or pending Windows Updates that might be locking the driver files:

# List scheduled tasks in the root folder (scoped to avoid performance overhead on large servers)
Get-ScheduledTask -TaskPath "\" -ErrorAction SilentlyContinue | Where-Object { $_.TaskName -like "*WinFsp*" -or $_.Actions.Execute -like "*WinFsp*" }

# Query if there are pending Windows updates requiring a reboot (requires PSWindowsUpdate module)
Get-WindowsUpdate

# Audit recent hotfix/patch history on the host
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

---

## 4) Operational safety: registry backup

**WARNING:** Modifying the Windows registry without a backup can corrupt the operating system boot process. Before deleting or altering any driver keys, export the registry keys for safety:

> [!CAUTION]
> **CRITICAL SECURITY WARNING:** Incorrectly modifying the Windows registry can cause irreparable damage to the operating system, potentially leading to boot failures (Blue Screen of Death/BSOD). Ensure you perform a proper backup as instructed and export the targeted registry keys before executing any modification.

Backup the Launcher service key#

reg export "HKLM\SYSTEM\CurrentControlSet\Services\WinFsp.Launcher" "$env:USERPROFILE\Desktop\WinFsp-backup.reg"

Safety backup of the entire services tree (recommended)#

reg export "HKLM\SYSTEM\CurrentControlSet\Services" "$env:USERPROFILE\Desktop\Services-backup.reg"

In case you need to restore the original key:#

reg import "$env:USERPROFILE\Desktop\WinFsp-backup.reg"#

---

## 5) Lock identification and physical directory deletion

Using legacy CMD commands (such as `rd /s /q`) inside a PowerShell console causes syntax errors and false access-denied warnings. The correct way to remove the [C:/Program Files (x86)/WinFsp](file:///C:/Program%20Files%20(x86)/WinFsp) directory recursively in PowerShell is:

Native PowerShell command for recursive and forced deletion#

Remove-Item "C:\Program Files (x86)\WinFsp" -Recurse -Force

If the command returns `Access Denied` even after resetting NTFS permissions and ownership (`takeown` and `icacls`):

Change folder ownership to the local Administrators group#

takeown /f "C:\Program Files (x86)\WinFsp" /r /d y

Grant Full Control permissions to the Administrators group#

icacls "C:\Program Files (x86)\WinFsp" /grant Administrators:F /t

The underlying issue is a kernel-level lock on the `winfsp-x64.dll` file.

Unlike a user-space file lock (where a standard process like `explorer.exe` or `notepad.exe` holds an active file handle and can be terminated using Task Manager or `taskkill`), a **kernel lock** occurs when a driver loaded in Ring 0 (such as the WinFsp filter driver) maintains active memory references to the binary. In this scenario, the Windows Object Manager and I/O manager strictly block any physical file deletion or modification to prevent kernel panic or system instability. This results in "Access Denied" errors, even for Administrator or `SYSTEM` accounts. To break this lock, the driver must be completely unloaded from the stack (`fltmc unload`) or the host must be booted into Safe Mode.

To identify which user-space process or service is holding additional handles that prevent the library release:

1. Obtain the Sysinternals diagnostic suite:

Download the official Sysinternals Suite#

Invoke-WebRequest -Uri "https://download.sysinternals.com/files/SysinternalsSuite.zip" -OutFile "$env:USERPROFILE\Downloads\SysinternalsSuite.zip"

Create the target directory before extraction to prevent errors#

New-Item -ItemType Directory -Path "$env:USERPROFILE\Tools\Sysinternals" -Force

Extract the suite to the created local directory#

Expand-Archive -Path "$env:USERPROFILE\Downloads\SysinternalsSuite.zip" -DestinationPath "$env:USERPROFILE\Tools\Sysinternals" -Force

2. Run the `handle64.exe` tool to map the DLL locks:

Search for active process handles pointing to the locked DLL#

cd "$env:USERPROFILE\Tools\Sysinternals" .\handle64.exe winfsp-x64.dll

If the handle is owned by `explorer.exe` or a third-party backup service, restarting that process may release the lock without requiring a full host reboot.

---

## 6) Entering safe mode

If the filter driver is locked persistently, the most reliable approach is to boot Windows into Safe Mode, preventing non-essential third-party drivers from loading:

- **Option 1 (GUI):** Run `msconfig`, go to the **Boot** tab, select **Safe boot**, click OK, and restart the host.
- **Option 2 (PowerShell):** Run the following command to boot directly to the Windows Advanced Boot Options menu:

Shutdown /r /o /t 0

- **Option 3 (Shift Restart):** Hold down the `Shift` key while clicking "Restart" in the Windows Start menu.

---

## 7) Registry purge and residue cleanup

After removing physical files, purge orphan service definitions from the registry to prevent Windows from trying to load missing binaries during boot.

Here is the recommended technical decision flow for safe uninstallation and purge:

graph TD A[Start WinFsp Uninstallation] --> B{Is MSI database healthy?} B -- No --> C[Run Microsoft Program Troubleshooter] B -- Yes --> D[Run msiexec /x {GUID}] C --> E{Is directory removal blocked?} D --> E E -- Yes --> F{Is Filter Driver active in fltmc?} E -- No --> J[Purge orphan registry keys] F -- Yes --> G[Run fltmc unload winfsp] F -- No --> H[Identify handles with handle64.exe] G --> I{Is DLL still locked?} H --> I I -- Yes --> K[Reboot into Safe Mode] I -- No --> L[Remove physical WinFsp directory] K --> L L --> J J --> M[End: System Stabilized]

Permanently delete the Launcher service key#

reg delete "HKLM\SYSTEM\CurrentControlSet\Services\WinFsp.Launcher" /f

---

## 8) Post-removal verification and event log audits

Once physical and logical removals are complete, execute final audits to verify the system is clean and monitor the boot sequence:

1. Ensure the driver is completely unloaded from the filter stack#

fltmc | findstr /i winfsp driverquery /v | findstr /i winfsp

2. Confirm the physical installation directory is gone#

Test-Path "C:\Program Files (x86)\WinFsp"

3. Verify that the registry service definition is purged#

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\WinFsp.Launcher" -ErrorAction SilentlyContinue

4. Check if any process has residual DLLs loaded in active memory#

Get-Process | Where-Object { $_.Modules.ModuleName -like "winfsp" }

Inspect the Event Viewer logs for startup warnings or errors related to WinFsp:

Filter the System log for errors containing "WinFsp"#

Get-WinEvent -LogName "System" -MaxEvents 100 -ErrorAction SilentlyContinue | Where-Object { $_.Message -like "WinFsp" } | Format-Table TimeCreated, Message -Wrap

Filter logs via wevtutil#

wevtutil qe System /f:text /c:50 /q:"*[System[Provider[@Name='Service Control Manager'] and (Level=2)]]" | findstr /i "WinFsp"

Check the Application log for related errors#

Get-WinEvent -LogName "Application" -MaxEvents 100 -ErrorAction SilentlyContinue | Where-Object { $_.Message -like "WinFsp" }

---

## Checklist: winfsp complete removal

Follow this structured roadmap to verify and purge the WinFsp driver safely.

### 1. Diagnostic phase
- [ ] Query registered installation: `wmic product`
- [ ] Inspect filter driver stack status: `fltmc` / `driverquery`
- [ ] Identify open file handles locking the DLL: `handle64.exe`

### 2. Operational safety
- [ ] Back up the services registry branch: `reg export HKLM\SYSTEM\CurrentControlSet\Services`
- [ ] Check for dependent software, shortcuts, and environment paths
- [ ] Review pending Windows updates and hotfix installation state

### 3. Purging and deletion
- [ ] Run regular uninstall or clean up GUID conflicts with the Microsoft Troubleshooter
- [ ] Stop locking processes, restart Explorer, or boot to Safe Mode
- [ ] Delete physical directory: `Remove-Item -Recurse -Force`
- [ ] Purge orphan registry service entries: `reg delete`

### 4. Verification and closing
- [ ] Confirm directory, drivers, and keys are successfully removed
- [ ] Audit Event Viewer logs for boot errors
- [ ] Document the incident and resolution steps in the internal platform runbook

See also

Infrastructure Ghost clink in CMD: forensic diagnosis and definitive removal on Windows 10

Infrastructure Anatomy of a silent deadlock in CloudLinux and cPanel: phantom processes, session locks, and TCP queues

Infrastructure Crontab kernel mechanics, Linux logging differences, and Exim mail spool maintenance

This post is licensed under CC BY-NC.