Windowsupdate.LOG unter Windows 10 lesen


MS hat mal wieder ein Zwangsverbesserung angestoßen und damit vieles wieder komplizierter gemacht. Konnte man früher einfach die Windowsupdate.LOG-Datei aus C:\Windows im Notepad einsehen, so findet man nun den Hinweis:

Windows Update logs are now generated using ETW (Event Tracing for Windows).
Please run the Get-WindowsUpdateLog PowerShell command to convert ETW traces into a readable WindowsUpdate.log.

For more information, please visit http://go.microsoft.com/fwlink/?LinkId=518345

Ich kann mir den Grund schon denken, warum die Umstellung gemacht wurde, nämlich wegen Performance und der Dateifragmentierung vorzubeugen. Vor allem auf Windows IoT Geräten ist immer zu wenig Platz, also warum dann nicht ein bewährtes Format verenden, welches eh Log-Dateien im Zaum hält.

Als bekennender Powersheller hab ich auch kein Problem mit Commandlets, aber wenn dann weite Teile der daraus erzeugten Log-Datei dann so aussieht?

1601.01.01 01:00:00.0000000 1040  13164                 Unknown( 10): GUID=fceb5510-7e12-22d8-8d1b-e6a079483552 (No Format Information found).
1601.01.01 01:00:00.0000000 1040  13164                 Unknown( 26): GUID=464bbb57-7e12-b0a1-8d1b-e6a079483552 (No Format Information found).
1601.01.01 01:00:00.0000000 1040  13164                 Unknown( 10): GUID=fceb5510-d1b3-b0a1-23ef-338952442d14 (No Format Information found).

Wo ist hier der Informationsgehalt?

Wenn es nur Teile betrifft, kann man sich mittels dieses Aufrufs eine einfachere Update.Log erstellen:

Get-Content "$env:USERPROFILE\Desktop\Windowsupdate.log"|Select-String -Pattern "1601.01.01 01:00:00.0000000*" -NotMatch |Set-Content "$env:USERPROFILE\Desktop\Windowsupdate_Clean.log"

Damit erhält man die unsinnigen Fragmente ausgefiltert und die relevanten Daten in Windowsupdate_Clean.log gespeichert. Hier bei den Kommentaren lassen sich einige zum Thema aus: https://technet.microsoft.com/en-us/library/mt238376.aspx.

Leider hat auch Windows 10 V1511 das Problem mit den falschen bzw. unnötigen LOG-Einträgen.

Wer jetzt denkt, er wäre clever und könnte direkt die Inhalte aus den EWT-Dateien auslesen, denn schließlich gibt es ja noch die Funktion Get-WinEvent, welche EWT-Dateien lesen kann, wird ernüchtert feststellen, dass dem nicht so ist. Der Inhalt der mittels EWT erfassten Daten wird in Dateien mit der Endung .ETL gespeichert.

Beim Aufruf von z. B.

Get-WinEvent -Path C:\Windows\logs\WindowsUpdate\WindowsUpdate.20151206.160438.596.1.etl -Oldest

bekommt man genauso das belanglose Geschwafel wie in der erzeugten Windowsupdate.LOG-Datei. Ist das womöglich ein genereller Bug?

Ein weiterer Artikel zum Format und was man damit machen kann und wo auch auf den Symbolserver eingeht: http://blogs.technet.com/b/charlesa_us/archive/2015/08/06/windows-10-windowsupdate-log-and-how-to-view-it-with-powershell-or-tracefmt-exe.aspx.

Advertisements

5 Antworten to “Windowsupdate.LOG unter Windows 10 lesen”

  1. Quirel Says:

    In einem Fall hat die Angabe von -SymbolServer https://msdl.microsoft.com/download/symbols beim Aufruf von Get-WindowsUpdateLog geholfen die Unknown Einträge wegzubekommen! Wenn es beim ersten Mal nicht klappt einfach Get-WindowsUpdateLog nochmal aufrufen.

  2. Quirel Says:

    Noch zwei hilfreiche Aufrufe zur Fehlersuche

    get-content „$env:USERPROFILE\Desktop\WindowsUpdate.log“ | Select-String -SimpleMatch „driver“

    notepad „$env:USERPROFILE\Desktop\WindowsUpdate.log“

    So kann man feststellen, was alles in letzter Zeit heruntergeladen und dann wahrscheinlich auch installiert worden ist:

    get-content „$env:USERPROFILE\Desktop\WindowsUpdate.log“ | Select-String -SimpleMatch „.download.“

  3. Quirel Says:

    Weil es gerade so schön passt, hier noch eine Beschreibung, wie man Treiber los wird und neu installieren kann: https://blogs.msdn.microsoft.com/danchar/2015/05/29/whats-the-direct-url-for-a-windows-update-driver/

  4. Quirel Says:

    Hier neues zum Thema bei v1709: https://blogs.technet.microsoft.com/mniehaus/2017/10/10/improved-windows-update-log-formatting-with-windows-10-1709/

  5. Quirel Says:

    OK ein weiterer Versuch etwas Klarheit zu bekommen. Obige Angabe mit dem Symbolserver kann man sich sparen, denn laut Source von Get-WindowsUpdateLog mittels Get-Content function:Get-WindowsUpdateLog verweist der Standardwert von -Symbolserver bereits auf die URI https://msdl.microsoft.com/download/symbols.

    Wo werden nun die Symbole gespeichert? Es gibt einen Ordner unter C:\Windows\Symbols dort finden sich die Symboldateien wieder. Allerdings wird bei neueren Versionen dieser Ordner nicht benutzt, statt dessen finden sich die Symboldateien in $env:TEMP\WindowsUpdateLog\SymCache, was z. B. diesen Pfad ergeben kann: C:\Users\admin\AppData\Local\Temp\WindowsUpdateLog\SymCache.

    Wenn es nicht klappt, dann kann einem SymChk.exe aus dem Windows WDK helfen. Hier eine Beschreibung, was zu tun ist: https://social.technet.microsoft.com/Forums/en-US/6da44666-4e4b-48e2-bc93-7d7430860dc3/server-2016-windows-update-logs-getwindowsupdatelog?forum=ws2016. Das Windows WDK ist hier zu finden: https://developer.microsoft.com/de-de/windows/hardware/windows-driver-kit.

    In diesem Zusammenhang ist noch wichtig, dass der Parameter -Symbolserver bei Windows 10 v1709 nicht mehr verfügbar ist!

    Interessant dabei ist, dass im Sourcecode bei v1703 im Pfad C:\WINDOWS\System32\WindowsPowerShell\v1.0\Modules\WindowsUpdate in der Datei WindowsUpdateLog.psm1 noch explizit der Symbolserver auftaucht, bei v1709 allerdings nicht mehr.

    Im Grunde wird von den Powershell-Funktionen nur das Commandline-Tool Tracerpt.exe aufgerufen, welches die eigentliche Verarbeitung übernimmt. Das Powershell drumherum ist nur dazu da, dass tracerpt nicht überladen wird (max. 10 ETL-Dateien bei einem Durchgang, deshalb auch immer die komische Ausgabe bei Aufruf von Get-WindowsUpdateLog) und am Ende wird aus der CSV bzw. XML-Datei welche von tracerpt erstellt wurde eine lesbare TXT-Datei erstellt.

    Übrigens werden eigentlich nur die PDB-Dateien für die Dateien wuaueng.dll
    wuauclt.exe
    wuapi.dll
    wuuhext.dll
    wuautoappupdate.dll
    storewuauth.dll
    benötigt, weil nur diese beim Updatevorgang in die Eventlog schreiben.

    Hier noch die aktuelle, offizielle Seite wo man die Symboldateien direkt herunterladen kann: https://developer.microsoft.com/en-us/windows/hardware/download-symbols. Ansonsten benötigt man obige Symchk.exe-Geschichte.

    Hier noch die Doku zum Symbolserverdownloadstring
    https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/microsoft-public-symbols, wenn hier immer die Rede von srv*DownstreamStore*https://msdl.microsoft.com/download/symbols ist, dann muss man DownstreamStore durch ein eigenes Directory ersetzten also z. B. so: srv*C:\Symbols*https://msdl.microsoft.com/download/symbols.

    Noch eins: laut dieser Seite gibt es noch Tracefmt: https://blogs.technet.microsoft.com/charlesa_us/2015/08/06/windows-10-windowsupdate-log-and-how-to-view-it-with-powershell-or-tracefmt-exe/

    Übrigens ist in der aktuellen Fassung von Get-WindowsUpdateLog noch immer der Parameter -Symbolserver genannt: https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps

    Alles ziemlich aufwändig! Ich würde sagen, da ist mal wieder ordentlich geschlampt worden!

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

w

Verbinde mit %s


%d Bloggern gefällt das: