Removendo WinFsp travado no Windows: diagnóstico real, erro MSI e remoção forçada

Removendo WinFsp travado no Windows: diagnóstico real, erro MSI e remoção forçada na prática

Durante uma manutenção em servidor Windows, precisei remover o WinFsp 2025 e encontrei um cenário clássico de infra: MSI inconsistente, diretório protegido e DLL travada em nível de kernel.

Este artigo é o runbook real da correção, sem atalhos.

---

1) Contexto e identificação do componente

Primeiro passo foi validar instalação formal do produto:

wmic product where "name like '%WinFsp%'" get name, version, identifyingnumber

Resultado no incidente:

• Produto: WinFsp 2025
• Versão: 2.1.25156
• Registro via MSI confirmado

Com isso, ficou claro que a remoção ideal seria por msiexec, mas o ambiente já mostrava indício de inconsistência do instalador.

---

2) Armadilha comum: confundir serviço com driver

Rodar:

sc query winfsp

e ver “nenhum serviço ativo” não encerra análise.

No WinFsp, quem costuma manter lock em I/O é o driver de filtro. Por isso, a validação correta inclui:

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

Se o fltmc retorna entrada, o driver ainda está carregado no stack de filtros, mesmo sem serviço visível em execução.

---

3) Falha no MSI e erro de sintaxe entre CMD e PowerShell

Tentativa de desinstalação formal (msiexec /x {GUID}) falhou por estado inconsistente do MSI.

Na remoção manual, apareceu outro problema comum: comando de CMD usado em PowerShell.

• Errado no PowerShell:
• rd /s /q "C:\Program Files (x86)\WinFsp"
• Correto:

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

Essa diferença parece básica, mas em incidentes sob pressão gera perda de tempo e falsa leitura de “acesso negado”.

---

4) Causa real do bloqueio: winfsp-x64.dll com handle aberto

Mesmo com ownership ajustado e ACL correta, a exclusão seguia falhando.

Comandos usados:

takeown /f "C:\Program Files (x86)\WinFsp" /r /d y
icacls "C:\Program Files (x86)\WinFsp" /grant Administrators:F /t

Sem sucesso.

Diagnóstico final: não era NTFS permission issue, era kernel-level file lock. A DLL winfsp-x64.dll estava mapeada por processo ativo (ou shell/driver), impedindo remoção física.

---

5) Estratégias que funcionam na prática

Opção A — localizar handle sem reboot

Com Sysinternals:

.\handle64.exe winfsp-x64.dll

Se o lock estiver no explorer.exe, reiniciar o Explorer pode liberar o arquivo sem reboot completo.

Opção B — reboot estratégico

Reiniciar o host pode subir sem reanexar imediatamente o driver de terceiro, abrindo janela para exclusão.

Opção C — Modo Seguro (mais determinístico)

No Safe Mode, drivers de terceiros não essenciais normalmente não carregam. É o cenário mais limpo para remover componentes de filesystem que ficaram “zumbis”.

---

6) Limpeza de resíduos (registro e catálogo MSI)

Excluir pasta não encerra incidente. Se a definição de serviço/driver permanece, o Windows continua tentando inicializar algo que não existe.

Limpeza da chave:

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

Para limpar cadastro quebrado do MSI (quando .msi original não está mais disponível), use:

• Microsoft Program Install and Uninstall Troubleshooter

Isso remove referência inválida do produto e evita lixo persistente em inventário.

---

7) Playbook pós-incidente

Checklist que apliquei para fechar o caso:

1. validar ausência no driverquery e fltmc;
2. validar ausência de binários em C:\Program Files (x86)\WinFsp;
3. validar ausência da chave em Services\WinFsp.Launcher;
4. revisar Event Viewer para erro residual de serviço/driver no boot;
5. registrar ação no runbook interno de plataforma.

---

8) Lições de trincheira

1. Instalação ≠ execução: serviço parado não garante driver descarregado.
2. Permissão ≠ lock: icacls não resolve arquivo com handle ativo.
3. Sintaxe importa: misturar CMD e PowerShell em incidente piora MTTR.
4. Limpeza holística: remover pasta sem limpar Services deixa bomba para o próximo admin.

---

Conclusão

O caso não era “erro de desinstalação”, era componente de kernel com persistência parcial.

Tratar WinFsp como software comum leva a troubleshooting raso. Tratar como extensão de stack de filesystem leva à solução definitiva.

Este post está licenciado sob CC BY-NC.