Debugging Topshelf service that won't run under restrictive account

Question

I have a Windows service written using Topshelf. I'm trying to configure it to run using a Windows account with restricted privileges rather than using LocalSystem. That's also necessary as I'd like to connect to a database using integrated authentication.

The service works when run as LocalSystem (albeit with a database connection string containing credentials) and running the console application as my limited account (using runas) also works.

However, when I try to start the service the service control manager times out waiting for a response:

The service did not respond to the start or control request in a timely fashion.

I also get the following in the Application Popup event log:

Application Error : The exception unknown software exception (0xc06d007e) occurred in the application at location 0x77e4bef7.

The first thing that the application does is writes to a log file but it doesn't reach that when I start the service. The logging works if I run via the console.

Any suggestions what I might be missing or what I might try next?

Answer 1

Check the MSDN article Debugging windows services which describes how you debug windows services.

Answer 2

I've just started seeing this on a few of my services written in .net 2.0. They'll start fine when the server boots, but if I were to restart them throughout the day, they would not start, and give this error message.

They currently ran under a domain account which has admin rights on the box, but for kicks, I switched it to Local System, and the service started normally. I stopped it, changed it back to the domain account (reentering the password), and it started normally again as expected.

Don't know if this counts as a 'fix' so much, but that's what worked for me.

Answer 3

which version are you using?

Answer 4

This problem seems to be related to the server (a domain controller) rather than TopShelf. A service built with the .NET service component also exhibits the same behaviour.

The service runs successfully on a different machine (in the same domain).

Unfortunately this doesn't help diagnose the problem but gives me an acceptable workaround.