windows 错误 1053：服务没有及时响应启动或控制请求

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

提问by deejjaayy

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

我最近继承了几个作为 Windows 服务运行的应用程序，我在为它们提供 gui（可从系统托盘中的上下文菜单访问）时遇到问题。

The reason why we need a gui for a windows service is in order to be able to re-configure the behaviour of the windows service(s) without resorting to stopping/re-starting.

我们需要 Windows 服务的 gui 的原因是为了能够重新配置 Windows 服务的行为，而无需停止/重新启动。

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

我的代码在调试模式下运行良好，并且出现了上下文菜单，并且一切正常等。

When I install the service via "installutil" using a named account (i.e., not Local System Account), the service runs fine, but doesn't display the icon in the system tray (I know this is normal behavior because I don't have the "interact with desktop" option).

当我使用命名帐户（即，不是本地系统帐户）通过“installutil”安装服务时，服务运行良好，但不会在系统托盘中显示图标（我知道这是正常行为，因为我没有有“与桌面交互”选项）。

Here is the problem though - when I choose the "LocalSystemAccount" option, and check the "interact with desktop" option, the service takes AGES to start up for no obvious reason, and I just keep getting

不过，这里是问题所在 - 当我选择“LocalSystemAccount”选项并选中“与桌面交互”选项时，该服务需要 AGES 才能无明显原因地启动，而我只是不断收到

Could not start the ... service on Local Computer.

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

无法在本地计算机上启动 ... 服务。

错误 1053：服务没有及时响应启动或控制请求。

Incidentally, I increased the windows service timeout from the default 30 seconds to 2 minutes via a registry hack (see http://support.microsoft.com/kb/824344, search for TimeoutPeriod in section 3), however the service start up still times out.

顺便说一句，我通过注册表黑客将 Windows 服务超时从默认的 30 秒增加到 2 分钟（请参阅http://support.microsoft.com/kb/824344，在第 3 节中搜索 TimeoutPeriod），但是服务仍然启动超时。

My first question is - why might the "Local System Account" login takes SOOOOO MUCH LONGER than when the service logs in with the non-LocalSystemAccount, causing the windows service time-out? what's could the difference be between these two to cause such different behavior at start up?

我的第一个问题是 - 为什么“本地系统帐户”登录需要的时间比使用非 LocalSystemAccount 登录的服务时间长得多，从而导致 Windows 服务超时？这两者之间有什么区别会在启动时导致如此不同的行为？

Secondly - taking a step back, all I'm trying to achieve, is simply a windows service that provides a gui for configuration - I'd be quite happy to run using the non-Local System Account (with named user/pwd), if I could get the service to interact with the desktop (that is, have a context menu available from the system tray). Is this possible, and if so how?

其次 - 退后一步，我想要实现的只是一个提供 gui 配置的 Windows 服务 - 我很乐意使用非本地系统帐户（使用命名用户/密码）运行，如果我可以让服务与桌面交互（也就是说，从系统托盘中提供一个上下文菜单）。这可能吗，如果可以，怎么办？

Any pointers to the above questions would be appreciated!

任何指向上述问题的指针将不胜感激！

回答by Marty

After fighting this message for days, a friend told me that you MUST use the Release build. When I InstallUtil the Debug build, it gives this message. The Release build Starts fine.

在与这条消息斗争了几天之后，一位朋友告诉我，您必须使用 Release 版本。当我 InstallUtil 调试版本时，它给出了这个消息。发布版本开始正常。

回答by mdb

If you continue down the road of trying to make your service interact with the user's desktop directly, you'll lose: even under the best of circumstances (i.e. "before Vista"), this is extremely tricky.

如果您继续尝试让您的服务直接与用户的桌面交互，您将失败：即使在最好的情况下（即“Vista 之前”），这也是非常棘手的。

Windows internally manages several window stations, each with their own desktop. The window station assigned to services running under a given account is completely different from the window station of the logged-on interactive user. Cross-window station access has always been frowned upon, as it's a security risk, but whereas previous Windows versions allowed some exceptions, these have been mostly eliminated in Vista and later operating systems.

Windows 内部管理着几个窗口站，每个窗口站都有自己的桌面。分配给在给定帐户下运行的服务的窗口站与已登录交互用户的窗口站完全不同。跨窗口站访问一直受到反对，因为它存在安全风险，但之前的 Windows 版本允许一些例外情况，但这些在 Vista 和更高版本的操作系统中已基本消除。

The most likely reason your service is hanging on startup, is because it's trying to interact with a nonexistent desktop (or assumes Explorer is running inside the system user session, which also isn't the case), or waiting for input from an invisible desktop.

您的服务在启动时挂起的最可能原因是它试图与不存在的桌面交互（或者假设 Explorer 在系统用户会话中运行，但事实并非如此），或者等待来自不可见桌面的输入.

The onlyreliable fix for these issues is to eliminate all UI code from your service, and move it to a separate executable that runs inside the interactive user session (the executable can be started using the global Startup group, for example).

解决这些问题的唯一可靠方法是从您的服务中删除所有 UI 代码，并将其移动到在交互式用户会话中运行的单独可执行文件（例如，可执行文件可以使用全局启动组启动）。

Communication between your UI code and your service can be implemented using any RPC mechanism: Named Pipes work particularly well for this purpose. If your communications needs are minimal, using application-defined Service Control Manager commandsmight also do the trick.

您的 UI 代码和您的服务之间的通信可以使用任何 RPC 机制来实现：命名管道特别适用于此目的。如果您的通信需求很小，使用应用程序定义的服务控制管理器命令也可以解决问题。

It will take some effort to achieve this separation between UI and service code: however, it's the only way to make things work reliably, and will serve you well in the future.

实现 UI 和服务代码之间的这种分离需要一些努力：但是，这是使事情可靠地工作的唯一方法，并且将来会很好地为您服务。

ADDENDUM, April 2010:Since this question remains pretty popular, here's a way to fix another common scenario that causes "service did not respond..." errors, involving .NET services that don't attempt any funny stuff like interacting with the desktop, but douse Authenticode signed assemblies: disable the verification of the Authenticode signature at load time in order to create Publisher evidence, by adding the following elements to your .exe.config file:

附录，2010 年 4 月：由于这个问题仍然很受欢迎，这里有一种方法可以解决另一个导致“服务没有响应...”错误的常见情况，涉及不尝试任何有趣的东西（例如与桌面交互）的 .NET 服务，但请使用 Authenticode 签名的程序集：通过将以下元素添加到您的 .exe.config 文件中，在加载时禁用对 Authenticode 签名的验证以创建发布者证据：

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

Publisher evidence is a little-used Code Access Security (CAS) feature: only in the unlikely event that your service actually relies on the PublisherMembershipCondition will disabling it cause issues. In all other cases, it will make the permanent or intermittent startup failures go away, by no longer requiring the runtime to do expensive certificate checks (including revocation list lookups).

发布者证据是一个很少使用的代码访问安全 (CAS) 功能：只有在您的服务实际依赖 PublisherMembershipCondition 的不太可能发生的情况下，禁用它才会导致问题。在所有其他情况下，它将不再需要运行时进行昂贵的证书检查（包括吊销列表查找），从而消除永久性或间歇性启动失败。

回答by wbennett

I faced this problem because of a missing framework on the box running my service. The box had .NET 4.0 and the service was written on top of .NET 4.5.

由于运行我的服务的机器上缺少框架，我遇到了这个问题。盒子有 .NET 4.0，服务是在 .NET 4.5 之上编写的。

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

我在盒子上安装了以下下载，重新启动，服务启动正常：http: //www.microsoft.com/en-us/download/details.aspx?id=30653

回答by Jacob

To debug the startup of your service, add the following to the top of the OnStart()method of your service:

要调试服务的启动，请将以下内容添加到OnStart()服务方法的顶部：

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

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

这将停止服务，直到您使用调试 -> 附加到进程手动附加 Visual Studio 调试器...

Note:In general, if you need a user to interact with your service, it is better to split the GUI components into a separate Windows application that runs when the user logs in. You then use something like named pipes or some other form of IPC to establish communication between the GUI app and your service. This is in fact the onlyway that this is possible in Windows Vista.

注意：一般来说，如果您需要用户与您的服务进行交互，最好将 GUI 组件拆分为一个单独的 Windows 应用程序，该应用程序在用户登录时运行。然后您可以使用诸如命名管道或某种其他形式的 IPC在 GUI 应用程序和您的服务之间建立通信。事实上，这是在 Windows Vista 中实现这一点的唯一方法。

回答by Eranna

In service class within OnStart method don't do huge operation, OS expect short amount of time to run service, run your method using thread start:

在 OnStart 方法中的服务类中不要做大量操作，操作系统期望运行服务的时间很短，使用线程启动运行您的方法：

protected override void OnStart(string[] args)
{
    Thread t = new Thead(new ThreadStart(MethodName)); // e.g.
    t.Start();
}

回答by Mihai Limb??an

I'm shooting blind here, but I've very often found that long delays in service startups are directly or indirectly caused by network function timeouts, often when attemting to contact a domain controller when looking up account SIDs - which happens very often indirectly via GetMachineAccountSid()whether you realize it or not, since that function is called by the RPC subsystem.

我在这里盲目射击，但我经常发现服务启动的长时间延迟是由网络功能超时直接或间接引起的，通常是在查找帐户 SID 时尝试联系域控制器时 - 这经常通过间接发生GetMachineAccountSid()不管你是否意识到，因为该函数是由 RPC 子系统调用的。

For an example on how to debug in such situations, see The Case of the Process Startup Delayson Mark Russinovich's blog.

有关如何在这种情况下进行调试的示例，请参阅Mark Russinovich 博客上的进程启动延迟案例。

回答by Bulu

If you are using Debug code as below in your service the problem may arise.

如果您在服务中使用如下调试代码，则可能会出现问题。

#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 build your windows service remove #if condition because it didn't work as it is.

要解决此问题，请在构建 Windows 服务时删除 #if 条件，因为它无法正常工作。

Please use argument for debug mode instead as below.

请使用调试模式的参数代替，如下所示。

if (args != null && args.Length > 0)
{
_isDebug = args[0].ToLower().Contains("debug");
}

回答by Masoud

In my case the problem was missing version of .net framework.

在我的情况下，问题是缺少.net framework.

My service used

我的服务使用

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

But .net Frameworkversion of server was 4, so by changing 4.5 to 4 the problem fixed:

但是.net Framework服务器的版本是 4，所以通过将 4.5 更改为 4，问题解决了：

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

回答by Alexis La Joie

I was running into a similar problem with a Service I was writing. It worked fine then one day I started getting the timeout on Start errors. It happened in one &/or both Release and Debug depending on what was going on. I had instantiated an EventLogger from System.Diagnostics, but whatever error I was seeing must have been happening before the Logger was able to write...

我正在编写的服务遇到了类似的问题。它工作正常，然后有一天我开始因启动错误而超时。它发生在一个和/或两个发布和调试中，具体取决于发生了什么。我已经从 System.Diagnostics 实例化了一个 EventLogger，但是我看到的任何错误都必须在 Logger 能够写入之前发生......

If you are not aware of where to look up the EventLogs, in VS you can go to your machine under the Server Explorer. I started poking around in some of the other EventLogs besides those for my Service. Under Application - .NETRuntime I found the Error logs pertinent to the error on startup. Basically, there were some exceptions in my service's constructor (one turned out to be an exception in the EventLog instance setup - which explained why I could not see any logs in my Service EventLog). On a previous build apparently there had been other errors (which had caused me to make the changes leading to the error in the EventLog set up).

如果您不知道在何处查找 EventLog，则可以在 VS 中转到服务器资源管理器下的计算机。除了那些用于我的服务的事件日志之外，我开始在其他一些事件日志中四处寻找。在 Application - .NETRuntime 下，我发现了与启动错误相关的错误日志。基本上，我的服务的构造函数中有一些异常（其中一个是 EventLog 实例设置中的异常 - 这解释了为什么我在 Service EventLog 中看不到任何日志）。在以前的构建中，显然还有其他错误（这导致我进行了导致 EventLog 设置错误的更改）。

Long story short - the reason for the timeout may be due to various exceptions/errors, but using the Runtime EventLogs may just help you figure out what is going on (especially in the instances where one build works but another doesn't).

长话短说 - 超时的原因可能是由于各种异常/错误，但使用运行时事件日志可能只是帮助您弄清楚发生了什么（尤其是在一个构建有效但另一个构建无效的情况下）。

Hope this helps!

希望这可以帮助！

回答by goamn

I had this problem, it took about a day to fix. For me the problem was that my code skipped the "main content" and effectively ran a couple of lines then finished. And this caused the error for me. It is a C# console application which installs a Windows Service, as soon as it tried to run it with the ServiceController (sc.Run() ) then it would give this error for me.

我遇到了这个问题，花了大约一天的时间来解决。对我来说，问题是我的代码跳过了“主要内容”并有效地运行了几行然后完成。这导致了我的错误。这是一个安装 Windows 服务的 C# 控制台应用程序，一旦它尝试使用 ServiceController (sc.Run() ) 运行它，它就会给我这个错误。

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

在我修复代码以转到主要内容后，它将运行预期的代码：

ServiceBase.Run(new ServiceHost());

ServiceBase.Run(new ServiceHost());

Then it stopped showing up.

然后它就不再出现了。

As lots of people have already said, the error could be anything, and the solutions people provide may or may not solve it. If they don't solve it (like the Release instead of Debug, adding generatePublisherEvidence=false into your config, etc), then chances are that the problem is with your own code.

正如很多人已经说过的那样，错误可能是任何事情，人们提供的解决方案可能会也可能不会解决它。如果他们不解决它（例如 Release 而不是 Debug，将 generatePublisherEvidence=false 添加到您的配置中等），那么问题很可能出在您自己的代码上。

Try and get your code to run without using sc.Run() (i.e. make the code run that sc.Run() would have executed).

尝试让您的代码在不使用 sc.Run() 的情况下运行（即让 sc.Run() 执行的代码运行）。