none
WindowsUpdateLog - No Format Information found RRS feed

  • Вопрос

  • Hi,

    On allmost every Windows 10 machine I have problems when reading WindowsUpdateLog.

    I run the command from an administrative prompt "Get-WindowsUpdatelog" and it generates the log and dump it to desktop, but the information in this file is like this...

    1601.01.01 01:00:00.0000000 692   5220                  Unknown( 31): GUID=c232d8d6-c0ba-3f2d-4ee0-3c6f4b234595 (No Format Information found).
    1601.01.01 01:00:00.0000000 692   5220                  Unknown( 18): GUID=d8f4d644-6ec0-4f3d-fa7c-f0d0a5b120ae (No Format Information found).
    1601.01.01 01:00:00.0000000 692   5220                  Unknown( 13): GUID=4bc2bc11-e128-512d-d523-8da29c6efcde (No Format Information found).
    1601.01.01 01:00:00.0000000 692   5220                  Unknown( 30): GUID=fa7f9ca7-a9ca-7c9a-be26-0e9e978abc58 (No Format Information found).
    1601.01.01 01:00:00.0000000 692   5220                  Unknown( 75): GUID=660c3846-d8b2-5440-48f2-9b67dac5f6cf (No Format Information found).
    1601.01.01 01:00:00.0000000 692   5220                  Unknown( 56): GUID=660c3846-d8b2-5440-48f2-9b67dac5f6cf (No Format Information found).
    1601.01.01 01:00:00.0000000 692   5220                  Unknown( 25): GUID=fa7f9ca7-a9ca-7c9a-be26-0e9e978abc58 (No Format Information found).
    1601.01.01 01:00:00.0000000 692   5220                  Unknown( 11): GUID=4bc2bc11-e128-512d-d523-8da29c6efcde (No Format Information found).

    I have upgraded to the latest version 1511 and its the same problem here...
    I have tried to delete everything under %temp%\windowsupdatelog folder but same problem.

    Suggestions ?

    /Regards Andreas

    24 февраля 2016 г. 9:06

Ответы

  • Hi,

    This method is working.
    Not really user friendly but at least you have readable information at the end. 

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

    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

    24 февраля 2016 г. 16:06
  • Ok... I found the problem.

    Using only the local Symbols folder will only work on a fresh and never updated Windows 10.
    3 DLL have been replaced by different updates so they don't match the .PDB file in the Symbols folder.
    That's why you can't decrypt the logs correctly.

    I've tested with a VM updated with Windows Update to I have the latest fixes.

    Here's the updated DLL: storewuauth.dll, wuauclt.dll and wuaueng.dll

    Can you add these folders into your local Symbols folder then test again?

    http://1drv.ms/1TOmEYi

    Gerald

    • Помечено в качестве ответа Andreas2012 1 марта 2016 г. 21:10
    1 марта 2016 г. 14:00

Все ответы

  • I get the same result latest Insider build and have seen this posted a couple of times now. Can find any of them now but WindowsUpdate.log Changes discusses the files but with no solution. Also check on the Enterprise LTSB so 10240 and the same entries in there. Also mentioned a couple of time in the Feedback app and has votes.

    Only thing I noticed was doing a find for all lines with 2016 did at least separate that information.

    24 февраля 2016 г. 13:47
  • Hi,

    This method is working.
    Not really user friendly but at least you have readable information at the end. 

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

    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

    24 февраля 2016 г. 16:06
  • Suggestions ?

    I guess you are on a preview build?  Me too.  The basic build 10586.104 still works fine.

    So, looks like we really need to do this sort of stuff after all...

    http://answers.microsoft.com/en-us/windows/forum/windows_10-update/windowsupdatelog-unreadable/2e6b05ed-ac91-4186-a362-c6b5a7e42911

    https://chentiangemalc.wordpress.com/2015/09/03/debugging-viewing-windows-update-log-on-windows-10-insider-builds/

    I must confess that I have only looked with interest at the procedure described there, not actually done it.  My tack would still be to try to convert the calls that Get-WindowsUpdateLog makes to tracerpt.exe to ones which use tracefmt.exe the way the OP in the above thread was trying

    http://answers.microsoft.com/en-us/windows/forum/windows_10-update/windowsupdatelog-unreadable/2e6b05ed-ac91-4186-a362-c6b5a7e42911?page=4&msgId=ea9d5728-3d09-4d37-a8c5-cea72466b5fe 

    but I haven't done that either.

    Another possibility might be feeding some variation of those inputs to NetMon.  I have had some surprisingly readable results from it for Windows .etl data.

    Good luck



    Robert Aldwinckle
    ---

    25 февраля 2016 г. 5:27
  • Hi Andreas2012,

    I have checked the log on my machine, it shares the same symptom as yours.

    Best regards


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




    25 февраля 2016 г. 8:33
    Модератор
  • This problem can occurs with 10586 also if you can't access correctly the Microsoft Internet Symbol Server.
    Get-WindowsUpdateLog use this server by default if you don't specify a new location with
    -SymbolServer.
    The PowerShell command doesn't report an error but is unable to "decrypt" the log.

    Ok... Got the command working with local symbols:

    Get-WindowsUpdateLog -SymbolServer C:\symbols -LogPath C:\Temp\WU.log

    Gerald



    25 февраля 2016 г. 8:44
  • Hi,

    I have done some testing, and it seems like the clients have to be online for the "get-windowsupdatelog" to work for the first time, since it then download the symbols or something. Because our clients are offline, and when I have a clean installed windows 10 machine, and rung "get-windowsupdatelog" it fails with the same problem. If I connect the client to internet and run the same command, you are asked to agree to the symbols box... then i guess it download something. If we then disconnect the client from the internet it works.... Why is it like this, we cant have all the clients first connect to the internet and then run the command, then disconnect, and we cannot download the symbols on every client either.

    Anyone else could reproduce the problem....

    Thanks for reply.


    /Regards Andreas

    1 марта 2016 г. 8:07
  • Hi,

    There's a simple solution for that.

    1. Download the Symbols of your Windows 10 release from Microsoft: https://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx
    2. Install them on a computer (Default install goes to C:\Symbols)
    3. Copy the C:\Symbols folder on a server then share it
        If you don't want to copy the entire folder (5Gb), you can only copy these on the share

    4. Use the command from your clients: Get-WindowsUpdateLog -SymbolServer \\Server01\Win10\Symbols\10586

    Gerald



    1 марта 2016 г. 8:47
  • Hi,

    I tried it but it does not work.

    I have Version 10.0 Build 10240, and I have download both the following files, and exctracted them and pointed to both to see if anyone is better than the other..

    Windows_TH1.10240.16384.150709-1700.x64FRE

    Windows_TH1.10240.16384.150709-1700.x64CHK

    I have tried to point to local path, and also tried to share it. But it just runs through and same information. Do I need to remove anything else, cache or something that causes this to happen ?

    Thanks for reply.


    /Regards Andreas

    1 марта 2016 г. 9:16
  • It seems that, once Windows has successfully used the local Symbols or the Microsoft Server, it can "decrypt" the log.

    I'll reinstall a new VM to test. Keep you informed.

    Gerald

    1 марта 2016 г. 10:15
  • Yes thats correct :) hope for a success reply :)


    /Regards Andreas

    1 марта 2016 г. 10:23
  • Ok... I found the problem.

    Using only the local Symbols folder will only work on a fresh and never updated Windows 10.
    3 DLL have been replaced by different updates so they don't match the .PDB file in the Symbols folder.
    That's why you can't decrypt the logs correctly.

    I've tested with a VM updated with Windows Update to I have the latest fixes.

    Here's the updated DLL: storewuauth.dll, wuauclt.dll and wuaueng.dll

    Can you add these folders into your local Symbols folder then test again?

    http://1drv.ms/1TOmEYi

    Gerald

    • Помечено в качестве ответа Andreas2012 1 марта 2016 г. 21:10
    1 марта 2016 г. 14:00
  • Hi,


    So I download the file, it contains pdb files and not dll files, but guess thats what you meant ?

    If I copy these directories into the excisting directories, then there will be two folders there, but same problem.

    C:\Symbols2\storewuauth.pdb\5A9142A09775486CB3053E2D6D6A7B6F1\storewuauth.pdb  (Old)

    C:\Symbols2\storewuauth.pdb\257F67B52E884E9F82AC2F0A24DB17971\storewuauth.pdb  (New)

    .....


    If I copy these files into the existing directory structure, same problem.

    C:\Symbols2\storewuauth.pdb\5A9142A09775486CB3053E2D6D6A7B6F1\storewuauth.pdb  (New)

    I may do something wrong here, so please explain :)




    /Regards Andreas

    1 марта 2016 г. 19:54
  • You probably don't have the same version of dll than mine

    Yes, it only contains .PDB which are the symbols of the running files of Windows.
    You can have multiple folders of the same file, Windows will only use the one that match the file in System32.

    So if there's no match, it can't decrypt the .ETL correctly.

    I also found that, even when using the Symbol Server with my updated VM, there's still information that are not correct in the WindowsUpdate.log

    Gerald

    1 марта 2016 г. 19:56
  • Hi,

    Ok, thanks for trying :) So could this be a bug, I guess it should not work like this. Better before when you just had a txt file, seems like a step back this solution :(


    /Regards Andreas

    1 марта 2016 г. 20:55
  • Not a bug but like other features on Windows 10, only ment to be used with a full Internet access and not within an enterprise behind firewalls, proxy, etc... Need more tuning in Redstone ^^
    1 марта 2016 г. 21:09
  • Hehe, to bad...

    Thanks for followup.


    /Regards Andreas

    1 марта 2016 г. 21:11
  • not within an enterprise behind firewalls, proxy, etc...

    Then he should be able to download the Symbols and use the Get-WindowsUpdateLog  -SymbolServer  pointer.  FWIW I think the cmdlet is working fine for my 10586.104.  The problem is only on the Fast-ring side, e.g. build 14271.

    Ah. I just visited the manual Symbol server.  It stops at November.  So how are we getting anything more current?  Can it be saved somehow?  Otherwise it still looks like we would need to be using the chkmatch tool that chentiangemalc was demonstrating for preview builds.

    I'll try doing some ProcMon tracing to understand this.



    Robert Aldwinckle
    ---


    1 марта 2016 г. 21:25
  • not within an enterprise behind firewalls, proxy, etc...
    Then he should be able to download the Symbols and use the Get-WindowsUpdateLog  -SymbolServer  pointer.  FWIW I think the cmdlet is working fine for my 10586.104.  The problem is only on the Fast-ring side, e.g. build 14271.


    Robert Aldwinckle
    ---

    It's logic that 14271 doesn't have available Symbols online. Maybe if it goes to Slow, Microsoft will provide them.

    By default, the command wants to connect to the Microsoft Symbol Server. -SymbolServer is to use a local copy of the Symbols but this needs to be updated each time a dll is replaced by a patch... And this test was on a 10586 VM.

    And you can see here that it's still missing information in the WindowsUpdate.log, even when using the Microsoft Symbol Server.

    Gerald

    1 марта 2016 г. 21:48
  • My bad for the screenshot, this was the beginning of the log using 10586.63 version of WU.
    Latest doesn't shows the translation errors ;-)
    1 марта 2016 г. 21:54
  • After alot of banging my head against the wall i got it working on a "disconnected" system.  Someone mentioned that the "in-between" releaeses may not have all of 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.

    • Предложено в качестве ответа Rhasputin 4 мая 2017 г. 11:52
  • Microsoft Employee Number 1: "Hey, you know how currently we just write Windows Update issues to a log file that anybody can open in notepad and debug?"

    Microsoft Employee Number 2: "Yeah. Plain text. So lame"

    Microsoft Employee Number 1: "Well, that's not cool enough for Windows 10. I came up with a new method where people won't even be able to start debugging until they visit TechNet to read some forum/blog posts, and on top of that they need to download and install an 896MB symbols package! Even then they will have massive issues!"

    Microsoft Employee Number 2: "We really ARE becoming more like Linux, yeah boy!"

    • Предложено в качестве ответа Geo Perkins 18 июня 2019 г. 1:42
  • Ok have stopped laughing at the above post now. Wow that makes it sound planned, hmm.

    Anyhow thought I would try pointing the command to online symbol and appears good;

    Get-WindowsUpdateLog -SymbolServer http://msdl.microsoft.com/download/symbols -LogPath C:\Temp\WU.log

    Ok if you have a half decent net connection and saves the manual download.

    5 июня 2017 г. 18:03
  • Ok have stopped laughing at the above post now. Wow that makes it sound planned, hmm.

    Anyhow thought I would try pointing the command to online symbol and appears good;

    Get-WindowsUpdateLog -SymbolServer http://msdl.microsoft.com/download/symbols -LogPath C:\Temp\WU.log

    Ok if you have a half decent net connection and saves the manual download.

    i have windows 10 1511 upgraded to 1607 with all comunlative 14393.1358 only few rows are read also with network server , i think is a problem of ugraded w10
    16 июня 2017 г. 9:54
  • That didn't help att for me.

    I downloaded the symbol package and installed it, but the Windows Update Log file on my desktop has only "No information found" entries.


    OS: 1607 (14393.1770)
    • Изменено DenLei 26 октября 2017 г. 13:33
    26 октября 2017 г. 13:31
  • This has reminded me to test on 17025.1000.  A new symptom:

    Get-ChildItem : A parameter cannot be found that matches parameter name 'Directory'.

    and more.

    In fact, I am seeing that in  15063.674 too. 

    In any case, neither work as expected.  Less GIGO in the new one.  Perhaps they are trying to put a sanity check in it?



    Robert Aldwinckle
    ---

    26 октября 2017 г. 17:03
  • I wish, I knew...

    All I can say is: The CmdLet Get-WindowsUpdateLog doesn't work on several clients. I only see this:

    1601.01.01 01:00:00.0000000 1204  2428      Unknown( 119): GUID=2fc03aa6-a1fa-3d0c-ba09-b8539ec28a26 (No Format Information found).

    on 1607 and 1703.

    From my prospect I quite heavy thing, when even the log files for failing windows updates cannot be checked.

    The big thing is: I cannot provide 1703 on WSUS (Win 2012 R2). All client end up in 0x8000FFFF and further are unavailable in these logs.

    26 октября 2017 г. 18:57
  •  test on 17025.1000.  A new symptom:

    It's working perfectly?  All I did is try to trace it with ProcMon.  My guess would be that something changed on the symbol server.  15063.674 is still broken but now I have two similar traces to try to compare.  Or perhaps just wait and see if something changes for that case too?  Who knows?


    Robert Aldwinckle
    ---

    26 октября 2017 г. 22:20
  • Yeah, who knows ;-)

    After I finally made the update to 1709 run by WSUS (Win 2012 R2), I see Get-WindowsUpdateLog is working fine (Build: 16299.15). Timestamps and Symbols are in perfect condition.

    27 октября 2017 г. 15:42
  • (Build: 16299.15). Timestamps and Symbols are in perfect condition.

    What I noticed by comparing my two cases is that in the newer one there is no hint of PDB.  So that is in a preview.  Please check yours to see if that is your case too in the FCU.  Here's a method to compare:   (Get-Command Get-WindowsUpdateLog).ScriptBlock | clip  Then Paste into an ISE script tab.   Notice that doing Finds for  Sym  don't work?  More significantly, I think, ProcMon isn't finding any PDB references with it at all?  I'm still trying to figure out what all is different now.  I tried using the -SymbolServer operand to nullify a search for symbols but that didn't change the symptom.  YMMV.

    A related thing to ask about is what if we get some WindowsUpdate .etl files from someone (e.g. you on your FCU getting files from someone who is still CU).  What is the facility for handling that case?  This just made me realize that I should try doing that myself!  What could go wrong?  TBD.



    Robert Aldwinckle
    ---

    27 октября 2017 г. 16:48
  • Will check it for you on Monday.
    • Изменено DenLei 27 октября 2017 г. 17:10
    27 октября 2017 г. 17:09
  • trying to figure out what all is different now.

    I think the .etl records themselves have changed.  Message Analyzer likes them now!


    Robert Aldwinckle
    ---

    27 октября 2017 г. 17:14
  • Hello,

    Windows 10 1709 made changes so the log should update without access to the symbols.


    Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    27 октября 2017 г. 21:52
  • I absolutely agree! All clients I checked deliver decent results with Get-WindowsUpdateLog running 1709.
    27 октября 2017 г. 22:09
  • 1607: Ony 2 hints  for Symbols found:

    1.) param definition for external MS source (http://msdl.micrsoft.com/downloads/symbols

    2.) It's used while call of ConvertETLsToLog.

    29 октября 2017 г. 15:13
  • Same in 1703.
    29 октября 2017 г. 15:15
  • the format of windows update log was indeed changed in the creators update, so there should no longer be a problem: Improved Windows Update Log Formatting with Windows 10 1709
    29 октября 2017 г. 15:50
  • @ EckiS

    Thanks for the link.  I think someone should tell the users asking for "real-time" text to try using Message Analyzer.  Then why do we need the PowerShell cmdlet now?  Hmm... I guess I will have to keep Get-WindowsUpdateLog for now, at least until I figure out how to make Message Analyzer more usable for this scenario.  ETW for WindowsUpdateClient is not one of the provided scenarios unfortunately.



    Robert Aldwinckle
    ---

    29 октября 2017 г. 17:26
  • My 1607 W10 14393.2068 machine does process symbols OK

    So I copied c:\windows\symbols to standalone (no internet connection, only local LAN) machine's c:\windows\symbols, same 1607 - 14393.2068

    Could not get it to decode the logs

    Of course as stated previously Download Windows Symbol Packages was of no use at all!

    Seb

    16 февраля 2018 г. 13:56
  • @scerazy: as was already mentioned in this thread: that is only fixed in 1709.
    so no wonder it does not work on 1607.
    16 февраля 2018 г. 15:06
  • @EckiS

    Not really the case, as above Rhasputin explained what to do.
    I will test in later, as my originbal test simply did omit -symbolserver switch (I assumed that c:\windows\symbols would be used by default, which is not the case)!

    Seb


    17 февраля 2018 г. 8:44
  • The most awful Microsoft service is update services no matter it is client side or server, nor Windows or Office, nor 2000 version or 2019, nor you work with update logging or updating process itself or even WSUS api .



    • Изменено harsini 2 июля 2019 г. 3:52