locked
Get-WindowsUpdateLog still not working RRS feed

  • Question

  • Hi,

    We all know that Get-WindowsUpdateLog is an abomination, but beyond that has anyone actually got it working yet?

    Using Windows 10 1607, so no Insider Preview, but no matter what I try, the log is nothing but GUID=fbf46613-33f0-3872-c248-268156b5ca06 (No Format Information found).

    I've cleared the local symbol cache, tried pointing directly at the public symbol server, but no matter I do I still can't get any useful information out of the log.

    Windows build is 14393.223, I've downloaded the symbols that match this and pointed at them explicitly with -symbolserver <path> and that doesn't work either. The dates of the pdbs match with those of my local dlls.

    We've got a problem with our WSUS and I've had to go back to a Windows 8 machine to be able to do any debugging because of this mess.


    Wednesday, March 29, 2017 9:40 AM

All replies

  • Hi OffColour1972,

    I am using Windows 10.14393.953(KB4013429) version. The Windowsupdate log is good.

    The latest version should be Windows 10.14393.970. We could install the KB4016635 manually then check the symptom again.

    Best regards

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.



    Thursday, March 30, 2017 2:07 AM
  • And I am on 14393.969.  WindowsUpdate.log is incomplete but mostly readable.  However, I don't use WSUS, so maybe that should be the focus of your diagnosis.

    Also, for another thought, what if the WindowsUpdate etl files are stuck in another version?  I can imagine that Get-WindowsUpdateLog would be giving the same useless result every time then.  The actual files involved contain date and time information which could clarify if this possibility could be your case and they are logged by full path name as they are converted by the cmdlet.  More precise diagnostics on this tack are probably possible using the command line arguments and PowerShell tracing.  I may have a look at how that could be done.  Alternatively, as always, I would see if there would be any clues available by running ProcMon.  That would probably only be really useful if you had two otherwise identical traces to compare for their essential differences.

    HTH



    Robert Aldwinckle
    ---

    Friday, March 31, 2017 12:49 AM
  • WSUS isn't the problem. It's the ability of Get-WindowsUpdateLog to parse the etl files correctly.

    It's working with that update, but that does seem to imply that it will only work when running exactly the same updates that Microsoft expect you to have installed.

    On a related note, do you know how to enable verbose logging for Windows Update in Windows 10? The method for Windows 8 doesn't work.

    Friday, March 31, 2017 3:37 PM
  • WSUS isn't the problem. It's the ability of Get-WindowsUpdateLog to parse the etl files correctly.

    If you really need to do it, Chentiangemalc showed how
    https://answers.microsoft.com/message/fc2a6c8e-b38d-4d85-b84e-a749b79ec3d3

    The blog hasn't been updated in a while; who knows maybe there has been an unreported development which would make the procedure easier?

    On a related note, do you know how to enable verbose logging for Windows Update in Windows 10? The method for Windows 8 doesn't work.

    Then, I imagine it would be possible to find out whether WU looks there by stopping it and starting it while running ProcMon.



    Robert Aldwinckle
    ---

    Friday, March 31, 2017 5:25 PM
  • On a related note, do you know how to enable verbose logging for Windows Update in Windows 10? The method for Windows 8 doesn't work.

    Then, I imagine it would be possible to find out whether WU looks there by stopping it and starting it while running ProcMon.

    It certainly does look there--repeatedly.  Here is a Count Occurrences on Path filtered by Path Contains WindowsUpdate after just doing a Check for updates after applying the two registry modifications advised by KB902093

    https://support.microsoft.com/en-us/help/902093/how-to-read-the-windowsupdate.log-file

    (BING search for
        windowsupdate.log verbose regedit site:support.microsoft.com
    )

    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace","64"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\BufferSize","1"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\Columns","4"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\DisableLogTrimming","10"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\Flags","5"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\GlobalFlags","4"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\Level","5"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\LogDir","5"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\LogFile","5"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\MaximumBuffers","1"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\MaximumFileSize","1"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\MaxLogFolderSize","1"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\MinimumBuffers","1"
    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\WPPLogDisabled","1"
    

    I don't know how to figure out what that achieves though.  There are only two things being written which I imagine would be the same ones written without having a higher "level" of trace being specified.  So, it may only be an anachronism that has been left in the code.

    "C:\Windows\Logs\WindowsUpdate\WindowsUpdate.20170401.164112.975.1.etl","1"
    "C:\Windows\System32\winevt\Logs\Microsoft-Windows-WindowsUpdateClient%4Operational.evtx","3"
    

    We might get a clearer idea of how much is still working by trying to use the redirect values and what is a WPPLOG anyway?

    OMG.  I think the verbose request may have had an effect on the formatter!  In that case I guess it could be comforting thinking that all those 1600- things might just be unformatted verbose entries and not necessarily critical information that was being obscured.   For example, in my  WindowsUpdate.log  I now see (uninteresting) lines like

    2017-03-26 09:08:21.6466610 1172  7692  Handler         CBS called Progress with state=2, ticks=200, total=1000

    (lots of them) which I cannot recall seeing before (but possibly where I had been seeing 1600- lines).

    I'm going to try this idea on my 15063 and try to arrange a more controlled test this time.   ; )



    Robert Aldwinckle
    ---

    Saturday, April 1, 2017 10:11 PM
  • Hi OffColour1972,

    "It's working with that update, but that does seem to imply that it will only work when running exactly the same updates that Microsoft expect you to have installed."
    So the Windows Update log is good after installing a later update, right?

    The Windows Update log is a known issue and it has been fixed in a Windows 10 update package. I didn`t know the exact one but it should be included in the latest update KB. To get a better performance of system, it is always recommended to keep the machine up to date.

    Anyway, I am glad installing the latest update worked.

    Best regards


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, April 3, 2017 6:23 AM
  • Yes, it's working with this update.

    I'm trying to keep them up to date but without being able to read the logs I couldn't fix WSUS to deploy the updates :D

    Tuesday, April 4, 2017 4:21 PM
  • Hi OffColour1972,

    I am glad to be of help and thanks for updating. Please remember to mark the helpful reply.

    Best regards


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, April 5, 2017 2:48 AM
  • Finally got this working by playing with the Level value in the Trace. Setting it to 9 was sufficient to get the level of detail I needed to find my WSUS problem.
    Wednesday, April 5, 2017 8:03 AM
  • I had this problem on a "disconnected" system, but not on a connected one.   Someone mentioned that all of the (I'll call them) "in between" builds and such won't necessarily have all of the their symbols files in the download packs available.

    So, to find what I needed, I downloaded and installed the Win10 WDK to get the debugging tools.  Specifically I needed symchk.exe

    On my disconnected computer I ran:
    symchk C:\Windows\System32 /om <outputfilepath>\<outputfilename.txt>

    What this does is it checks every file in the System32 directory to determine what symbols I need and creates an output list of them.  For Windows update specifically, you could probably do it specifically for the 6 items listed below and put them into the same output file

    wuaueng.dll
    wuauclt.exe
    wuapi.dll
    wuuhext.dll
    wuautoappupdate.dll
    storewuauth.dll

    Once I got the output file, I pulled it to a system that had internet access and ran the following command:

    symchk /im <outputfilelocation>\<outputfilename.txt> /s SRV*<locationforthesymbolstodownloadto>*https://msdl.microsoft.com/download/symbols

    What this command does is pretty much go out to Microsoft and fetch the symbols you need and put them in the <locationforthesymbolstodownloadto> location.

    Take the folder the symbols downloaded to, copy it off to your disconnected box and rerun your Get-WindowsUpdateLog cmdlet again with the -symbolserver parameter pointing to the location of those new symbol files, and viola.

    Hope this helps.

    • Proposed as answer by Rhasputin Thursday, May 4, 2017 11:44 AM
    Thursday, May 4, 2017 11:43 AM
  • Check and see if you have a Group Policy setting configured

    Do not connect to any Windows Update internet locations

    If this is configured, I know from experience it will nuke your ability to get to the Symbol server and Windows Store, as well as other Microsoft services.


    There's no place like 127.0.0.1

    • Proposed as answer by Matt5150 Tuesday, August 8, 2017 4:05 PM
    Monday, August 7, 2017 7:37 PM
  • Hello,

    Get-widnwosupdate might not work at times. make sure that you have latest vesion of windows updated on the server or machine.

    this command did not work on many machine with anniversary update as well.

    Regards,

    Nick.

     

    Monday, August 7, 2017 8:40 PM
  • Haha, I found the same thing on my disconnected system just before I read your reply. So I copied the files to my Windows 10 box (which is connected), and ran the powershell scripts. Utterly disappointing:

    2019/01/19 18:44:22.2598668 1096  4748  Unknown         Unknown
    2019/01/19 18:51:23.3119749 1096  7272  Unknown         Unknown
    2019/01/19 18:51:23.3355982 1096  7272  Unknown         Unknown
    2019/01/19 18:51:23.3355996 1096  7272  Unknown         Unknown
    2019/01/19 18:51:23.3356001 1096  7272  Unknown         Unknown
    2019/01/19 19:25:30.6650655 1080  2620  Unknown         Unknown
    2019/01/19 19:25:30.6652420 936   5840  Unknown         Unknown
    ….. <snip>

    I was able to run the symchk to download the symbols, and tried again. But I couldn't find a way to point Get-WindowsUpdateLog to the symbols folder.  Then I found a blog on a site showing that FormatFmt.exe can be used to set the output symbols folder. Unfortunately, there was a bug in the guy's script and one of the lines just errors out. I fixed the line and posted it at the bottom in the comments; don't forget to update that line!

    https://blogs.technet.microsoft.com/runcmd/get-windowsupdatelog-if-it-were-only-that-easy/

    So, step one: forget using Get-WindowsUpdateLog
    Step two; Read the blog using the link above
    Step three; gather the symbol files for the list Rhasputin put together above
    Step four; Run the script from the blog and point the symbols folders at the files you downloaded from the previous step.

    If you feel like you just got kicked in the teeth, you did! But hopefully you now have a log to show for it.





    • Proposed as answer by Brain2000 Sunday, January 20, 2019 2:03 AM
    • Edited by Brain2000 Sunday, January 20, 2019 2:06 AM
    Sunday, January 20, 2019 12:54 AM