At 2:13 AM, the conversion finished. She shut down the source, powered on the VM, and the app came up without a hitch.
This time, the driver installed. The progress bar jumped from 5% to 15%.
The next conversion attempt was clean. The driver started. The clone synced block by block. At 2:13 AM, the conversion finished
Bingo. The server had Hyper-V role installed (even though no VMs were running) and Device Guard enabled via group policy. Hyper-V and VMware’s change tracking driver cannot coexist—they fight for the same virtualization primitives.
That made sense. The server was old—Windows 2008 R2 with an older Secure Boot policy and no SHA-2 code signing updates. VMware’s newer drivers used SHA-2 certificates. The OS didn't trust them. The progress bar jumped from 5% to 15%
And somewhere in a data center, another Windows box silently stopped breathing, waiting for its own 2 AM hero.
Change tracking driver wasn't the villain. It was just the messenger—alerting her to years of security hardening, feature conflicts, and certificate rot hiding beneath a simple error message. The clone synced block by block
She uninstalled Converter completely from the source machine (cleanup with Converter standalone clean-up utility ), deleted leftover VMware folders from ProgramData and AppData\Local , then reinstalled. Still broken.
She checked if the driver was even present. On the source machine, she opened C:\Windows\System32\drivers and looked for vmware-ctk.sys . Nothing. That meant Converter never installed it properly—or the OS blocked it.
Sarah remembered something from a deep-dive blog she’d read last year: Change Tracking driver issues are almost always about antivirus, stale driver remnants, or missing certificates.