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:

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:
2) Download the Tracefmt.exe tool by following these instructions:
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 (15)
  1. Sandy Wood says:

    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.

  2. Matt Wreede says:

    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.

  3. GoGoNET says:

    fukin MS’s monkeys add troubles again.

  4. Pekka Ylönen says:

    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.

  5. Anonymous says:

    These are the top Microsoft Support solutions for the most common issues experienced when using Windows

  6. Colin Vincent says:

    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. 🙂

  7. stephen says:

    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?

  8. Grumpy Monkey says:

    Still broken, it looks to be an issue with getting the correct Symbols from the online Microsoft Symbol Server, the extracted logs are full of junk.
    Offline tracing? Nope (unless you have already downloaded the whole symbol list from MS.
    Troubleshooting a remote desktop logs anyone? Erm??

  9. Harry Johnston says:

    The PowerShell solution doesn’t seem to work remotely. (Perhaps because, according to KB3036646, it wants to present a dialog box.) We really need a better solution that this, it’s going to be a nightmare.

  10. Harry Johnston says:

    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!

  11. stephen says:

    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.

  12. Your Customer says:

    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

  13. What a crock... says:

    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.

  14. Clientguy says:

    I agree with What a crock… Why would anybody do this?

  15. Annie says:

    Sandy’s 100% correct. What an absurd hassle.

Comments are closed.

Skip to main content