Windows Update tells me that I'm up to date, and I've not knowingly started any installers, but the "Windows Modules Installer Worker" process is merrily thrashing my disk - is there a log, or way to find out what it thinks it's up to?
Since 2015 the human-readable log needs to be generated on-demand
When you run the Get-WindowsUpdateLog cmdlet, an [sic] copy of WindowsUpdate.log file is created as a static log file. It does not update as the old WindowsUpate.log unless you run Get-WindowsUpdateLog again.
Basically open a powershell and type
Get-WindowsUpdateLog. It will do its thing and finally print something like
WindowsUpdate.log written to C:\Users\User\Desktop\WindowsUpdate.log
which you can then inspect. The log is pretty verbose and the TiWorker is a busy bee, e.g. just for checking/installing the Windows Defender definition updates you may get slightly over 1000 lines of log output.
After a bit more experimenting (with an old enough PC that uses an HDD so things take a while), the "firehose" log does have a substantial limitation: if there's an old task started that takes a long time to complete but prints nothing as it progresses, it becomes very hard to find in the log if Windows attempts newer tasks, but you get some clue that the new tasks get postponed or error. Typically these aborted/postponed with the dreaded
0x8007002 in the "control panel" user interface.
Also, if there's some other (typically non-MSFT) app that invoked TiWorker for servicing, not Windows update, you won't get anything in that log, as far as I can tell. So, it seems the log only captures a subset of what TiWorker does. Apparently you have to change the registry (directly of via the policies) for more:
To enable Windows Installer logging yourself, open the registry by using Regedit.exe, and then create the following subkey and keys:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer Type: Reg_SZ Value: Logging Data: voicewarmupx The letters in the value field can be in any order. Each letter turns on a different logging mode. Each letter's actual function is as follows for MSI version 1.1:
v - Verbose output o - Out-of-disk-space messages i - Status messages c - Initial UI parameters e - All error messages w - Non-fatal warnings a - Start up of actions r - Action-specific records m - Out-of-memory or fatal exit information u - User requests p - Terminal properties + - Append to existing file ! - Flush each line to the log x - Extra debugging information. The "x" flag is available only on Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.
"" - Wildcard: Log all information except the v and the x option. To include the v and the x option, specify "/lvx". Note This change should be used only for troubleshooting and should not be left on because it will have adverse effects on system performance and disk space. Each time that you use the Add or Remove Programs item in Control Panel, a new Msi*.log file is created. To disable the logging, remove the Logging registry value.
Enable Windows Installer logging with Group Policies You can enable logging with Group Policies by editing the appropriate OU or Directory Group Policy. Under Group Policy, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then select Windows Installer.
Double-click Logging, and then click Enabled. In the Logging box, enter the options you want to log. The log file, Msi.log, appears in the Temp folder of the system volume.
Although these logs are plain text (and MSI Office loved to created huge ones in in
wilogutl to make them a bit easier to comprehend. (In particular this tool has an abstraction/overview of Feature and Component States.)
For Windows setup logs, MSFT also gives SetupDiag as an alternative (more newbie friendly) parser which they say is actually included with Win 10 2004 (April 2020 release), but can be downloaded for the older versions of Win 10. I wasn't able to find in the location they indicated though (
%SystemDrive%$Windows.~bt\Sources) on the VS Dev Eval VM of that build. Maybe it's only there if you fail the install. In any case, it has nothing to say about routine things like after installing just some Defender updates.