v0.18.4: Critical Failure when Starting as Windows Service (Service Start Failed)

[felixxarcom]

Describe the bug
Attempting to register and start sql_exporter.exe (v0.18.4) as a Windows Service fails consistently with an operating system error (StartServiceFailed and sometimes the low-level ERROR 487), even when using the technically correct binPath syntax. The binary is unable to maintain execution in the Windows Service Control Manager (SCM) environment, leading to an immediate crash upon attempting to start. This suggests a Go binary/Windows API incompatibility rather than a configuration error.

To Reproduce
This bug occurs when attempting to load any configuration file via the Windows Service layer:

System: Windows Server (reproducible on various versions, tested on 2019/2022).

Files: Use the sql_exporter.exe binary (Version 0.18.4) and a valid config.yml.

Command: Attempt to create and start the service using the correct New-Service or sc.exe syntax:

PowerShell

$BinPath = "C:\ruta\sql_exporter.exe"
$CfgPath = "C:\ruta\config.yml"
$FullCommand = ('"{0}" --config.file="{1}"' -f $BinPath, $CfgPath)

Attempt to create using native utility

sc.exe create sql_exporter_test binPath= "$FullCommand" start= auto DisplayName= "Prometheus SQL Exporter Test"
Start-Service sql_exporter_test
Error Seen (PowerShell): Start-Service : No pudo iniciarse el servicio... (ServiceCommandException: StartServiceFailed).

Error Seen (SCM): The low-level utility sc.exe create often fails with ERROR 487: Se ha intentado tener acceso a una dirección no válida, indicating a conflict during the registration process itself.

Expected behavior
The service should register successfully and transition to a Running state, listening on its configured port (e.g., 9399), as it does when executed manually in the foreground.

Configuration
Exporter Version: 0.18.4.

OS: Windows Server.

Environment: Executed as NT AUTHORITY\SYSTEM (via SCM).

Additional context
Functional Mode: The binary works perfectly when executed manually in the console (.\sql_exporter.exe --config.file="config.yml"). This confirms the configuration file is valid.

Workaround: The only stable way to run this version in the background is by registering the command via Windows Task Scheduler (schtasks), not via New-Service or sc.exe, confirming a failure in the service control integration.

[burningalchemist]

Hey @felixxarcom, I'll have a look today and get back to you with some suggestions. 👍

[burningalchemist]

Hey @felixxarcom, so far I couldn't reproduce the issue on my available Windows machine.

The following script (which is based on yours) works fine, the server is up and running:

$BinPath = "C:\Users\admin\sqlExporter\sql_exporter.exe"
$CfgPath = "C:\Users\admin\sqlExporter\config.yml"
$FullCommand = ('"{0}" --config.file="{1}"' -f $BinPath, $CfgPath)

New-Service -Name "SqlExporter" -BinaryPathName "$fullCommand" -StartupType Automatic -DisplayName "SqlExporter"

The OS is Windows 10, though. The binary was taken from the v0.18.4 release page - sql_exporter-0.18.4.windows-amd64.zip. Could you also confirm that you're using the right binary?

On my end, I'll try to get a Windows Server 2019 evaluation copy to test it there.

[burningalchemist]

@felixxarcom, I've tested sql_exporter on a fresh Windows 2019 Server installation, and still couldn't reproduce the issue. Screenshots attached:

I currently assume that it might be something with the permissions on your end, what do you think? Also, the config.yml is expected to point at some collector file (though the collector data can be provided in the file too).

I'm happy to assist you, but so far I'd need more context or details from your side.

[felixxarcom]

Hi burningalchemist
First, thank you for all your comments

Title: Appreciation & Detailed Findings regarding v0.18.4 behavior as a Windows Service

Description:

First of all, we want to express our sincere gratitude for your work on this exporter. It is a fantastic tool that solves a critical need for us, and we really appreciate your effort in maintaining it.

We are writing this not to report that the software "doesn't work"—because the core logic is excellent—but to share a detailed timeline of specific behaviors we observed when deploying v0.18.4 on Windows Server 2019/2022. We hope these findings can help you refine the Windows integration in future releases.

Here is the forensic timeline of our deployment attempt:

1. Foreground Success (It works great!) We initially configured the exporter with a single collector file. When running the binary manually in the console (.\sql_exporter.exe ...), it worked perfectly. Metrics were scraped, and Grafana visualized the data correctly immediately. This confirmed to us that your core application logic is solid.

2. Windows Service Challenges When we moved to a production setup by registering the exact same binary and config as a Windows Service (using standard tools like sc.exe or New-Service), we encountered a StartServiceFailed error. The service refused to stay in the "Running" state within the Windows Service Control Manager (SCM).

3. The "Zombie Process" Discovery This is the most interesting finding for debugging: After the service technically "failed" to start according to Windows, we discovered that the sql_exporter.exe process was actually still running in the background (as an orphan process) and was successfully serving live metrics on port 9399.

This leads us to believe that the binary is working fine, but it might be missing the native Windows Service wrapper implementation (likely golang.org/x/sys/windows/svc) required to handshake with the SCM. As a result, Windows thinks it failed and tries to kill it, but the process persists.

4. Multi-Collector Complexity We also noticed that attempting to define multiple collector files in config.yml became unstable while in this unmanaged state, which led us to temporarily switch to a Windows Task Scheduler workaround to keep using your tool reliably.

Conclusion Thank you again for this project. We believe that adding the native Windows Service entry point code would resolve these deployment issues entirely, as the exporter logic itself is performing perfectly.

[burningalchemist]

Hey @felixxarcom, I appreciate the AI-generated response here, however it doesn't bring much clarity to help me resolve the issue.

sql_exporter already contains a package that utilises native Windows Service wrapper, and is proven to work with Service Control Manager as per the screenshots posted before (with the clean Windows Server 2019 installation). The mentioned package was added a couple of years ago and serves well to a good bunch of Windows users so far.

As an alternative, I'd suggest to check out NSSM or WinSW. That might help. Otherwise, there is nothing for me to fix or implement without any additional context or details to reproduce the issue.

Since I can't confirm it's a bug, I'll move the ticket to Discussions. I'm happy to delve into details whenever you have time to share them.