0

I have a service that does some system configuration on startup and just ran into an issue where Windows Updates was running at the same time and initiated a reboot which interrupted what my service was doing and I wound up with a broken configuration. I would like to delay the service start until after Windows Updates are done and any reboots completed. Is there some way to tell that updates are currently running? Then I can have my service just wait and resume on the next startup or whenever the updates are finished. Would it help to mark my service as Automatic (Delayed Startup)?

EDIT: I am strictly controlling whether the Windows Update service is enabled/disabled and as part of the configuration I'm manually enabling the service and installing specific updates. Usually this results in an error code 3010 meaning that the machine needs to be rebooted and updates are finished. So after that reboot I resume with further configuration updates from my service.

After further investigation this happened because of a failure in Windows update startup. I saw this in the CBS log:

2020-03-26 21:05:54, Info                  CBS    Startup: Failed, restart required to try again.
2020-03-26 21:05:54, Info                  CBS    Startup: Processing complete. [HRESULT = 0x80070bc2 - ERROR_SUCCESS_REBOOT_REQUIRED]
2020-03-26 21:05:54, Info                  CBS    Keeping Trusted Installer as auto-start
2020-03-26 21:05:54, Info                  CBS    Winlogon: Checking to see if CreateSessionNotify has been called at least once.
2020-03-26 21:05:54, Info                  CBS    Winlogon: CreateSessionNotify has been called
2020-03-26 21:05:54, Info                  CBS    Winlogon: Simplifying Winlogon CreateSession notifications
2020-03-26 21:05:54, Info                  CBS    Startup: received notification that startup processing completed and a restart has been initiated.
2020-03-26 21:05:54, Info                  CBS    A restart has been initiated

My service rebooted the machine after that and resumed its configuration but the Windows Update then ran at the same time and rebooted me. On another machine this didn't happen and I had these messages in the CBS log:

2020-03-26 21:01:50, Info                  CBS    Startup: Retrying failed packages.
2020-03-26 21:01:50, Info                  CBS    Startup: Processing complete. [HRESULT = 0x00000000 - S_OK]
2020-03-26 21:01:50, Info                  CBS    Enabling LKG boot option
2020-03-26 21:01:50, Info                  CBS    Setting ServicingInProgress flag to 0
2020-03-26 21:01:50, Info                  CBS    Startup processing completed. [HRESULT = 0x00000000]
2020-03-26 21:01:50, Info                  CBS    Winlogon: Simplifying Winlogon CreateSession notifications
2020-03-26 21:01:50, Info                  CBS    Winlogon: Deregistering for CreateSession notifications
2020-03-26 21:01:50, Info                  CBS    Startup: received notification that startup processing completed, allowing user to logon
2020-03-26 21:01:50, Info                  CBS    Startup processing complete, Trusted Installer will now wait around for a little while to see if any clients show up.

I'm not sure how to distinguish between these two cases where Windows Update is finished and needs a reboot and where it is essentially going to reboot and try again other than by parsing this log. I'm looking for some kind of state or status indicating what Windows Update is doing.

1

Windows Update is a complex beast.

It looks like stopping and disabling the Windows Update service could do the trick, but this is just the tip of the iceberg; that service only checks for update availability and starts the update process, which is actually handled by the Windows Modules Installer service (aka TrustedInstaller).

Even worse, the actual update installation is a three-steps process: when an update is download and installed, it's actually only scheduled for installation at the next reboot; part of the update installation happens during system shutdown, and part during the subsequent boot; if this part fails for some reason, the system is rebooted and the update installation is rolled back, after which the system can even be rebooted again; and even if it succeeds, some updates (such as the really big ones) can require two reboots.

But there's worse: you can't simply apply an update and then disable the Windows Modules Installer service, because then you would not install anything: that service is what performs the actual update installation upon reboot. If you want to apply an update, you need to leave the service active when rebooting the system; and this means that the service will be free to reboot the system again, if it feels like so.

If you want to completely stop Windows Update from interfering with your actions, you need to stop and disable both the Windows Update service and the Windows Modules Installer service; but then you will not be able to manually install updates, because they require those services for installation.

Oh, and there's also the icing on the cake: the Windows Modules Installer service also handles enabling or disabling Windows roles and features, so that will be impossible to do if the service is stopped.

| improve this answer | |
  • Yeah! I'm realizing the complexity. That's why what I'd like to do is query SOMETHING to say oh, Windows Update / TrustedInstaller / whatever is doing stuff... just wait for it to be done doing stuff, then see where we are at. That's not so tricky due to the state machine in my service, but ... I don't know if that SOMETHING I'm looking for even exists. Any ideas on that? – Skrymsli Mar 27 at 1:00
  • You're on the right track with the CBS logs; CBS stands for "Component-Based Servicing", which is exactly what TrustedInstaller is responsible for. However, I don't know how to parse those logs to determine if another reboot is going to happen or not. – Massimo Mar 27 at 1:15
0

Set the Windows Update service to manual start. Then have your service trigger the start of the Windows Update service when it finishes the other routine.

| improve this answer | |
  • I just updated the question. I am controlling the Windows Update service and I actually disable it before rebooting after installing some updates. In this case Windows Updates resumed anyway. – Skrymsli Mar 27 at 0:09
  • Wrong. First of all, the Windows Update service is already configured for manual start (trigger start); second, see my answer: that is not the service which performs the actual update installation. – Massimo Mar 27 at 0:36
  • Hey Massimo. I DISABLE it. Like right after the OS is installed. It only runs when I enable it and manually install the msu. Then I disable it again before reboot. You are right that after the reboot, TrustedInstaller is still doing stuff, but usually it does not perform another reboot. It seems crazy that this would be non-deterministic, but I have observed it reboot on one machine and not another! Same configuration.... aaaahhh. – Skrymsli Mar 27 at 1:03
  • @Skrymsli As I said in my answer, disabling the Windows Update service is useless; it's TrustedInstaller which handles the actual installation during a reboot. And it will perform another reboot if an update installation fails. – Massimo Mar 27 at 1:13
  • What about defining 'active hours'? docs.microsoft.com/en-us/windows/deployment/update/waas-restart – PSn00b Mar 27 at 3:22
0

Thanks to the other answers on here I found that this value seems to be a pretty reliable indicator that Trusted Installer is still doing things:

[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Interface]
  DWORD ServicingInProgress

From my experimentation, if Trusted Installer is doing something it will be non-zero. If it is 0 then Trusted Installer is done working.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.