2

I have a windows service programmed in vb.NET, using Topshelf as Service Host. Once in a while the service doesn't start. On the event log, the SCM writes errors 7000 and 7009 (service did not respond in a timely fashion). I know this is a common issue, but I (think) I have tried everything with no result. The service only relies in WMI, and has no time-consuming operations. I read this question (Error 1053: the service did not respond to the start or control request in a timely fashion), but none of the answers worked for me.

I Tried:

  • Set topshelf's start timeout.
  • Request additional time in the first line of "OnStart" method.
  • Set a periodic timer wich request additional time to the SCM.
  • Remove TopShelf and make the service with the Visual Studio Service Template.
  • Move the initialization code and "OnStart" code to a new thread to return inmediately.
  • Build in RELEASE mode.
  • Set GeneratePublisherEvidence = false in the app.config file (per application).
  • Unchecked "Check for publisher’s certificate revocation" in the internet settings (per machine).
  • Deleted all Alternate Streams (in case some dll was marked as web and blocked).
  • Removed any "Debug code"
  • Increased Window's general service timeout to 120000ms.

Also:

  • The service doesn't try to communicate with the user's desktop in any way.
  • The UAC is disabled.
  • The Service Runs on LOCAL SYSTEM ACCOUNT.

I believe that the code of the service itself is not the problem because:

  • It has been on production for over two years.
  • Usually the service starts fine.
  • There is no exception logged in the Event Log.
  • The "On Error" options for the service dosn't get called (since the service doesn't actually fails, just doesn't respond to the SCM)
  • I've commented out almost everything on it, pursuing this error! ;-)

Any help is welcome since i'm completely out of ideas, and i've been strugling with this for over 15 days...

Michal Hosala
  • 5,570
  • 1
  • 22
  • 49
BetonUser
  • 21
  • 4

3 Answers3

2

For me the 7009 error was produced by my NET core app because I was using this construct:

var builder = new ConfigurationBuilder()
    .SetBasePath(Directory.GetCurrentDirectory())
    .AddJsonFile("appsettings.json");

and appsettings.json file obviously couldn't be found in C:\WINDOWS\system32.. anyway, changing it to Path.Combine(AppContext.BaseDirectory, "appsettings.json") solved the issue.

More general help - for Topshelf you can add custom exception handling where I finally found some meaningfull error info, unlike event viewer:

HostFactory.Run(x => {
    ...
    x.OnException(e =>
    {
        using (var fs = new StreamWriter(@"C:\log.txt"))
        {
            fs.WriteLine(e.ToString());
        }
    });
});
Michal Hosala
  • 5,570
  • 1
  • 22
  • 49
  • 1
    Been searching for hours why my service wouldn't work, thank you so much! – danny10846 Nov 13 '20 at 14:41
  • @danny10846 happy to help! Just FYI since writing my answer, there were improvements done in .NET core and native support for windows services has been added, see e.g. [here](https://codeburst.io/create-a-windows-service-app-in-net-core-3-0-5ecb29fb5ad0). As a result we stopped using Topshelf entirely, so perhaps something for you to consider in case you are on .NET core. – Michal Hosala Nov 13 '20 at 15:23
0

I've hit the 7000 and 7009 issue, which fails straight away (even though the error message says A timeout was reached (30000 milliseconds)) because of misconfiguration between TopShelf and what the service gets installed as.

The bottom line - what you pass in HostConfigurator.SetServiceName(name) needs to match exactly the SERVICE_NAME of the Windows service which gets installed.

If they don't match it'll fail straight away and you get the two event log messages.

antmeehan
  • 865
  • 9
  • 11
-1

I had this start happening to a service after Windows Creator's Edition update installed. Basically it made the whole computer slower, which is what I think triggered the problem. Even one of the Windows services had a timeout issue.

What I learned online is that the constructor for the service needs to be fast, but OnStart has more leeway with the SCM. My service had a C# wrapper and it included an InitializeComponent() that was called in the constructor. I moved that call to OnStart and the problem went away.

Joe Mattioni
  • 1
  • 1
  • Oops, sorry. After more thorough testing I found that moving initialization to OnStart causes other problems. It should stay in the constructor. – Joe Mattioni Jul 14 '17 at 19:45
  • 1
    Please delete your answer if you think it is wrong, rather than leaving a comment. – Alex Jul 17 '17 at 01:51