Error 1053: the service did not respond to a start or control request in a timely manner

I recently inherited a couple of applications that run as Windows services, and I'm having problems providing gui (accessible from the context menu in the system tray) with both of them.

The reason we need gui for a Windows service is to be able to reconfigure the behavior of the Windows services (s) without resorting to stopping / restarting.

My code works fine in debug mode, and I get a context menu, and everything behaves correctly, etc.

When I install the service through "installutil" using a named account (that is, not a local system account), the service works fine, but does not display an icon on the taskbar (I know that this is normal behavior because I donโ€™t have the option " interact with the desktop ").

Here's the problem: if I select the "LocalSystemAccount" option and check the "interact with the desktop" option, the service starts AGES to start without any obvious reason, and I just keep getting

Failed to start the service ... on the local computer.

Error 1053: The service did not respond to a start or control request in a timely manner.

By the way, I increased the default Windows service timeout from 30 seconds to 2 minutes through a registry hacker (see http://support.microsoft.com/kb/824344 , search for TimeoutPeriod in section 3), however, the service still does not start works.

My first question is: why does the โ€œLocal System Accountโ€ account accept SOOOOO MUCH LONGER than when the service logs in with a non-LocalSystemAccount, causing a Windows service timeout? what's the difference between the two to cause this behavior at startup?

Secondly - taking a step back, all I'm trying to achieve is just a Windows service that provides gui for configuration - I would be very happy to start using a non-Local System Account (named user / pwd) if I could make the service interact with the desktop (that is, have a context menu available in the system tray). Is this possible, and if so, how?

Any pointers to the above questions would be appreciated!

+48
windows timeout error-handling windows-services
01 Oct '08 at 16:06
source share
29 answers

After a long battle with this message, a friend told me that you MUST use the Release build. When I install the Debug assembly, it gives this message. Build assembly Starts fine.

+55
Sep 30 '11 at 14:12
source share

If you continue along the path so that your service interacts with the user desktop directly, you will lose: even in the most favorable circumstances (that is, "before Vista"), it is very difficult.

Windows internally manages multiple windows each with its own desktop. The window station assigned to services running under this account is completely different from the window station of an interactive user registered online. Access to firewalls has always been disapproved, as it was a security risk, but while previous versions of Windows allowed some exceptions, they were mostly fixed in Vista and later operating systems.

The most likely reason your service freezes at startup is because it tries to interact with a non-existent desktop (or assumes that Explorer is working inside a system user session, which is also not the case) or expects input from an invisible desktop.

A reliable fix only for these problems is to remove all the user interface code from your service and transfer it to a separate executable file that runs inside an interactive user session (the executable file can be launched using the global For example, launch group).

The connection between your user interface code and your service can be implemented using any RPC mechanism: Named pipes work especially well for this purpose. If your communication needs are minimal, using the applications defined by the service control manager teams can do the trick too.

This will require some effort to achieve this separation between the user interface and utility code: however, this is the only way to do the job reliably and well will serve you in the future.

ADDENDUM, April 2010: Since this question remains quite popular, here you can fix another common scenario that causes "services do not respond ..." errors, including .NET services, t try to do something funny, for example, to interact with a worker table, but do use Authenticode-signed assemblies: disable Authenticode signature verification at boot time to create publisher evidence by adding the following elements to the .exe.config file:

<configuration> <runtime> <generatePublisherEvidence enabled="false"/> </runtime> </configuration> 

Publisher certification is an underused Code Access Security (CAS) feature: only in the unlikely event that your service really relies on PublisherMembershipCondition will it disable it, causing problems. In all other cases, this will cause persistent or intermittent startup crashes to disappear, no longer requiring the runtime to perform costly certificate checks (including list search).

+28
01 Oct '08 at 16:36
source share

I ran into this problem due to the lack of a framework in the box that my service runs on. The box was .NET 4.0, and the service was written on top of .NET 4.5.

I installed the following download on the box, restarted, and the service started normally: http://www.microsoft.com/en-us/download/details.aspx?id=30653

+14
Sep 20 '13 at 20:39 on
source share

To debug the start of your service, add the following to the beginning of the OnStart() method of your service:

  while(!System.Diagnostics.Debugger.IsAttached) Thread.Sleep(100); 

This will stop the service until you manually attach the Visual Studio debugger using Debug -> Attach to Process ...

Note. In general, if you want the user to interact with your service, it is better to separate the GUI components into a separate Windows application, which starts when the user logs in. Then you use something like named pipes or some other form of IPC to establish a connection between the GUI and your service. This is actually the only way that is possible in Windows Vista.

+12
01 Oct '08 at 17:00
source share

I shoot the blind here, but I often found that long delays in starting the service are directly or indirectly caused by timeouts of network functions, often when connecting to a domain controller when searching for account SIDs - which happens very often indirectly through GetMachineAccountSid() , do you understand it or not, because this function is called by the RPC subsystem.

For an example of how to debug in such situations, see the Case of Delays in Starting a Process on Mark Russinovich's Blog.

+5
01 Oct. '08 at 16:14
source share

In the service class inside the OnStart method, a lot of work is not done, the operating system expects a short time to start the service, starts your method by starting the thread:

 protected override void OnStart(string[] args) { Thread t = new Thead(new ThreadStart(MethodName)); // egtStart(); } 
+5
Mar 17 '11 at 11:08
source share

If you use the debug code as shown below, a problem may occur in your service.

 #if(!DEBUG) ServiceBase[] ServicesToRun; ServicesToRun = new ServiceBase[] { new EmailService() }; ServiceBase.Run(ServicesToRun); #else //direct call function what you need to run #endif 

To fix this, while you are creating your Windows service, remove the #if condition because it does not work as it is.

Instead, use the debug mode argument as shown below.

 if (args != null && args.Length > 0) { _isDebug = args[0].ToLower().Contains("debug"); } 
+4
Nov 24 '14 at 10:38
source share

Install the service debugging construct and attach the debugger to the service to see what happens.

+2
01 Oct '08 at 16:13
source share

I want to write mdb comments here. Do not go this way. Your service should not have a user interface ... "No user interaction" is like the defining function of the service.

If you need to configure your service, write another application that edits the same configuration as the service at startup. But make it a great tool - when you want to start a service, you start the service. When you want to configure it, you will run the configuration tool.

Now, if you need real-time monitoring of a service, then this is a little more complicated (and, of course, something that I wanted with the services). Now you are talking about the need to use interprocess communications and other headaches.

Worst of all, if you need user interaction, then you have a real disconnect here, because services do not interact with the user.

In your shoes, I would step back and ask why this should be a favor ? And why is user interaction required ?

These two requirements are quite incompatible, and this should be alarming.

+2
01 Oct '08 at 18:17
source share

Copy the DLL version of the release or call the dll from the release mode, and not into the debug mode, and paste it into the installation folder, it should work

+2
Feb 22 2018-11-22T00:
source share

I had this problem and it made me dunk for two days ... If your problem is similar to mine:

I have User Preferences settings in my Windows service, so the service can perform self-service without stopping or starting the service. The problem is the "user settings", where the configuration file for these parameters is saved in a folder under the user profile of the user who starts the Windows service in the version of the service-exe file.

This folder has been damaged for some reason. I deleted the folder and the service started working happily again, as usual ...

+2
Mar 04 '11 at 21:45
source share

I had a similar problem with the service I was writing. It worked great, and one day I started getting a timeout on Start errors. This happened in one and / or release and debugging depending on what happens. I created an EventLogger instance from System.Diagnostics, but any error I saw had to happen before Logger could write ...

If you do not know where to look for EventLogs, in VS you can go to your computer in Server Explorer. I began to delve into some other EventLogs, besides the ones that were for my Service. In the Application -.NETRuntime section, I found error logs related to a startup error. Basically, there were some exceptions in my service constructor (one of them turned out to be an exception in setting up an EventLog instance, which explained why I did not see any logs in my Service EventLog). According to the previous build, there were apparently other errors (which forced me to make changes that led to an error in the EventLog configuration).

In short, the cause of the timeout can be caused by various exceptions / errors, but using EventLogs Runtime can help you understand what is happening (especially in cases where one assembly works and another does not work).

Hope this helps!

+2
Aug 16 '13 at 18:16
source share

I had this problem, it took about a day to fix it. For me, the problem was that my code skipped the "main content" and effectively completed a couple of lines, then finished. And that caused an error for me. This is a C # console application that installs a Windows service as soon as it tries to start it using ServiceController (sc.Run ()), then it will give me this error.

After I fixed the code to go to the main content, it would run the intended code:

ServiceBase.Run(new ServiceHost());

Then he stopped appearing.

As many people have already said, there can be any mistake, and the proposed solutions may or may not solve it. If they do not solve the problem (for example, Release instead of Debug, adding generatePublisherEvidence = false to your configuration) and most likely the problem is related to your own code.

Try running your code without using sc.Run () (i.e., run sc.Run () code).

+2
May 01 '14 at 22:13
source share

This problem usually occurs when there is some kind of link on your assembly and, as a rule, the crash does not execute at runtime.

for debugging put Thread.Sleep(1000) in main() . and place the breakpoint on the next line of execution.

Then start the process and attach the debugger to the process while it starts. Press f5 after it reaches the breakpoint. This eliminates the exception of a failure or link.

Hope this solves this error.

+2
Jul 28 '14 at 3:07
source share

In my case, the problem was missing from the .net framework version.

Used my service

 <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" /> </startup> 

But the .net framework version of the server was 4, therefore, by changing 4.5-4, the problem was fixed:

 <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" /> </startup> 
+1
Jul 11 '15 at 4:39 on
source share

I also had this problem. I made it work by changing the Logon account to Local System Account. In my project, I had a setting to work as a Local Service account. So when I installed it, by default it used Local Service. I am using .net 2.0 and VS 2005. Therefore, installing .net 1.1 SP1 would not help.

0
03 mar. '09 at 20:10
source share

Both the local system account and the local service will not work for me, and then install it in the network service, and this worked fine.

0
Jul 20 '09 at 13:33
source share

In my case, I had this problem due to a genuine error. Before calling the service constructor, one static member variable constructor fails:

  private static OracleCommand cmd; static SchedTasks() { try { cmd = new OracleCommand("select * from change_notification"); } catch (Exception e) { Log(e.Message); // "The provider is not compatible with the version of Oracle client" } } 

By adding a try-catch block, I found that the exception was due to the wrong version of oracle. Installing the correct database solved the problem.

0
Feb 21 '11 at 2:52
source share

I also ran into a similar problem and found that there was a problem loading assemblies. I immediately got this error while trying to start the service.

To quickly debug the problem, try running the utility executable on the command line using ProcDump http://technet.microsoft.com/en-us/sysinternals/dd996900 . He should give a sufficient hint of exact errors.

http://bytes.com/topic/net/answers/637227-1053-error-trying-start-my-net-windows-service helped me a lot.

0
Sep 28 '12 at 7:20
source share

Adding 127.0.0.1 crl.microsoft.com to the Hosts file solved our problem.

0
Jan 15 '13 at 13:32
source share

It worked for me. Basically make sure the Log on user is set to the right. However, this depends on how the account infrastructure is configured. In my example, it uses the user credentials of the AD account.

In the search window, in the search menu, find "Services", -Investments will find the required service, right-click and select the "Login" tab -Select "This account" and enter the required content / credentials -Open it and start the service as usual .

enter image description here

0
Mar 23 '16 at 10:26
source share

If you have a window form used for testing, make sure that the startup object is still a service, not a window form

0
Apr 04 '16 at 15:10
source share

We have Log4Net configured to write to the database table. The table became so large that the timing service tried to log messages.

0
Jun 15 '16 at 17:48
source share

open the services window as an administrator, then try to start the service. It worked for me.

0
Aug 22 '16 at 4:47
source share

Try to run the exe file. I had the same problem, but when I launched it directly by double-clicking the exe file, I received a message about the version of .Net framework because a service project with a framework that it was not installed on the target machine was released.

0
Sep 04 '16 at 18:35
source share

Assembly for assembly did not work for me, however I looked at the event log and application log and saw that the Windows service throws a security exception when I tried to create an event log. I fixed this by adding the event source manually with administrator access.

I followed this guide from Microsoft:

  • open registry editor, run โ†’ regedit
  • Locate the following registry subkey: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Eventlog \ Application
  • Right-click the Application subkey, select New, and then click Key.
  • Enter the event source name used by your Windows service for the key name.
  • Close Registry Editor.
0
Mar 21 '17 at 14:40
source share

enter image description here

Took me for hours, should have seen the event viewer get_AppSettings () .

An application configuration change caused a problem.

0
Aug 10 '17 at 7:47 on
source share

My problem related to the target structure mentioned in the windows service configuration was

 <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6"/> </startup> 

and my server on which I tried to install the Windows service was not supported for this version of .Net.

By changing this, I was able to solve the problem.

0
Oct 26 '17 at 12:57 on
source share
  • Build a project in release mode.
  • Copy all release folder files to the source path.
  • Run the window service using a command prompt window in administrator access.
  • Never delete files from the source path.

For rent it works for me.

-one
Aug 25 '16 at 8:19
source share



All Articles