This was discovered while diving into #5903 and is responsible for why customers get themselves into the #5903 scenario however this issue stands on its own and #5903 covers another problem that could possibly be encountered in other scenarios.
When the Habitat Supervisor receives a ctrl+c signal on Windows, either via a user or programatically in the windows habitat service harness, the expected behavior is that the Supervisor should immediately terminate under the default windows ctrl+c behavior and the launcher which waits for the supervisor to exit, will then properly clean things up.
It appears that the supervisor is not responding to ctrl+c. This would be fine if all services are in their
run hooks. In that case the service loop is alerted by the launcher that things are shutting down and all comes down clean. However if an init hook is in progress, the service loop is blocked and the supervisor will remain alive and the launcher will keep waiting. The windows habitat service will wait up to a minute for the launcher to exit and if it fails to do so, it will forcefully terminate the process which leaves the services PID files around and results in the unhappy #5903 scenario.
This appears to be a regression between 0.65.0 and 0.66.0.