Archive for the ‘Ereignisanzeige’ Category

Hyper-V Ereignisanzeige-Einträge erklärt

24 Januar 2018

Klappt bei einem Hyper-V etwas nicht, dann helfen auch mal die Ereigniseintragungen von Windows zur Problemlösung. Allerdings gibt es nicht einen, sondern je nach Problem verschiedene Eventlogs. Hier eine aktuelle Übersicht mit kurzen Beschreibungen für 2016: https://blogs.technet.microsoft.com/virtualization/2018/01/23/looking-at-the-hyper-v-event-log-january-2018-edition/

Hier noch die Verwendung in Powershell:

Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-VMMS
Get-WinEvent -ProviderName Microsoft-Windows-VHDMP

Ausgabe alle verfügbaren Hyper-V LogProvider (ok, VHDMP fehlt):

Get-WinEvent -ListProvider *hyper-v*

Noch kurz zur Verwendung der Cmdlets: Wenn man sich vertippt, erhält man diese Meldung:

PS> Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-GibtesNicht
Get-WinEvent : Auf dem Computer "localhost" wurde kein Ereignisanbieter gefunden, der "Microsoft-Windows-Hyper-V-GibtesNicht" entspricht.
In Zeile:1 Zeichen:1
+ Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-GibtesNicht
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Microsoft-Windows-Hyper-V-GibtesNicht:String) [Get-WinEvent], Exception
    + FullyQualifiedErrorId : NoMatchingProvidersFound,Microsoft.PowerShell.Commands.GetWin
EventCommand

Wohingegen, wenn man einen gültigen Ereignisanbieter verwendet, aber keine Ereigniseinträge vorhanden sind, diese Meldung erscheint:

PS > Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-Config
Get-WinEvent : Es wurden keine Ereignisse gefunden, die den angegebenen Auswahlkriterien entsprechen.
In Zeile:1 Zeichen:1
+ Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-Config
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (:) [Get-WinEvent], Exception
    + FullyQualifiedErrorId : NoMatchingEventsFound,Microsoft.PowerShell.Commands.GetWinEvent
Command

Werbeanzeigen

Feststellen welches Programm das Entfernen eines USB-Gerätes unter Windows verhindert

30 August 2017

Wenn man unter Windows USB Geräte abmeldet bzw. auswirft, kann es passieren, dass man mit dieser schönen Meldung beglückt wird:

—————————
Fehler beim Abdocken von "USB-Massenspeichergerät"
—————————
Das Gerät "USB-Massenspeichergerät" kann aufgrund eines unbekannten Fehlers nicht beendet werden. Entfernen Sie das Gerät nicht, solange es noch verwendet wird. Schließen Sie alle Programme, von denen das Gerät verwendet wird, und entfernen Sie es anschließend.
—————————
OK  
—————————

Unter Windows 7 sieht die Meldung etwas anders aus, ist aber genauso sinnlos:

—————————
Fehler beim Abdocken von "USB-Massenspeichergerät"
—————————
Dieses Gerät wird gerade verwendet. Schließen Sie alle Programme oder Fenster, die möglicherweise das Gerät verwenden, und wiederholen Sie den Vorgang.
—————————
OK  
—————————

Tja, “Unbekannte Fehler” sind des Benutzers liebste Fehler! Selbst heute in Zeiten von Windows 10 hat es Microsoft noch nicht geschafft diese Meldung mit mehr sinnvollen Informationen zu versehen und kommt immer noch so kryptisch wie zu Windows XP-Zeiten daher.

Aber dank Powershell kann der gequälte Anwender sich etwas mehr Informationen beschaffen. Zumindest bei Windows 7 bis Windows 10.

Get-WinEvent -ProviderName Microsoft-Windows-Kernel-PnP -MaxEvents 5 | where {$_.TimeCreated.Date -eq (Get-Date).Date -and $_.id -eq 225} | ft TimeCreated, Message –Wrap

Denn es werden in der Ereignisanzeige in Windows tiefergehende Informationen zum Vorgang gespeichert und damit kann man in der Regel den Grund für obige Fehlermeldung herausfinden. Man muss nur beim Microsoft-Windows-Kernel-PNP Provider nach der EventID 225 suchen.

In diesem Fall bekommt man z. B.:

TimeCreated         Message
———–         ——-
30.08.2017 17:33:47 Die Anwendung \Device\HarddiskVolume4\Windows\System32\cmd.exe mit der Prozess-ID                     21832 hat das Entfernen oder Auswerfen für das Gerät                     USB\VID_1E68&PID_0035\BB00000XXXXXXX beendet.

angezeigt. D. h. cmd.exe, also die Eingabeaufforderung, mit der ProzessID 21832 hatte Zugriff auf den USB-Stick und verhinderte dadurch das Auswerfen.

Windowsupdate.LOG unter Windows 10 lesen

6 Dezember 2015

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.

Ereignisanzeige Protokollnamen für Powershell übersetzen

28 Juli 2014

Durch den vorhergehenden Blogeintrag https://newyear2006.wordpress.com/2014/07/28/windows-store-konnte-die-computerlizenzen-nicht-synchronisieren-ergebniscode-0x80070490/ bin ich wieder mal über ein Problem gestolpert, dem ich schon häufiger begegnet bin, deshalb dieses Mal fürs löchrige Gehirn etwas ausführlicher.

Es ging um ein Problem, welches in der Ereignisanzeige mit dem Protokollnamen "Microsoft-Windows-Store-Licensing/Admin" erfasst ist. Möchte man nun diesen Event per Powershell ermitteln, passiert folgendes:

PS>Get-WinEvent -LogName Microsoft-Windows-Store-Licensing/Admin
Get-WinEvent : Auf dem Computer "localhost" wurde kein Ereignisprotokoll gefunden, das
"Microsoft-Windows-Store-Licensing/Admin" entspricht.
In Zeile:1 Zeichen:1
+ Get-WinEvent -LogName Microsoft-Windows-Store-Licensing/Admin
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Microsoft-Windows-Store-Licensing/Admin:String) [Get-WinEvent], Excepti
   on
    + FullyQualifiedErrorId : NoMatchingLogsFound,Microsoft.PowerShell.Commands.GetWinEventCommand

Gut, vielleicht kann man es auch mit Anführungsstrichen probieren? Leider bringt dies auch nichts. Microsoft-Windows-Store-Licensing steht jetzt auch nicht im Verdacht in der falschen Sprache angegeben zu sein oder?

Nächster Versuch, man könnte ja alles mit Namen *Licen* auflisten lassen:

PS> Get-WinEvent -ListProvider *licen*

Name     : Microsoft-Windows-Kernel-LicensingSqm
LogLinks : {}
Opcodes  : {}
Tasks    : {}

Name     : Microsoft-WS-Licensing
LogLinks : {Microsoft-WS-Licensing/Diagnostic, Microsoft-WS-Licensing/Debug, Microsoft-WS-Licensing/Admin}
Opcodes  : {win:Start, win:Stop}
Tasks    : {Service_Init, Service_Stop, Service_Init_LicenseStore, Service_Init_HwidCollect…}

Name     : Microsoft-Windows-Kernel-Licensing-StartServiceTrigger
LogLinks : {}
Opcodes  : {}
Tasks    : {}

Sieht auch nicht sehr ergiebig aus. Wobei Microsoft-WS-Licensing geht ja in die Richtung, wenn WS für Windows Store stehen würde:

PS > (Get-WinEvent -ListProvider *licen*).Loglinks

LogName                          IsImported DisplayNam
——-                           ———- ———
Microsoft-WS-Licensing/Diagnostic      False
Microsoft-WS-Licensing/Debug           False
Microsoft-WS-Licensing/Admin           False

OK, es ist kein Displayname eingetragen, also wird es das auch nicht sein. Oder vielleicht doch? Ich bin ja immer noch der Meinung, WS steht für Windows Store. Da Powershell teilweise immer etwas Daten vor einem verheimlicht, lasse ich mir alle Daten zu einem Objekt ausgeben:

Get-WinEvent -ListProvider *licen*| fl *

Siehe da, hier gibt es auch ein Displayname Feld. Also mal dieses ausgeben lassen:

PS> (Get-WinEvent -ListProvider *licen*).displayname
Microsoft-Windows-Store-Licensing
Microsoft-Windows-LicensingStartServiceTrigger

Ah da isses ja. Der gesuchte Microsoft-Windows-Store-Licensing-Protokollname. Deutlicher wird es damit:

PS C:\Windows\system32> (Get-WinEvent -ListProvider *licen*)| select displayname, providername| fl

DisplayName  :
ProviderName : Microsoft-Windows-Kernel-LicensingSqm

DisplayName  : Microsoft-Windows-Store-Licensing
ProviderName : Microsoft-WS-Licensing

DisplayName  : Microsoft-Windows-LicensingStartServiceTrigger
ProviderName : Microsoft-Windows-Kernel-Licensing-StartServiceTrigger

Es geht halt nichts über eine ordentliche Übersetzung! Übrigens wäre es auch noch einfacher gegangen. Einmal über die GUI-Methode, indem man beim betreffenden Protokolleintrag sich die Details anzeigen lässt und dann System erweitert. Dort taucht dann unter Provider ebenso wieder “Microsoft-WS-Licensing” auf.

Man kann nun also mittels

Get-WinEvent -LogName Microsoft-WS-Licensing/Admin -MaxEvents 10

eine schöne Auflistung der Fehler erhalten.

DxpTaskRingtone Fehlermeldung beim Öffnen der Administrativen Ereignisse nach Update auf Windows 8.1

25 November 2013

Uahh, diese Schmerzen! Der Pfuscherverein MS hatte es ja sooo wichtig sein Update auf Windows 8.1 möglichst lange hinterm Berg für die Allgemeinheit zu halten, damit möglichst viele Bugs unerkannt in die Releaseversion kommen.

Aktuelles Beispiel, die tolle Fehlermeldung:

Mindestens ein Protokoll in der Abfrage enthält Fehler.

erscheint beim Aufruf der Ereignisanzeige, wenn man auf Administrative Ereignisse klickt. Das Problem taucht nur nach einem Upgrade von Windows 8 auf Windows 8.1 auf. Ob 32-Bit oder 64-Bit spielt keine Rolle. Ein Bild der Meldung ist in diesem Thread unten zu sehen: http://answers.microsoft.com/de-de/windows/forum/windows_8-performance/windows-81-defrag-optimierung/1dc8894d-91b8-43df-b652-9b872484479d#4

Was kann man tun?
Abwarten und Tee trinken, bis MS sich herablässt seine Schrottsoftware zu fixen. Naja, da die Mädels von MS das Problem aber zum heutigen Zeitpunkt noch nicht mal in der Knowledge Base dokumentieren, kann dies noch lange dauern.

Also pfuscht man etwas an der Registrierung herum. Zuerst macht man als Admin ein ordentliches Backup:

reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-DxpTaskRingtone/Analytic"  DxpTaskRingtone-Sicherung.REG

Die DxpTaskRingtone-Sicherung.REG sollte man nun gut aufheben. Anschließend löscht man den Eintrag mittels

reg delete  "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-DxpTaskRingtone/Analytic"

Und jetzt sollte man immer dran denken, dass wenn in den 10000 Fällen, wo die nächsten Jahre ein Update für Windows 8.1 fehlschlägt, dass man die Registry manipuliert hatte!!!! Hoffen, dass es keine Probleme damit gibt, lässt mich die Tatsache, dass bei einer Neuinstallation von Windows 8.1 dieser Key gar nicht vorhanden ist.

Zum Nachschauen, wie der aktuelle Status ist, verwendet man:

reg query  "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-DxpTaskRingtone/Analytic"

Als neugieriger Mensch hab nun MSDN.COM und TECHNET.COM befragt, was denn DxpTaskRingtone überhaupt darstellt aber es war leider nix zu finden.