How to detect if a reboot is needed after installing a patch

If you use ITMU (SMS 2003 Inventory Tool for Microsoft Updates) or MBSA 2.0 to scan
machines for patch status, a patch may be reported as installed even though a
reboot is needed in order complete the installation. Example scenario:

- You install patch M05-051 (KB 902400) by manually downloading the patch
installation EXE and then running the EXE.

- After the installation is done, you do not reboot the machine even though the
installation wizard states that it's needed.

- You scan the client using ITMU (scanwrapper.exe) or MBSA 2.0 (mbsacli.exe). The
patch is reported as installed by both ITMU and MBSA. However, MBSA flags that a
reboot is needed by some software update/patch as part of its general vulnerability
scan, not its software updates scan. Note that in this scenario, MBSA 1.2.x would
report the patch as applicable.

This behavior is by design. Both ITMU and MBSA 2.0 use the Windows Update Agent
(WUA) as their scan agent, hence the identical results. (WUA logs to
%systemroot%\WindowsUpdate.log). In order for ITMU to accurately report software
update status, the software updates/patches need to be installed through ITMU or
Microsoft Update. The reason for this is that when a patch is manually installed, a
registry key/value that ITMU uses to detect needed reboots is not set. This is set
by WUA which is not utilized when the patch is manually installed. Here's how ITMU
detects a pending reboot:

1. When a patch is installed by WUA, either via ITMU or Microsoft Update, if the
patch installation returns exit code 3010, WUA creates the volatile registry key
Update\RebootRequired. It then adds a DWORD value for each update ID that requires
a reboot, for example:


2. When ITMU next performs a scan via smswushandler.exe which invokes a WUA scan,
the following takes place:

a) WUA will scan for missing updates according to their detection rules. If a patch doesn't pass its detection rules, WUA reports that a reboot is pending.

b) If a patch is reported as installed by WUA, ITMU (smswushandler.exe) checks to
see if any patches are listed under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired. If so, those are flagged as applicable. As mentioned
earlier, this key will be missing if a patch was manually installed. Note that the
RebootRequired key is automatically deleted when the machine reboots as it's
volatile (only held in memory). It's possible to manually create the RebootRequired
key and its values to force ITMU to detect a pending reboot. The Win32 API
RegCreateKeyEx could be used with the REG_OPTION_VOLATILE flag set for dwOptions to create the RebootRequired key.

So without SMS and ITMU in the picture, why does MBSA 1.2.x report the patch as
applicable while ITMU and MBSA 2.0 (actually WUA) report it as installed when the
detection rules really are the same? The reason is that when WUA comes across a
file version or file CRC detection rule, in addition to the file's original
location, for example system32, WUA also checks the files that the
PendingFileRenameOperations value under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager points to.


The detection rule for a patch states that file system32\clbcatq.dll should be
version 10.
The current version of the file in system32 is 9.
WUA performs a scan and finds that the file is in compliance.
PendingFileRenameOperations  has the following two entries:
During a scan, WUA will actually check the file version of system32\SET31.tmp which
is 10.
SET31.tmp will be renamed to clbcatq.dll when the machine restarts.

Besides the above two registry values under "Session Manager" and "RebootRequired",
there is a third one that can be used to detect a pending reboot. ITMU can't use
this though as ITMU reports compliance on a per patch basis, not per machine.
However, MBSA 2.0 makes use of this new registry key that was introduced with
version and later of update.exe. The key is
HKLM\SOFTWARE\Microsoft\Updates\UpdateExeVolatile and the value is called flags.
See for details on this
value. Basically, if you have a 1 or 2 in the flags value, a reboot is pending.
MBSA 1.2.x or ITMU does not check this key/value. A possible workaround to detect
pending reboots when a patch was not installed via WUA, is to for example send out
a vbscript or update sms_def.mof to check for the presence of this key/value.

To use MBSA 2.0 to detect a missing reboot, run mbsacli /n Password+OS+SQL+IIS /nai

To query WUA for outstanding reboots, use the script at and replace "IsInstalled=0" with "RebootRequired=1".


Comments (3)

  1. anandi says:

    Hi Hans 🙂  Hope you’re doing well.

  2. Thanks a bunch for this useful info.

  3. Phil Vialle - MSFT says:

    Hi there,

    great article – thanks.

    In case of, just wanted to point out that this does not work anymore with MBSA 2.2 (latest version, ATOW).

    – mbsacli /nai    

    /nai unknown command

    – mbsacli /nm    

    /nm unknown command

    You might want to have a look at the following article for further information:…/cc184922

    Why doesn't MBSA provide reboot pending status for the latest updates?

    MBSA can only provide reboot pending status when the option to Check for Windows administrative vulnerabilities is selected in the GUI or by default if "/n Updates" is not added to the command-line utility (CLI) to suppress this feature.


Skip to main content