To isolate the problem and understand startup behavior, I started with the simplest code: a no-op program

package main

func main() {}

and registered it as a service:

sc.exe create TestSvc binPath= "C:\Test\service.exe"

Trying to start this "service" fails immediately with the 1053 message, even for the SYSTEM account. The message is misleading, but technically correct: The service really did not respond to the request in a timely fashion. Not because a timeout was encountered, but because it exited prematurely. Lesson learned: the message can indicate a timeout, OR premature exit.

To keep the program running the simplest way possible, I start an infinite loop:

package main

func main() {
    for {}
}

This behaves as expected: it starts, hogs a CPU thread and ultimately gets killed after 30 seconds. I get a 1053 message again, this time because of the timeout. The key is: This also works with a virtual account "NT SERVICE\TestSvc".

Now I include the package, but don't actually use it. I'm only interested in its side effects.

package main

import _ "github.com/kardianos/service"

func main() {
    for {}
}

Now I get the initially described behavior: it runs with the SYSTEM account (until it times out, but that's not important here), but fails immediately with any other account.

My conclusion: The package and/or some of its dependencies have side effects that cause a premature panic when run as a non-system account, before main() is even encountered.

This is probably a symptom of golang/go/issues/44921 and would be fixed by #362. Workaround:

go get github.com/kardianos/service@804642397ef740ab10846edc26f61fd134d74379