Add VMware binary discovery and removal tools

[jamepark4]

Complete VMware Tools removal toolkit with comprehensive cleanup

Implements a complete 9-step procedure for removing VMware Tools from
Windows VMs after v2v migration to KVM/virtio. Addresses critical
vSockets conflict, driver cleanup, and empty directory removal.

• discover_vmware_binaries.ps1: Cryptographic signature verification

  • Authenticode signature checking (VMware CA validation)
  • Metadata fallback for WHQL-signed drivers
  • Scans Program Files, System32, drivers, and ProgramData
  • 14× faster than batch version (no process spawning)

• remove_vmware_binaries.ps1: Native MoveFileEx integration

  • Immediate deletion with automatic reboot scheduling for locked files
  • Path safety validation prevents system directory accidents
  • FileRepository orphan cleanup after driver unload
  • Empty directory removal per customer requirements

• uninstall_vmware_msi.ps1: Proper MSI uninstall via Windows Installer

  • Uses official VMware uninstaller for clean removal
  • Removes files, services, drivers, and registry properly

Problem: VMware vSockets and virtio-vsock both use AF_VSOCK (40).
Windows allows only one provider per address family. If VMware vSockets
remains, virtio-vsock fails to register. Simple netsh winsock remove provider silently fails.

Solution: Three-phase cleanup in remove_vmware_registry.bat

1. Delete Services\vsock from ALL ControlSets (not just CurrentControlSet)
2. Delete WinSock2 registry entries from ALL ControlSets
3. Run netsh winsock reset to rebuild catalog from cleaned registry
4. Reboot to finalize (network stack reload)

Associated scripts:

• delete_vsock_all_controlsets.ps1: Remove vsock service entries
• delete_winsock_registry.ps1: Remove vSockets from all ControlSets
• cleanup_winsock_after_registry.ps1: Winsock catalog reset with fallback
• remove_vmware_registry.bat: Orchestrates cleanup + hardcoded key removal
• remove_vmware_driver_packages.bat: Enhanced with FileRepository awareness
  • NOTE: FileRepository cleanup moved to step 6 (after driver unload)
  • Drivers must be unloaded before directories can be removed

1. binaries\uninstall_vmware_msi.ps1          → Proper MSI uninstall
2. services\remove_vmware_services.bat        → Stop/delete services
3. binaries\discover_vmware_binaries.ps1      → Catalog all files
4. drivers\remove_vmware_driver_packages.bat  → Remove from driver store
5. REBOOT #1                                   → Unload kernel drivers
6. binaries\remove_vmware_binaries.ps1        → Delete files + cleanup
7. reg\remove_vmware_registry.bat             → Registry + Winsock reset
8. REBOOT #2                                   → Complete file deletion + finalize Winsock
9. drivers\remove_ghost_devices.ps1           → Remove hidden devices

Why Two Reboots?

• REBOOT 1: Unloads kernel drivers so files can be deleted
• REBOOT 2: Completes locked file deletion + finalizes Winsock catalog reset

Identifying binaries to remove

• Primary: Check certificate Subject for O=VMware
• Secondary: Check file VersionInfo.CompanyName for "VMware"
• Handles WHQL-signed VMware drivers (signed by Microsoft but made by VMware)
• Prevents false positives: vmic*.dll, vmbus*.dll (Hyper-V, not VMware)

Windows maintains multiple ControlSets (001, 002, etc.) for boot recovery.
Cleaning only CurrentControlSet leaves VMware entries in backup sets, which
can be restored during system recovery or boot failures. Must clean ALL.

• Rejects paths containing: Windows, System32, SysWOW64, Program Files (root)
• Length validation (minimum 20 chars for safety)
• Prevents accidental C:\Windows deletion

All items from minimum_customer_cleanup_actions addressed:

• ✅ MSI uninstall, services (stop/disable/delete)
• ✅ Kernel drivers (System32\drivers\vm*.sys, vsock.sys)
• ✅ Driver packages (pnputil + FileRepository + DRVSTORE cleanup)
• ✅ Registry (VMware Inc., WOW6432Node, Services, Installer keys)
• ✅ Directories (Program Files, Common Files, ProgramData - including empty)
• ✅ System32/SysWOW64 binaries (vm3ddevapi64.dll, vmGuestLib.dll, etc.)
• ✅ Ghost devices (with OS version awareness)
• ✅ GISvc (Guest Introspection Service)

Validated on:

• Windows Server 2019 (ghost device auto-removal not supported - expected)
• Windows Server 2025 (all 14 verification checks passing)

Signed-off-by: James Parker [email protected]
Co-Authored-By: Claude Sonnet 4.5 [email protected]

[gemini-code-assist]

Code Review

This pull request introduces a comprehensive toolkit for removing VMware Tools remnants from Windows VMs after v2v migration, including scripts for service management, driver removal, registry cleanup, and binary file deletion. The code review highlights several critical improvements to ensure robustness, portability, and safety. Key feedback includes fixing registry parsing in the binary discovery script, using well-known SIDs instead of localized group names to support non-English Windows installations, replacing the slow and unsafe Win32_Product WMI query with the Windows Installer COM object, and addressing potential command injection vulnerabilities by utilizing delayed expansion for path variables.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[jamepark4]

Based on feedback, converting to draft and re-testing with recommended updates.

[kostyanf14]

One comment about vsock.
Windows does not support AF_VSOCK out of the box. So, the driver needs to register AF_VSOCK and map it to a user-mode driver (UMD).
Due to this, you can not just remove the UMD file; Windows will still think that AF_VSOCK exists. This will cause an issue with virtio-sock. So, for the VMware vSockets driver, we must: unregister AF_VSOCK and only then remove the UMD.

[jamepark4]

Thanks for highlighting this, my current procedure has been:

1. Stop VMware services (services/remove_vmware_services.bat)
2. Discovery relevant VMware binaries (binaries/discover_vmware_binares.ps1)
3. Remove drivers (drivers/remove_vmware_driver_packages.bat)
4. Reboot to unload drivers
5. Remove the discovered vmware binares (binaries/remove_vmware_binaries.ps1) Any locked binary during this process will be schedule for deletion at next reboot.
6. Clean the registry (reg/remvoe_vmware_registry.bat)
7. Reboot
8. Clean up any remaining protected files (binaries/cleanup_protected_files.ps1)
9. Remove any lingering ghost devices (binaries/remove_ghost_devices.ps1)

I will confirm if what I'm doing in step 3 is enough to ensure unregister AF_VSOCK before progressing to the binary removal.

[kostyanf14]

Can be not be enough, because UMD registration can be done independently of driver installation. Need to check. You can use virtio-sock test application to enumerate all installed socket providers and check.