I have a windows service that creates an instance of UdpClient class and listen for incoming request. I have a helper class to run it as a console application. When i run it as a console program, it runs fine and receive connections normally.
When deployed as a Windows Service using "installutil MyService" and start it, I get the following error:
"Error 1053: the service did not respond to the start or control request in a timely fashion."
The service don't even start, so I can't place a breakpoint in code.
Any suggestion about how to debug this or where to look?
Thanks.
Your Start() method is taking too long to do whatever it does when the service starts - if memory serves you have something like 15 seconds to kick-off whatever tasks the service is supposed to perform (on separate threads for long-running or continuous activities) and you must then allow the startup method to end so that the Service Controller recognises that the service has finished starting.
You didn't post any code, but my assumption would be that you're listening for UDP traffic synchronously - so the startup method just sits there waiting for UDP messages and never ends. Put the UDP listener into its own thread, start that thread, and then let the startup method end.
Related
I have a service that spins up a server which handles calls. The server can only start under certain conditions, and the service should try to start the server for a couple of minutes before giving up. Therefor, I use the service interface methods only to spin up a thread that handles the "try starting server and retry if it failed"-logic. But now I need to add termination of the service, if the server was not successfully started after, say, 5 minutes. The problem is, that I do not know how to marshal a call back to the service's "main" thread, since, as far as I understand, it is not an STA thread where I can just use a dispatcher. It is my understanding that I would have to do that in order to be able to System.Exit(1) my service. Any advice?
Points of clarification:
I do spin up a thread that is basically the service's main thread. Terminating that thread, however, does not couse the service to appear as stopped.
I'm giving you a tip and if you don't manage to implement it I will edit it later with more details. When you want to stop the service you should call the ServiceBase.Stop method.
Spin up a task to do the "try starting server and retry if it failed" and add a continuation (or pass Stop as Action argument) that will be executed when the task completes based on the result (or alternatively if you throw exception on failed to start, then verify Task.IsFaulted and call Stop() if true).
I have a windows service hosting a WCF server.
I used "sc config...." and "sc failure..." to set the following properties:
1) log on credentials - local user
2) recovery - restart the service for the first 2 failures, and then run a program (.bat or .cmd)
I tried to test it with several ways of crashing the service, but non of them kicked in the recovery.
I tried via task manager, taskkil, throwing exception within the code, divide by zero...
and nothing happend - not the restart nor the run a program.
Any ideas?
I bet that wcf service is spawned out in a thread from the containing service and the main thread is not exiting for child thrown exceptions as you are expecting.
See this article.
Since this exception is being thrown on a different thread than the
main thread, I need to subscribe to the AppDomain’s UnhandledException
event. If I don’t do this the thread will just die silently and the
service will continue to run, which is not what I want.
I am getting into windows services and looking over some tutorials, but they are all very dumbed down. They usually involve printing something out in the overridden OnStart method. That sounds like it gets called once. Now where would I put code that needs to be run continuously?
All of the On... methods in your service class should return as quickly as possible. They will end up being called whenever the Windows service controller interacts with your service, and the service controller will be waiting for a successful return. Whenever you use the Services Control Panel applet and you start or stop a service, that progress bar you see is what is shown while waiting for that service's equivalent of OnStart or OnStop to return.
So the typical thing to do in OnStart is one or more of the following:
start a separate thread that performs the constant task your service will perform
set up a timer (of the System.Threading.Timer variety) that will periodically perform whatever action your service does periodically (perhaps polling for some state)
start listening asynchronously on a network port, perhaps with a TcpListener or UdpClient
subscribe to some system event
In any of these cases, your service's task is performed asynchronously, and you exit from OnStart immediately. But remember to keep track of your thread, timer, TcpListener, or whatever, so that you can interact with it in OnStop (and optionally OnPause and OnContinue). Usually the thing to do is to dispose of any timers (so they won't fire any more), shut down any sockets or listeners, then set a ManualResetEvent. Any threads you have running should check this event periodically and exit once it's signaled. If you want to ensure a successful shutdown of the service and risk possible data loss, you might join to any running threads with a reasonable timeout (30 seconds is common), then abort any threads that are still running after the timeout has expired.
The same as any other project that has more than a couple of classes - you put it in a separate project.
The 'Windows Service' project should just contain the boilerplate stuff to start the service, any timers that are part of the service, and that sort of thing. Putting the rest in another project allows you to use your business logic in a desktop app, a web app, as a WCF service and so on later on.
To create any Windows Services the proper way, I stick to TopShelf library. It is IoC friendly and you can keep the Windows Service infrastructural code completly separate from the logic of the service. You also can run the service as a console application and just convert it to a windows service on production. I think it is "THE" way to create Windows Services and never looked back.
I've created a WCF service application containing a client, contract and a service. I use the client to call methods implemented in the service.
Is there a way to have a timer in the service and to set its interval to tick and to have a method that is executing during the time the service is being called.
I tried to create a constructor to the service (static and non-static) but it didn't work.
I thought about creating a 3rd party client, which will execute a method implemented in the service which will do what I need.
Thanks,
Oded.
If you want something running while the service is called, then you could do it from the client:
Call start process from the client
Call the service from the client
Call stop process from the client
You could also do it on the server side:
Your first line in the service is start process
Your last line in the service is stop process
Note you must be carefull about error handling, otherwise you will end up with many orphaned processes.
I'm developing an application to achieve work in background through a Windows Service.
I've created the service thanks to the MSDN tutorial, and then I can Start or Stop it correctly.
My service also need to execute custom commands. Therefore, I've implemented the "OnCustomCommand" method in the service's class.
I can send custom execution commands with commands ID between 128 and 255, accordingly everything i've found on the net.
My problem is :
I can't execute command on the service when it's stopped. ExecuteCommand() throws an System.InvalidOperationException every time I call it on the serviceController.
Cannot control <myservice> service on computer '.'
This does not happens when the service is running.
MSDN says
When you call ExecuteCommand, the
status of the service does not change.
If the service was started, the status
remains Running. If the service was
stopped, the status remains Stopped,
and so on.
So I suppose this is actually possible to executeCommand on stopped services.
My service is installed as LocalSystem service, and the serviceController is run with administrator privileges.
Does anyone know how to resolve this?
It would not be possible to ExecuteCommand against a stopped service. I believe what the documentation you're reading is telling you is that calling ExecuteCommand will not start the service if it is stopped. It is not saying that you will still be able to call the method; essentially no object exists to execute the method on. I think your best solution would be to find a way to determine if the service has stopped, if it has, restart it and then call ExecuteCommand. Otherwise, you could use kind of a "dirty hack" and attempt the call, if it fails, catch the exception and start the service and try a second time. By no means preferred, but possible.
EDIT:
Assuming that you're using a ServiceController you can use the Status property to determine if the service is running or not.
It's not possible to ExecuteCommands against a stopped service.
If it's not running, then it's not "there" to listen for the commands you send it.