I've installed my serivce but cannot start it.
I get dialog window with the message:
Windows could not start the WU Distribution Service service on Local
Computer. Error 1053: The service did not respond to the start or
control request in a timely fashion.
And two EventLog entries: the first with the same message and the second one with:
A timeout was reached (30000 milliseconds) while waiting for the WU
Distribution Service service to connect.
My serivce class has default generated constructor with the only call to InitializeComponent() so nothing heavy.
Just to check how long OnStart runs I inserted Debug.WriteLine with times tamps and added TextWriterTraceListener with Debug.AutoFlush set to true.
No log file was created, thus OnStart was not called.
To be absolutely sure I just throw exception inside OnStart but still get no messages about exception.
I need to know what can be the reasons why OnStart is not called.
You'll have to debug to see what happens. You can add more prints, I would recommend eliminating complications and just write to a file stream instead of Debug listeners.
You can attach debugger to a running process, see How to: Debug Windows Service Applications, but that requires the service to be up and running. If it hungs at startup you still have a good chance because you can inspect the hung state and understand what happens.
If you need to debug service first moments of life then you'll need to graduate to a true debugger. See KB824344 How to debug Windows services, specifically the Configure a service to start with the WinDbg debugger attached, I usually use gflags, way more elegant than registry. You'll need to bridge a remote to your service attached WinDbg from your own session, see Remote Debugging Using WinDbg.You can debug managed code in WinDbg, is not exactly the posh experience VS is doing, but is the real deal on what the machine is doing.
An easy thing to test first is how does your executable behaves when started under the service account. If service is running as localsystem then use psexec -i -s.
Related
If I call Console.WriteLine in a Windows Service, are the logs written anywhere in a sort of "hidden" console?
I'm NOT interested in finding out where Windows Service writes Console.WriteLine's logs, I'm just wondering if the service still writes the log in a background console (invisible to the user) when Console.WriteLine is called.
Services have no allocated consoles, stdout data will silently get dropped.
Unless of course at any point you attach something to it, like a debugger that hooks into stdout, in which case you'll start seeing your messages.
I have a service application written in C# and under certain circumstances, I would like it to terminate itself. This would happen after the service has been running for a while, so this would not be happening in the OnStart() event.
Everything that I have read so far suggests that the only safe way to terminate a service is through the Service Control Manager. My service runs as Local Service and does not have the rights to start or stop services, so I can't access the SCM from the service itself. Is there another way to self-terminate while still playing by the rules of the SCM?
Try ServiceBase.Stop().
If you want to terminate the service instead of stopping it (perhaps because the service has caught an otherwise unhandled exception) you can use Environment.Exit(1) (use another exit code if you want).
Windows will discover that the service has terminated unexpectedly. If the service has been configured to recover the recovery procedure will be used which includes options for restarting the service, running a program or restarting the computer.
What happens if you just let all the executing threads finish? I can imagine three possible outcomes:
The SCM notices, and decides you finished appropriately
The SCM notices, thinks you died, and restarts you
The SCM doesn't notice, and shows you as still running
EDIT: I suspect this answer is the best one really, but I'll leave this up (for the moment) just for the sake of interest.
Don't have the service run under Local Service. Have it run under a user that has the rights to stop a service.
Although the idea of self-terminating services is not the best of ideas. That very fact alone means that it should be an application, and not a service.
I have a service application written in C# and under certain circumstances, I would like it to terminate itself. This would happen after the service has been running for a while, so this would not be happening in the OnStart() event.
Everything that I have read so far suggests that the only safe way to terminate a service is through the Service Control Manager. My service runs as Local Service and does not have the rights to start or stop services, so I can't access the SCM from the service itself. Is there another way to self-terminate while still playing by the rules of the SCM?
Try ServiceBase.Stop().
If you want to terminate the service instead of stopping it (perhaps because the service has caught an otherwise unhandled exception) you can use Environment.Exit(1) (use another exit code if you want).
Windows will discover that the service has terminated unexpectedly. If the service has been configured to recover the recovery procedure will be used which includes options for restarting the service, running a program or restarting the computer.
What happens if you just let all the executing threads finish? I can imagine three possible outcomes:
The SCM notices, and decides you finished appropriately
The SCM notices, thinks you died, and restarts you
The SCM doesn't notice, and shows you as still running
EDIT: I suspect this answer is the best one really, but I'll leave this up (for the moment) just for the sake of interest.
Don't have the service run under Local Service. Have it run under a user that has the rights to stop a service.
Although the idea of self-terminating services is not the best of ideas. That very fact alone means that it should be an application, and not a service.
I am using C# to write a program that uses a web service from http://msrmaps.com, the problem is sometimes (seemingly at random) the site won't work properly and will return a few different exceptions. Then on subsequent attempts to use the service I get the error over and over, then after a while (sometimes 30 minutes) the service starts working properly again. In order to avoid waiting for the service to work properly again, I usually just close my program and start it back up again. Usually that fixes the problem and I can continue to use the web service.
My question: Is it possible to restart my program within the program or better yet is there a way to somehow re-connect to the web service like the program does when I first run it?
What is the program actually doing that depends on the web service? Does it really need to be re-started? It sounds like you should be able to just have some UI element in the application that attempts to connect to the service. Wrap that connection in some exception handling and somewhere in the application's UI display that the service connection is currently unavailable.
Or am I way off here?
Warning: This is a bit of a hack, but it works.
I'm assuming your application is unattended, so a UI change alerting the user to the need to shut down and restart is not an option.
We had a similar situation where the simplest resolution to a problem was to shut down and restart my app. (We'll call this "App A").
What I wound up doing was writing a second executable (We'll call it "App B") as a console app that did two things.
It used the System.Diagnostics.Process to kill any instance App A.
Use System.Diagnostics.Process to re-launch App A after all instances were killed.
Then in App A, I had a try/catch around the offending code, and when the error I was looking for came up, it would call App B.
This was the only way I could find of killing a program and relaunching it. If anyone has a better solution, PLEASE post it and I'll change my hack to use a better solution.
I would check that you don't have too many simultaneous requests happening at the same time due to each waiting for a long time before returning (and relatedly, that the total allowed connections as per machine.config is high enough). Throttling code can be very useful with unattended use of web-services (or any other remote service), if you've had a few failures in a row then wait a while before allowing another request to be made (I like to roll forward the wait period each time, starting a around a minute, maxing the wait at around 10minutes).
Then while you can't guarantee the other service won't go down, you can help prevent it causing a permanent problem, or reducing the performance of other processes.
I developed a simple windows service in C# as per this article.
http://www.codeproject.com/KB/dotnet/simplewindowsservice.aspx
I was successfully able to start the service for the first time and stop it. During the following attempts, I was not able to start the service. I got the following information.
The MyNewService service on Local
Computer started and then stopped.
Some services stop automatically if
they have no work to do, for example,
the Performance Logs and Alerts
service.
Please help.
I outlined here a method we're using to debug our Windows services. Maybe this will help you trace the error. Basically this sounds like some error is occurring while trying to execute the OnStart method.
Basically this means the main thread of your service has crashed for some reason. The most common I've seen is filesystem access to it's own log files.
Sometimes you can find the reason in the event viewer, but unfortunately a lot of the time the user you're running the service as won't actually have access to log it's error. A simple thing to do if you're in a dev environment is to just give the service an administrator account temporarily, firstly cause it'll tell you whether the crash is being caused by lack of access (cause it'll work) and secondly if it's not it'll allow it to write to the event viewer. Make sure to take the admin access of f once you fix it though, cause long-term that can be very dangerous.
Did you look in the event log? You can usually get more detailed error information there about the service error. Also, are you writing out to a log with your service? That's another way you could figure out what's going wrong.
You can get to the event log by right clicking on Computer and selecting "Manage". Under System Tools, look under Event Viewer->Application. This is on Windows XP, but other Windows OS's should be similar.
If the service is on your development machine, you should be able get Visual Studio's debugger to attach to it as it starts so that you could identify if anything is causing it to crash. It involves a bit of registry editing as described here: http://blogs.msdn.com/greggm/archive/2005/02/21/377663.aspx
It sounds like your main thread is dying for some reason. Put a call to System.Diagnostics.Debugger.Break() in your service's startup code, e.g., the Main entry point, the service constructor, or the OnStart() method. When you start your service from the Services MMC, you'll be prompted to enter a debug session. Once you're in Visual Studio, open the Exceptions dialog (from the Debug menu) and check the boxes in the Thrown column. Then debug from there to find the problem.