-
- Posts: 6
- Joined: Mon Sep 18, 2017 6:01 am
We're evaluating Viscosity as a replacement client for our current VPN. Unfortunately we're seeing an issue where the service is not starting reliably after a reboot.
Basically the Viscosity service fails to start up quickly enough and Windows 10 tells it to shut down. We've tried using the “Automatic (delayed start)” configuration for the service but by the time the service starts, the application has given up trying to connect.
It could be that this problem only happens on slow systems, where starting the service takes longer than some arbitrary OS defined timeout.
This is an issue that we've seen with our own product's Windows service, so it's very familiar. We tried all sorts of things to work around it, including changing our service to return to the OS quickly and initializing separately in a thread. None of these changes mattered. We still had reported cases of our service not starting for some users on slow systems.
In the end the only work around was to register our service so that when a client tries to access one of our named pipes, our service is notified and started. So even on slow systems where the service fails to start at boot, the first time a client tries to access our service it will get started.
Since making that change, we have no reported issues from end users of our service not starting.
It's unclear to us if any of this is relevant to your Viscosity implementation. But if it is, you might want to consider making this change in a future version.
Basically the Viscosity service fails to start up quickly enough and Windows 10 tells it to shut down. We've tried using the “Automatic (delayed start)” configuration for the service but by the time the service starts, the application has given up trying to connect.
It could be that this problem only happens on slow systems, where starting the service takes longer than some arbitrary OS defined timeout.
This is an issue that we've seen with our own product's Windows service, so it's very familiar. We tried all sorts of things to work around it, including changing our service to return to the OS quickly and initializing separately in a thread. None of these changes mattered. We still had reported cases of our service not starting for some users on slow systems.
In the end the only work around was to register our service so that when a client tries to access one of our named pipes, our service is notified and started. So even on slow systems where the service fails to start at boot, the first time a client tries to access our service it will get started.
Since making that change, we have no reported issues from end users of our service not starting.
It's unclear to us if any of this is relevant to your Viscosity implementation. But if it is, you might want to consider making this change in a future version.