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.
Related
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'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.
I have a requirement that a Windows Forms C# .NET 2.0 program running in user-space (not a service) must always be running. As I'm not infallible and make coding mistakes, I wanted to know of any extra safeguards I could use to ensure this requirement is met. The things I've been thinking of are TaskScheduler to check it every 5 minutes, A stub watcher or a secondary process. Are these good / bad ideas?
Thanks,
Richard
EDIT: The reason I didn't use a service (the obvious and sensible answer!) was the program runs in a kiosk type environment and has has a heavy GUI component. The service option didn't work well across Windows 2000 - W7.
EDIT: The second reason not to use a service was the app needs internet access and on some of our customer sites, proxies are set up to only allow specific users (not the local system account) so it would be tricky to ensure access if multiple users log onto the machine.
Task scheduler is a cheap solution for this which does work. I use this to keep our Perforce Proxy server running (had some issues with the service), and so far there's been no problems - though now I've said that the server's probably exploded!
However, the most complete solution is a Windows service which invokes your app. You can make that service catch error return codes from the app, restart it on failure and notify you by email, which may help you diagnose and fix those issues. I think the Task Scheduler does something similar but it won't be able to provide as much insight into your application as a custom service.
If you're unsure of how to do that, then something like this should work:
http://www.codeproject.com/KB/install/csharpsvclesson1.aspx
There are three approaches that you can take:
Heartbeat Message.
A heartbeat is useful in a distributed application and is simply message that is sent (from let say a client to server) to confirm that it is still healthy/running.
Manager Process
A stub program, implemented as either a user process or a service. It launches the main application, monitors any unhandled exceptions, reports errors, and restarts on failure.
An exception guard on the entry point.
A try-catch-all in the application entry point.
I would recommend either of the first two options; the third option, the try-catch-all, is a particular nasty hack for the lazy and inexperienced programmer (IMHO).
I have successfully used both heartbeat and manager process in a large distributed application.
UPDATE
As for ready-to-go™ restart managers, take a look at the Windows API Codepack as discussed in Emmanuel Istace blog post (http://istacee.wordpress.com/2013/09/21/automatic-recovery-restart-in-net-application/).
You can install the package from https://www.nuget.org/packages/WindowsAPICodePack-Core/
I have a working WCF service and worker role that I have been debugging locally on the Azure Development Fabric. All is well, but now that I'm trying to deploy it to the cloud in a staging environment, I'm seeing some weird issues.
My worker role, which is infinitely more complex than the service, works fine. It goes from Initializing -> Busy -> Ready.
My service role, however, goes from Initializing -> Busy and then the status never changes again.
I have read a few articles about Initialize -> Busy -> Stopping loops, but this is not the behavior I'm seeing. In fact, when I try to use IntelliTrace, I can't access any logs for the service because it never enters the Unresponsive status. I am able to access logs for the successfully-loaded worker role.
How am I supposed to resolve this issue if I can't see any logs or attach a debugger to figure out what's going on? Again, this service works absolutely fine on my local environment.
And before anyone suggests it, I have already done the following:
Check the DiagnosticsConnectionString and make sure it is connected to my storage account
Enable IntelliTrace on the deployment.
Check all referenced assemblies to make sure non-.NET assemblies are "copy to local = true"
It sure would be great if Azure exposed some kind of console so that I could see what's going on.
Later this year, you'll be able to use Remote Desktop to connect in and see what's going on.
For now, you can contact support, and they should be able to help.
Typically, "Busy" is the state you're in while you're still executing code in OnStart(). Is there any chance your OnStart() implementation isn't returning? (Or perhaps some constructor?)
In my experience, when Azure starts playing blackbox in the production, this is caused by the problems with configuration. One of the possible reasons - config section is recognized on your local machine, but is not available on Windows Azure Guest OS.
In this case your role will not even have a chance to say something to IntelliTrace or any logger (it's not loaded).
For example, if you have uri config section in your web.config, then it might work locally, but will cause Azure to freeze web deployment in production. Fix (in this case):
add following line to configuration/configsections:
<section name="uri" type="System.Configuration.UriSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
Your case might be different. Just look for any uncommon configs or cases, where schema might be unknown to Azure Guest OS you are running against.
I had the same problem and ended up starting with a blank project. Getteing it to run in the cloud. Added a few lines, deploying.
Eventually (after 10 deployments... do you know how long that takes???) I got it working... an the cause was in the config file. I didn't trace it down to one line though.
Contacting support would be the right thing to do, as smarx suggests.