>>I did a quick test on OnStop:
>>RequestAdditionalTime(120000) then sleep for 100 secs : Service stopped after the 100 seconds.
>>RequestAdditionalTime(300000) then sleep for 240 secs : SCM error "Service did not respond in timely fashion"
>>
>>Don't see any mention of maximum value but there's obviously a difference. FWIW WaitToKillServiceTimeout was 300000 but I don't think that should be a factor in OnStop ?
>
>Well, this indicates there are some inconsistencies in there. 120000 should have 120 seconds and 300000 should have been 300 seconds. Also, the second one also created a situation which I believe is the same that I got. IAC, this approach is a no go. After more analysis, as you may have seen in other messages, the goal is to go higher at the pre shutdown event, which will force Windows to wait for any code to complete in there before initiating the shutdown event.
>
>I have plugged it ok in the OnStart():
>
>

>    Protected Overrides Sub OnStart(ByVal toArgs As String())
>        oRobot.oWindowsService = Me
>
>        ' If we cannot start
>        If Not oRobot.Start() Then
>            lStart = False
>
>            ' If this from the Console application
>            If Environment.UserInteractive Then
>                Exit Sub
>            End If
>
>        End If
>
>        Dim acceptedCommandsFieldInfo As System.Reflection.FieldInfo = GetType(ServiceBase).GetField("acceptedCommands", _
>         System.Reflection.BindingFlags.Instance Or System.Reflection.BindingFlags.NonPublic)
>        If acceptedCommandsFieldInfo Is Nothing Then
>            'Throw ApplicationException("acceptedCommands field not found")
>        End If
>        Dim value As Integer = CInt(acceptedCommandsFieldInfo.GetValue(Me))
>        acceptedCommandsFieldInfo.SetValue(Me, value Or SERVICE_ACCEPT_PRESHUTDOWN)
>
>        ' Define the timer
>        AddHandler oTimer.Elapsed, AddressOf ServiceTimer
>
>        ' Start the timer
>        oTimer.Enabled = True
>
>    End Sub
>

>
>But, on shutdown, the event is never fired:
>
>

>    Protected Overrides Sub OnCustomCommand(command As Integer)
>
>        If command = SERVICE_CONTROL_PRESHUTDOWN Then
>
>            ' If the robot is busy
>            If oRobot.lBusy Then
>                oRobot.lShutDown = True
>                RequestAdditionalTime(30000)
>            Else
>
>                ' If we cannot stop the robot
>                If Not oRobot.StopRobot() Then
>
>                End If
>
>            End If
>
>        Else
>            MyBase.OnCustomCommand(command)
>        End If
>
>    End Sub
>

>
>I am still looking at this to see why the event is not fired. But, I am assuming this might be the way to do it, for our context, to control the general Windows shutdown. So, clean code will be executed to complete everything, all resources will be available because the shutdown event would not be fired yet, then once ok, the services will be terminated.

"Control the general Windows shutdown" - speaking as a sysadmin, this is not a good idea.

First, if your processing depends on other physical or virtual machines, and they become unavailable during a general shutdown then your processing will likely fail.

Second, if I need to shut down your server and/or the environment I have a good reason to do so. If one server refuses to shut down for minutes at a time, I will assume it's hung and I *will* kill it - in Hyper-V Manager, press and hold the power button for ACPI shutdown, pull the power cord - whatever it takes. You will get blamed for any corruption that happens in those circumstances.

To keep your sysadmin on your side you'd need to do something like this:

1. Give her accurate documentation about your job(s) and the time(s) when they are likely to run, and their estimated durations. She can then add this to her checklist of things to watch for prior to doing shutdowns

2. Give her an interface where she can view the status of your service(s). It should show:

- If a job is currently running. If one is running, it should have some kind of accurate progress indicator - estimated time remaining, number of files left to process etc. This progress indicator should either update itself frequently (sysadmins are impatient) or offer a "Refresh" button so she can manually refresh it on demand

- If a job is not running there should be a capability to stop or hold the service's schedule. This is to prevent a scheduled job from starting say, 2 minutes from now, when shutdown of other dependencies in the environment may already be under way

If you put something like that in place the sysadmin can plan ahead and schedule XX minutes of possible extra shutdown time, or try to avoid times when your services may be doing heavy processing. With a progress indicator she can see that your services are not hung and get an idea of when they will finish. From the interface she can stop or hold your service(s) so she doesn't have to worry about them trying to start up while everything else is being shut down.

Bottom line - the sysadmin will be on your side, rather than fighting you. In that case, you don't need to try to control server shutdown.

As a side note, depending on the exact environment effective shutdowns or loss of service can be more frequent than you might expect. For example, in a Hyper-V environment, if Windows Server Backup is used to back up VMs, those VMs are suspended during the backup. Other backup products can do so-called "live" backup without suspending the VMs. You might want to check with the sysadmin which type of backup is being used, and either schedule your jobs, or the backups so VMs you need don't get suspended unexpectedly.