我有一些慢速嵌入式PC运行Windows 2000并且无法可靠地启动服务。发出命令'net start xxx'和消息'xxx service is starting'之间有一个非常明显的延迟。这导致我的服务无法启动。
我的服务经常无法收到“开始”命令（我正在记录这个并且可以看到它永远不会发生）。
我试图在一个更快的XP盒子上重复这个，但延迟当然要短得多。然而我故意在我的Onstart处理程序中添加一个睡眠（60000） - 以模拟一个缓慢的启动。
在这个（XP）框中 - 即使net start命令返回'xxx服务无法启动（大约20秒以上），服务似乎仍在继续并确实启动。在此期间，服务管理器报告“开始” - 直到我的睡眠（60000）完成并且服务管理器报告开始。
我还尝试将'ServicesPipeTimeout'注册表项设置为65000 - 这似乎没有任何区别：-O - 是的我重新启动了; - ）。
有没有人知道为什么会这样呢？即使我已将“ServicesPipeTimeout”注册表项设置为65000 - 网络启动在20秒左右后失败：-O。
看来如果我设法在'net start'命令超时之前发出启动命令 - 我的服务确实会启动。这就是为什么我尝试将'ServicesPipeTimeout'注册表项设置为65000 - 但它似乎没有任何区别。
注意我的服务应用程序是使用面向.Net Framework V2的VS2008用C＃编写的 - 就像旧的2000个盒子可以支持的那样。
非常感谢 - 永远希望......
此致
格雷厄姆
答案 0 :(得分：1)
嗯，确实是ServicePipeTimeout来控制超时。不清楚的是这个超时计时器开始计时。您的OnStart（）未被调用的事实表明它在SCM创建进程时启动。可以做出的下一个精神飞跃是30秒的超时仍然适用于进程开始时间，无论注册表值如何。
如果.NET冷启动时间超过30秒，则框的状态非常差。冷启动时间主要由硬盘性能决定，大约85％的时间用于定位和加载DLL。一般。如果盒子从未对其硬盘进行碎片整理并且您最近在其上安装了.NET，那么这种情况很有可能。这将导致.NET文件的集群分散在整个磁盘上，需要许多读取头移动。如果每个群集位于不同的轨道上，这可以大大降低数据吞吐量，低至每秒千字节。
修复此问题可能就像对驱动器进行碎片整理一样简单。在superuser.com上提出有关该问题的问题
答案 1 :(得分：0)
Hmmmm，
我已经做了一些更多的工作，实际上并没有花费时间的.Net，它的服务控制器界面：-O。
要解决这个问题，我写了一个'Controller'应用程序（使用.Net 2），并且持有是在'sc.start'的调用中 - 这是在第一次登录后立即调用的，但我得到了一个异常~30秒后
2010年2月2日07：15：26：752，CarwashClient已停止 2010年2月2日07：15：57：556，StartService（）：异常：无法在计算机上启动服务CarwashClient'。'。 2010年2月2日07：15：57：586，StartService（）：异常：服务没有及时响应启动或控制请求
现在 - 由于控制器应用程序使用.Net，因此大多数必需的库已经加载。
我的服务从未见过OnStart事件 - 因为它也会记录并且日志中没有任何内容。
我的服务也没有定义依赖项 - 它只是没有得到OnStart事件：-O。
我现在已经重写了我的控制器，以便在它收到超时异常的情况下重试3次。稍后当我可以回到盒子上时再试一次......
我猜服务控制器库显然会出现一些主要的负载延迟：-O。
为了回答其他问题，它在嵌入式PC中只有300MHz处理器:-)。即便如此 - 它不应该这么慢。关于碎片整理的好处但是到目前为止它发生在两个盒子中的两个：-O。
由于
格雷厄姆