net start command delayed ??

Question

Hi,

I have some slow embedded PC's running Windows 2000 and am having trouble starting a service reliably. There is a VERY noticeable delay between issuing the command 'net start xxx' and the message 'the xxx service is starting'. This is causing my service to fail to start.

My service regularly fails to even receive a 'Start' command (I am logging this and can see that it never occurs).

I tried to repeat this on a much faster XP box, but the delay is of course MUCH shorter. I did however deliberately add a sleep(60000) in my Onstart handler - to simulate a slow startup.

On this (XP) box - even though the net start command returns 'the xxx service could not be started (after about 20+ seconds), the service seems to continue on and does indeed start. During this time service manager reports 'starting' - until my sleep(60000) completes and service manager reports started.

I ALSO tried setting the 'ServicesPipeTimeout' registry entry to 65000 - and this seems to have made no difference whatsoever :-O - yes I did a reboot ;-).

Does anyone have any idea why this happens please ??. Even though I have set up my 'ServicesPipeTimeout' registry entry to 65000 - the net start fails after 20 or so seconds :-O.

It would appear that IF I manage to get a start command issued before this 'net start' command times out - my service will indeed start up. This is why I tried setting the 'ServicesPipeTimeout' registry entry to 65000 - but it seems to make no difference at all.

NB My service app is written in C# using VS2008 targetted at .Net Framework V2 - as thats all that the old 2000 boxes can support.

Many thanks - ever hopefully....

Regards

Graham

Answer 1

Well, it really is ServicePipeTimeout that controls the timeout. What isn't clear is when this timeout timer starts ticking. The fact that your OnStart() doesn't get called would indicate that it starts when the SCM creates the process. The next mental leap that can be made is that the 30 second timeout still applies to the process start time, regardless of the registry value.

The box is in really poor shape if the .NET cold start time is longer than 30 seconds. Cold start time is dominated by hard disk performance, roughly 85% of the time is spent locating and loading DLLs. Normally. It's sorta possible if the box never had its hard disk defragmented and you've recently installed .NET on it. That would cause the clusters of the .NET files to be scattered all over the disk, requiring many read head moves. This can dramatically reduce data throughput, as low as a kilobyte per second if every cluster is on a different track.

Fixing this could be as simple as defragging the drive. Ask questions about that at superuser.com

Answer 2

Hmmmm,

I have done some more work on this and its not actually .Net which is taking its time, its the servicecontroller interface :-O.

To work around this issue a wrote a 'Controller' application (using .Net 2), and the holdup is in the call to 'sc.start' - This was called immediately after the first log entry, but I got an exception ~ 30 seconds later

02 Feb 2010 07:15:26:752,CarwashClient is Stopped 02 Feb 2010 07:15:57:556,StartService(): Exception: Cannot start service CarwashClient on computer '.'. 02 Feb 2010 07:15:57:586,StartService(): Exception: The service did not respond to the start or control request in a timely fashion

Now - as the controller app uses .Net, then most of the required libraries would have already been loaded.

My service never saw the OnStart event - as it also logs and nothing appeared in the log.

My service also has no dependencies defined - it just doesn't get the OnStart event :-O.

I have now rewritten my controller to retry 3 times in the event that it gets a timeout exception. Will try again later when I can get back onto the box....

There is obviously some major load delay going on with the servicecontroller library I guess :-O.

To answer the other points raised, its only a 300MHz processor in an embedded PC :-). Even so - it shouldn't be this slow. Good point about the defragger though but its so far happened on two out of two boxes :-O.

Thanks

Graham