I need the service to stop long enough. Approximately 5-10 minutes. Now on windows 10, my service system kills after 60 seconds without waiting for it to finish correctly. Saw a similar issue for C# using the net function RequestAdditionalTime. But I need a C++ implementation on the API.
setting the key value in the registry did not affect
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WaitToKillService set to 300000
You should not mess with global registry settings.
When stopping your service please call SetServiceStatus with SERVICE_STOP_PENDING and set dwCheckPoint and dwWaitHint to a proper value. And according to the documentation for dwWaitHint call ServServiceStatus multiple times until you are done and the service is stopped (SetServiceStatus(h, SERVICE_STOPPED, ...)).
Related
I'm trying to start a service with StartService method. According to the documentation:
StartService will block for 30 seconds if any service is busy handling a control code.
How can I change this timeout value?
You cannot change the timeout. It is builtin to the SCM, and contractually obligated by the documentation to be 30 seconds only.
UPDATE: Apparently, you can change the timeout after all. But only in the Registry, not in code. And it requires a reboot to take effect. See How do I increase windows service startup timeout on Server Fault.
It is the responsibility of each service to respond to the SCM in a timely manner. During a start request, a service needs to call StartServiceCtrlDispatcher() as soon as possible. If it needs a lengthy startup, it should be starting the dispatcher quickly, then entering a PENDING state and report updated status at regular intervals until ready.
I have developed a Win32 service (SERVICE_WIN32_OWN_PROCESS) in C++ for Windows 10. It fails to start once in a while, with the following messages in the event log:
A timeout was reached (45000 milliseconds) while waiting for the MyService service to connect.
The MyService service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion.
What kind of timeout is happening here?
I know that when a service starts up, there is a timeout of 30 seconds from the start of the executable to the call of StartServiceCtrlDispatcher(). I have a log statement just before the call to StartServiceCtrlDispatcher(), but I do not see it. Unfortunately, I do not have any log statements at the point where the service starts up. In between startup and StartServiceCtrlDispatcher(), I have a bit of initialization, but nothing that I would expect to take 30 seconds to finish.
My service never reaches StartServiceCtrlDispatcher() and I have not seen traces in the event log that it crashes.
So, why does the error message mention a timeout of 45 seconds and not 30 seconds? What does this timeout represent?
Edit: For now I am mostly interested if other persons have experienced similar timeout and if they have figured out the reason. I need to debug my code, but I hope that someone might be able to give a direction in which I could concentrate my debugging in. Later I might need specific help with my code when I know where to look :-)
Edit: Microsoft describes many kinds of timeout in their API documentation for services. But I have not seen any mentioning of a 45 seconds timeout even if I have read all the API calls that I am using.
Note: I have not modified any timeouts in the system/registry, if such a thing is possible.
Edit:
Notes about my service.
The issue happens on a users pc that I do not have direct access to.
My service starts up correctly most of the time, but when it fails, it might be during a windows update under boot-up, that causes it.
In a virtual machine with a debug version of my service it takes less than 2 seconds from start of executable to call of StartServiceCtrlDispatcher(). That sounds reasonable. Far below 30 seconds and 45 seconds.
I have in my development environment tried to add a delay (sleep) between start and StartServiceCtrlDispatcher() of greater than 30 seconds. This gave me the standard message about a 30000 miliseconds timeout. Not 45000!
I have tried to force a crash between start and StartServiceCtrlDispatcher(). This gave me a "Application Error" event log entry about the crash and a standard 30000 seconds timeout. Not 45000! On the problem PCs eventlog I have not noticed any "Application Error" when the startup failed.
What does "Pending Restart" mean? I have stopped and restarted my WebJob numerous times and that doesn't seem to fix it. Does it mean I have to restart my website? What caused my job to get in this state in the first place? Is there any way I can prevent this from happening in the future?
Usually, it means that the job fails to start (an exception?). Look in the jobs dashboard for logs.
Also, make sure that if the job is continuous, you actually have an infinite loop that keeps the process alive.
To add to Victor's answer, the continuous WebJob states are:
Initializing - The site was just started and the WebJob is doing it's initialization process.
Starting - The WebJob is starting up the process/script.
Running - The WebJob's process is running.
PendingRestart - The WebJob's process exited (for any good or bad reason) in less than 2 minutes since it started, for a continuous WebJob it's considered that something was probably not right with it (some exception during start-up probably as mentioned by Victor), at this point the system is waiting for 60 seconds before it'll restart the WebJob process (hence the name "pending restart").
Stopped - The WebJob was stopped (usually from the Azure portal) and is currently not running and will not be running until it is started again, best way to see this is as disabled.
Also, take a look at the webjob log, it should hold cue to what's been happening.
if the JOB is set to run continuously, once the process exits (say you are polling a queue and it's empty) the job shuts down and status changes to "pending restart". Azure Scheduler will typically restart the process in 60 seconds.
Try changing the target framework to .NET 4.5. This same issue was fixed for me when I changed the target framework from 4.6.1 to 4.5.
Had the same problem, found out that i need to keep my webjob alive, so I put a continous loop to keep it alive.
It means that application is failing after start. Check the App Service Application setting might have some problem. .. In my case i am passing date as a configuration and i entered wrong date like 20160431
This is just because Webjobs is failing or giving exception.
Make sure the Webjobs is continuous and you can check that in the log where it failing and can make the changes.
Process went down, waiting for 60 seconds
Status changed to Pending Restart
In my case, we got the deployment package prepared through the Visual Studio folder publish and deployed along with WebApp. Package created through 'Folder publish' lacked 'run.cmd' file in which command to invoke the console application (.exe) is available; this file is automatically created when we directly publish to Azure WebJob from Visual Studio.
After manually adding this to a package folder, the issue got fixed.
I am trying to call a long running web service from WebServiceTask in SSIS, but the TimeOut value for it seems to be a max of 300 seconds or 5 mins. But i am afraid that it might get timed out.
is there a way to increase the timeout vale
Unfortunately no. The Web Service Task, as I see it, is one of those "after thoughts." It satisfies a check box but doesn't go beyond the surface of functionality. I have found that I have a better web service experience if I just use a script component.
I write a local service application using C++ and I can't find the correct way of registering for a pre-shut-down notification (for OS later than Windows XP). I believe that SERVICE_CONTROL_PRESHUTDOWN notification has been added since Vista, but when you call SetServiceStatus do we need to specify:
dwServiceStatus.dwControlsAccepted = SERVICE_ACCEPT_PRESHUTDOWN;
or
dwServiceStatus.dwControlsAccepted = SERVICE_ACCEPT_SHUTDOWN | SERVICE_ACCEPT_PRESHUTDOWN;
You cannot accept both a shutdown and a preshutdown if your service is correctly coded. The documentation explicitly states this.
From http://msdn.microsoft.com/en-us/library/windows/desktop/ms683241(v=vs.85).aspx:
Referring to SERVICE_CONTROL_PRESHUTDOWN:
A service that handles this notification blocks system shutdown until the service stops or the preshutdown time-out interval specified through SERVICE_PRESHUTDOWN_INFO expires.
In the same page, the section about SERVICE_CONTROL_SHUTDOWN adds:
Note that services that register for SERVICE_CONTROL_PRESHUTDOWN notifications cannot receive this notification because they have already stopped.
So, the correct way is to set the dwControlsAccepted to include either SERVICE_ACCEPT_SHUTDOWN or SERVICE_ACCEPT_PRESHUTDOWN, depending on your needs, but not to both at the same time.
But do note that you probably want to accept more controls. You should always allow at least SERVICE_CONTROL_INTERROGATE, and almost certainly allow SERVICE_CONTROL_STOP, since without the latter the service cannot be stopped (e.g. in order to uninstall the software) and the process will have to be forcibly terminated (i.e. killed).
As noted by the commenters above, you will need to choose from either SERVICE_ACCEPT_SHUTDOWN or SERVICE_ACCEPT_PRESHUTDOWN (Vista or later). If you are using SERVICE_ACCEPT_PRESHUTDOWN, you will need to register your service with the SCM using RegisterServiceCtrlHandlerEx instead of RegisterServiceCtrlHandler else you will not be receiving the pre-shutdown notifications. The handler prototype also changes from Handler to HandlerEx.
Another point to note is that handling pure shutdown events is limited to 5 seconds in Windows Server 2012 (and presumably Windows 8), 12 seconds in Windows 7 and Windows Server 2008, 20 seconds in Windows XP before your service is killed while stopping. This is the reason why you may need the pre-shutdown notification. You may want to change this at \\HKLM\SYSTEM\CurrentControlSet\Control\WaitToKillServiceTimeout.
In the comment from alexpi there is a key piece of information. I found that the service handling PRESHUTDOWN needs to update the service status with a new checkpoint number (repeatedly) before WaitToKillServiceTimeout has elapsed. My server was configured to 5000 ms and my service only updated every 12000 ms, and the server went into the SHUTDOWN phase, which caused my attempt to stop another service to return the error that the shutdown was in progress.
These two notifications seem to be different as I get it from the documentation. If what you need is really to enable your service to recieve preshutdown notification, you should go with: dwServiceStatus.dwControlsAccepted = SERVICE_ACCEPT_PRESHUTDOWN; But if you also want to enable your service to receive shutdown notifications, you should go with your second option.