共用方式為

Windows 10, WindowsUpdate.log and how to view it with PowerShell or Tracefmt.exe

  • 發行項

Author: Charles Allen

With the release of Windows 10, there is going to be a change to the way the Operating System logs created and how we can view them.

For those of us who are supporting services like Configuration Manager and Windows Update Services to deploy Software Updates, this means a change to how we will look at the WindowsUpdate.log in Windows 10.
The WindowsUpdate.log is still located in C:\Windows, however when you open the file C:\Windows\WindowsUpdate.log, you will only see the following information:

In order to read the WindowsUpdate.log in Windows 10, you will need to either perform one of two different options.

1) Decode the Windows Update ETL files
2) Use Windows PowerShell cmdlet to re-create the WindowsUpdate.log the way we normally view it

I am going to go ahead and start with the PowerShell cmdlet option #2, as it is my personally preferred method.

Using PowerShell Get-WindowsUpdateLog:

1) On the Windows 10 device you wish to read the WindowsUpdate.log open PowerShell with Administrative rights (I prefer to use PowerShell ISE)
2) Perform the command "PS C:\WINDOWS\system32> Get-WindowsUpdateLog", you will see the following occur:

3) This will take a moment to complete, once done,  you will see on the desktop a new WindowsUpdate.log file

Please note that the newly created WindowsUpdate.log file from running the Get-WindowsUpdate.log command is a static log file and will not update like the old WindowsUpate.log unless you perform the Get-WindowsUpdateLog cmdlet again.
However, with some PowerShell magic, you can easily create a script that will update the log actively to allow you to troubleshoot closer to real time with this method.

For more information on the Get-WindowsUpdate.log cmdlet, please go here: https://technet.microsoft.com/en-us/library/mt238376.aspx

Decoding the Windows ETL files:

So the other option, is to directly decode the ETL files for getting the Windows Update information during troubleshooting. Lets go ahead and walk through this:

1) Download the public symbols, if you have never done this, you can follow these instructions: https://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx
2) Download the Tracefmt.exe tool by following these instructions: https://msdn.microsoft.com/en-us/library/windows/hardware/ff552974%28v=vs.85%29.aspx
3) Open an elevated command prompt
4) Create a temporary directory folder, example %systemdrive%\WULogs
5) Navigate to the folder containing the Tracefmt.exe and then copy it to the folder you just created (example copy Tracefmt.exe to %systemdrive%\WULogs)
6) Run the following commands at the command prompt you have open

cd /d %systemdrive%\WULogs
copy %windir%\Logs\WindowsUpdate\* %systemdrive%\WULogs\
tracefmt.exe -o windowsupate.log <Windows Update logs> -r c:\Symbols

For the <Windows Update logs> syntax, you will want to replace this with the applicable log names, space-delimited. Example:

cd /d %systemdrive%\WULogs
copy %windir%\Logs\WindowsUpdate\* %systemdrive%\WULogs\
tracefmt.exe -o windowsupate.log Windowsupdate.103937.1.etl Windowsupdate.103937.10.etl -r c:\Symbols

Comments

  • Anonymous
    August 06, 2015
    Thanks much for the timely post. This is, IMO, a step back in productivity for admins like myself who look into these logs many times a day. SCCM CMTrace still is the gold standard for me.
  • Anonymous
    August 12, 2015
    I agree with Sandy; this seems like an incredibly awkward additional step. What was the logic behind the change? I understand trying to consolidate logs to a single location, but MS has to realize this is awkward as sin.
  • Anonymous
    October 24, 2015
    The comment has been removed
  • Anonymous
    October 27, 2015
    There is wrong verb-noun 'Get-WindowsUpdateLog' as it should be called 'Export-Log'. But it's easy to make cmdlet wrapper or script to do what you want! Get-WindowsUpdateLog do one thing, namely file-format conversion and after that you need interpret that with Tracefmt.exe tool, grab the output, package to object and play with PowerShell.
  • Anonymous
    October 27, 2015
    These are the top Microsoft Support solutions for the most common issues experienced when using Windows
  • Anonymous
    October 29, 2015
    Thank you for pointing out that needs to be replaced with space-delimited log names.
    One issue I found is that tracefmt.exe (in WULogs) has to be set to Run as Administrator for this to work - for me, that is.
    Also, a suggestion from a friend: Running Procmon during the PS Get-WindowsUpdate.log process to capture details (names) of the logs in copy/paste form.
    It's still a tedious procedure, and not 100% successful. Better than the Get-WindowsUpdate.log method, for legibility tho. :)
  • Anonymous
    November 10, 2015
    Umm, I've yet to get much useful information from this procedure. Just tried again today after a month or so break after frustration, and it's just as bad. Maybe 20% at best of information in the outputted log is readable. What am I doing wrong?
  • Anonymous
    November 11, 2015
    The comment has been removed
  • Anonymous
    November 12, 2015
    The comment has been removed
  • Anonymous
    November 12, 2015
    The documentation for Get-WindowsUpdateLog says the -FlushUpdate option makes the Windows Update agent flush current traces to the log files, but it also says that it stops the Windows Update service. So ... the only way to monitor a scan's progress also STOPS that scan? Surely that's not right!
  • Anonymous
    November 14, 2015
    Looks like it's all fixed in v1511. Just upgraded to v1511 and run the command and it's all in english and very detailed.
  • Anonymous
    November 18, 2015
    Could you please explain, using short words and simple phrases so I'll be sure to understand, why you can't record useful entries into the Windows Update Client Application log? It's extraordinarily frustrating to try and troubleshoot problems in this product.
  • Anonymous
    November 23, 2015
    What problem was Microsoft trying to solve by encoding log files of updates? Seriously what could be a possible benefit? All it does it make things harder, and makes people less likely to want to find solutions to problems themselves. Sounds like someone fell out of the "stupid tree" and hit every branch on the way down.
  • Anonymous
    November 23, 2015
    The comment has been removed
  • Anonymous
    January 02, 2016
    Sandy's 100% correct. What an absurd hassle.