Description

When C:\ProgramData\Servy\security\aes_key.dat was DPAPI-protected under a different machine's LocalMachine master key (e.g., the host was cloned, imaged, OS-restored, or the file was copied from another system), ProtectedKeyProvider.GetOrGenerate throws CryptographicException: The data is invalid during service construction.

Servy's own log is clear and accurate:

[ERROR] Failed to unprotect key at C:\ProgramData\Servy\security\aes_key.dat. The file may have been moved from another machine.
[ERROR] Fatal error during service construction.

But the Windows Service never signals Started, so the Service Control Manager reports only the generic:

Error 1053: The service did not respond to the start or control request in a timely fashion.

Impact

• Admins diagnosing the failure see only the 1053 in services.msc / sc.exe / Event Log — the actionable error is buried in Servy's own log file, which is typically not the first place they look.
• There is no automatic recovery. The service will fail on every start indefinitely.
• Realistic trigger: any organisation that uses image-based Windows deployment (SCCM task sequence, MDT, Ghost, VMware clone) and has Servy installed in the gold image will hit this on every cloned host.

Reproduction

1. Install Servy on machine A, start the service so aes_key.dat is created.
2. Copy C:\ProgramData\Servy\security\aes_key.dat to machine B (or image machine A to B).
3. Start the Servy service on machine B.
4. Service fails with 1053; log shows CryptographicException: The data is invalid.

Suggested fixes (pick one or combine)

1. Event Log surface — when ProtectedKeyProvider fails with "data is invalid" on LocalMachine scope, write an entry to the Windows Application Event Log (not just Servy's private log) with source Servy and a clear message including the recovery command. Admins routinely check Event Viewer for 1053; Servy's private log they don't.
2. Dedicated recovery CLI command — e.g., servy-cli.exe reset-keys (or --reset-security-keys) that deletes the security folder with a confirmation prompt. Document it next to the error message.
3. Optional auto-heal flag at install time — Install-ServyService -AutoResetStaleKey — when set, the service constructor catches CryptographicException from ProtectedKeyProvider, deletes the corrupt key, regenerates, and logs what happened. Off by default (data loss implications), on for orgs that know their config is idempotent.
4. Service exit code — if the service can't be made to succeed, at least exit with a distinctive non-zero code (e.g., a Servy-specific code) so SCM/Event Log shows something more specific than 1053.

Workaround (for anyone else hitting this)

Stop-Service <YourServyServiceName> -Force
Remove-Item 'C:\ProgramData\Servy\security' -Recurse -Force
Start-Service <YourServyServiceName>

This wipes the stale key so Servy regenerates a fresh one bound to the current machine's DPAPI master. Safe if the service config is reinstalled from source on every deploy (no persistent Servy-encrypted state).

Environment

• OS: Windows 11 Enterprise 10.0.26200
• Trigger: cloned/imaged host