Troubleshooting

Table of Contents

1. Introduction
2. Blank Screen on Remote Management Tools
3. Service Won't Start
4. "Access Denied" Errors
5. Logs Not Appearing
6. Health Checks Failing Too Soon
7. Process Starts but Exits Immediately
8. Service Installed but Not Visible in Windows Services
9. Service Won't Uninstall
10. High CPU or Memory Usage
11. Changes Not Applying After Updating Configuration
12. Service Using a Domain Account Does Not Start After Reboot
13. Servy "Check for Updates..." Not Working on Windows 7

Introduction

This page lists the most common issues people run into when using Servy, along with practical fixes. Start here when something is not working as expected; the solution may already be covered below.

Most problems fall into a few categories: permissions, startup configuration, health checks, log capture, or Windows policy settings. Use the sections below to narrow the issue quickly before making changes.

Blank Screen on Remote Management Tools

If you get a blank screen on remote management tools (like MeshCentral, TeamViewer, or AnyDesk), run the desktop app from an admin command prompt with the following command:

Servy.exe --force-sr

And the Manager app with the following command:

Servy.Manager.exe --force-sr

Service Won't Start

This is one of the most common problems when wrapping an app as a Windows service.

Possible causes & fixes:

• Access Denied / Permissions Issue: If the service runs under an account other than LocalSystem, check the Servy log: since v10.2, Servy hardens the vault for the account automatically when the service is installed, which gives the account write access to the log folder of its own services (logs\services\<ServiceName>\) and read access to the binaries and configuration files it needs, and logs why if that did not succeed. Fix the cause and install the service again to re-apply it. On Servy 10.1 and earlier, run Set-ServyExePermissions.ps1 -TargetAccount "domain\user" from an elevated PowerShell session (see Servy 10.1 and Earlier). See Executable Permission Hardening.
• Missing working directory: Many apps (Node.js, Python, .NET, Java…) rely on relative paths. Real case: A user had a Node app that read ./config.json. It worked manually but failed as a service because Servy launched it from C:\Program Files\nodejs\. Setting the working directory fixed it.
• File not found or missing dependencies: Ensure all DLLs, configs or runtimes exist where your app expects them. Example: .NET apps missing runtime dependencies will silently fail.
• App crashes instantly: Open Servy Manager: Logs, check the rotating log files, or check %ProgramData%\Servy\logs\services\<ServiceName>\Servy.Service.log. You'll usually see the exception there.
• App crashes with Console/UI handle errors: If your app tries to visually update the command prompt (like clearing the screen or moving the cursor), it will crash when running as a background service since services don't have visible windows. To fix this without changing your code, enable the --enableConsoleUI option in the service configuration when installing your service.
• Environment variables missing: If your app relies on variables like PATH, NODE_ENV, ASPNETCORE_ENVIRONMENT, etc., define them in the service config.

"Access Denied" Errors

These issues typically happen when Windows blocks something.

Possible causes & fixes:

• Servy not running as Administrator: Some operations (installing a service, binding ports <1024, writing to protected locations) require elevation.
• Logs or working directory located in a protected folder: Real case: Writing logs to C:\Program Files\MyApp\logs caused access issues. Fix: Use a writable path like C:\ServyData\logs or adjust permissions.
• The wrapped app itself needs admin rights: Example: Apps that manage firewall rules or interact with drivers.

Logs Not Appearing

If your stdout/stderr logs are empty while Servy is running, your app's output isn't being captured.

Possible causes & fixes:

• Log directory read-only or blocked by antivirus: Real case: Windows Defender blocked file writes for an EXE that looked "suspicious." Adding an exclusion fixed it.
• Unbuffered stdout/stderr output: Some apps buffer logs until the process ends. Fix: Enable unbuffered output or add explicit flush calls.
• App logs directly to its own file: Check your internal application logging settings to ensure output is written to stdout/stderr.
• Console UI mode is enabled (--enableConsoleUI): stdout/stderr redirection is intentionally disabled when Console UI is on. Disable --enableConsoleUI if you need Servy to capture the app's output to the configured log files.

Health Checks Failing Too Soon

This happens when Servy thinks the app is unhealthy even though it's slow to start or performs heavy initialization.

Possible causes & fixes:

• Wrapped process exiting on startup: Servy's heartbeat checks whether the wrapped process is still running, not an HTTP health endpoint. If the heartbeat trips, it almost always means the process crashed or exited. Check stdout/stderr logs for the actual error.
• Startup time exceeds initialization window: Default is 30s × 3 = 90s before recovery fires. If your app needs longer, increase HeartbeatInterval or MaxFailedChecks.
• Slow warm-up or initialization: If your app fails to come up within the heartbeat budget because of a heavy initialization step (loading ML models, opening a SQL connection pool, etc.), move that step to a Pre-Launch hook so it completes BEFORE the main process is considered started.

Process Starts but Exits Immediately

Possible causes & fixes:

• App expects user interaction: GUI apps or apps that open a console window will quit instantly when run headless.
• Missing dependencies or runtime errors: Check logs for missing DLLs, config errors, or runtime mismatches.
• Bad command-line arguments: Incorrect flags or environment-specific paths can cause instant termination.

Service Installed but Not Visible in Windows Services

Possible causes & fixes:

• Elevation context mismatch: Installing a service as admin in one user session, then checking Services under a restricted user showed nothing.
• Outdated view: Refresh the list or reopen services.msc.
• Name collision: Ensure the service name doesn't conflict with an existing Windows service.

Service Won't Uninstall

Possible causes & fixes:

• Active process locks: Another tool (Task Manager, monitoring agent, antivirus) might still be holding a handle to the process. Stop the service manually first.
• Insufficient privileges: Run Servy Manager in administrator mode.
• Service marked for deletion: Check if Windows marked the service for deletion; if so, a reboot is required before it can be reinstalled.

High CPU or Memory Usage

Possible causes & fixes:

• Unexpected background behavior: Your app might behave differently as a background service (e.g., relative paths may cause it to load or write huge data files).
• Missing working directory setting: Use the correct working directory to prevent accidental file creation in system folders.

Changes Not Applying After Updating Configuration

Possible causes & fixes:

• Pending service restart: Restarting the Windows service is required for config changes to take effect.
• Cached application configs: Some apps read config only at startup.
• Syntax or validation errors: Ensure there are no trailing commas, broken JSON, or duplicated fields in your config file.

Service Using a Domain Account Does Not Start After Reboot

If a service configured to run under a domain account starts successfully after installation but fails to start following a server reboot, the most common cause is that the account has lost the "Log on as a service" right.

During service installation, Servy grants this right locally to the specified account. However, if a Domain Group Policy defines the "Log on as a service" setting, it overrides the local configuration during startup or Group Policy refresh. After the reboot, the domain policy replaces the local assignment, the account no longer has the required permission, and Windows prevents the service from starting.

To resolve this issue, add the service account to the "Log on as a service" policy at the domain level. Open the Group Policy Management Console by running gpmc.msc, edit the appropriate Group Policy Object that applies to the target server, then navigate to Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment, and select Log on as a service. Add the domain service account to the list and apply the changes. Run gpupdate /force on the server or wait for the next policy refresh cycle, and reboot if necessary.

If the server is not joined to a domain, you can configure the setting locally using secpol.msc and navigating to the same User Rights Assignment location.

When this issue occurs, Windows records the failure in Event Viewer (eventvwr.msc) under Windows Logs, System, with the source set to Service Control Manager. The log entry typically states that the service could not log on because the user does not have the requested logon type on the computer. This confirms that the issue is related to Windows security policy rather than Servy itself.

Also, check the Servy log for the automatic hardening of the domain account (v10.2+); it is what gives the account write access to the log folder of its own services under %ProgramData%\Servy\logs\services\ and read access to the binaries and configuration files it needs. See Executable Permission Hardening.

Servy "Check for Updates..." Not Working on Windows 7

Windows 7 (especially without updates) does not enable TLS 1.2 by default. That's the root cause.

To fix this, create a file named enable-tls12-win7.reg and run it as Administrator:

Windows Registry Editor Version 5.00

; WinHTTP TLS 1.2
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000a00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000a00

; SCHANNEL TLS 1.2 client
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

; .NET strong crypto
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
"SystemDefaultTlsVersions"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
"SystemDefaultTlsVersions"=dword:00000001

Then reboot your machine.