Windows: Ein Bug in winevtutil

[English]Ein Blog-Leser hat mich bereits Mitte Juni 2019 auf einen doofen Bug in winevtutil hingewiesen. Ich stelle mal die Details dazu hier im Blog zur Information ein.

Was ist winevtutil?

Bei winevtutil handelt es sich um ein Tools für die Kommandozeile (Eingabeaufforderung) von Windows, mit dem man Informationen zu Ereignisprotokollen abrufen kann. Dieser Befehl dient auch zum Installieren und Deinstallieren von Ereignismanifesten, um Abfragen auszuführen, und zum Exportieren, Archivieren und Löschen von Protokollen. Microsoft hat das Tool in diesem Artikel dokumentiert.

Problembericht des Blog-Lesers

Blog-Leser Dalai kontaktierte mich Mitte Juni 2019 per Mail, um auf einen Bug im Befehl hinzuweisen.

ich bin kürzlich auf einen Bug in einem Windows-Tool gestoßen, und ich kann sonst im Netz keine Anhaltspunkte dazu finden, dass dieser Bug jemand anderem innerhalb der vergangenen 12 Jahre aufgefallen ist, und das öffentlich gemacht hätte. Da man für den Feedback-Hub ja ein Microsoft-Konto benötigt, ich aber keines habe (und auch keines möchte), hoffe ich, Sie könnten das Problem auf irgendeine Weise an Microsoft herantragen. Vielleicht können Sie auch darüber bloggen.

Konkret geht es um das Konsolentool wevtutil.exe. Dessen langer Parameter reversedirection funktioniert nicht, und hat auch noch nie funktioniert seit das Tool mit Vista eingeführt wurde.

Ich habe es unter Vista, Win7, Server 2012 R2 und Win10 1809 getestet –
nirgendwo wird der Parameter angenommen. Konkretes Befehls-Beispiel, das jeder selbst testen kann:

wevtutil qe Application /c:1 /f:text /reversedirection:true

Das führt nur zur Fehlermeldung:

> Invalid option reversedirection. Option is not supported. The
> parameter is incorrect.

bzw. auf Deutsch

> Ungültige Option "reversedirection". Die Option wird nicht
> unterstützt. Falscher Parameter.

Und das obwohl der Parameter exakt so in der Hilfe steht, siehe
wevtutil qe /?.

Die kurze Form des Parameters funktioniert einwandfrei:

wevtutil qe Application /c:1 /f:text /rd:true

Nun habe ich mich in der EXE etwas umgesehen – es lebe Sysinternals Strings ;) – und festgestellt, dass der Parameter zweifach auftaucht, einmal als reversedirection und einmal als reversdirection (also ohne zweites e).

Benutzt man den Parameter in der Form ohne e, kommt zwar keine Fehlermeldung, aber der Parameter hat keine Wirkung, d.h es wird das älteste Ereignis statt des neusten ausgegeben.

Fun fact: In einem von Microsoft selbst hochgeladenen Beispiel-Code für ein abgespecktes Programm namens ReadEvents sieht es richtig aus (Zeilen 97/98)

Wer sich jetzt fragt, warum der Blog-Leser das überhaupt anspricht, wo doch die
Kurzform des Parameters funktioniert. Der Blog-Leser schrieb mir: Ich verwende in Skripten vorzugsweise die Langformen von Parametern (sofern verfügbar), da diese
sehr oft eine eindeutige Aussage darüber zulassen, was ein Parameter tut, ohne erst in die Hilfe schauen zu müssen. Zudem ist er der Meinung, dass nicht jeder Bug 20 Jahre rumliegen muss, bevor er behoben wird ….

Ich hatte dann noch nachgefragt, ob auch die englischsprachige Fassung des Tools betroffen sei.

GB> Wissen Sie, das Problem nur in einem deutschen Windows
GB> zu finden ist- oder auch in englischen Varianten?

Die Antwort lautete:

Ich habe es auch in einem englischen Windows 7 getestet, das Problem ist dort ebenfalls vorhanden. Ist mehr oder weniger auch logisch, denn die EXE ist dieselbe, nur die Sprachdateien (*.exe.mui) unterscheiden sich. Und die Problemursache liegt sehr wahrscheinlich in der EXE, wie die Untersuchung derselben zeigte. Das Problem ist also sprachunabhängig bzw. betrifft sämtliche Sprachen.

Außerdem sind auf 64-bit Windows beide EXEn betroffen, also die in 64-bit
EXE in \Windows\System32 und die 32-bit EXE in \Windows\SysWOW64.

An dieser Stelle mein Dank an den Blog-Leser für den Hinweis. Muss mal schauen, wie ich das jetzt zu Microsoft transportieren kann.