[German]A German blog reader already informed me in mid-June 2019 about a stupid bug in winevtutil to me. Here I outline a few details about this behavior within this blog post.
Advertising
What is winevtutil?
Winevtutil is a command line tool for Windows that can be used to retrieve information about event logs. This command is also used to install and uninstall event manifests to run queries and to export, archive and delete logs. Microsoft has documented the tool in this article.
Problem report of the blog reader
Blog reader Dalai contacted me by mail in mid-June 2019 to point out a bug in the command.
I recently came across a bug in a Windows tool, and I can't find any other evidence on the net that someone else has noticed this bug within the past 12 years, and made it public. Since you need a Microsoft account for the feedback hub, but I don't have one (and don't want one), I hope you could somehow bring the problem to Microsoft. Maybe you can blog about it.
Specifically it is about the console tool wevtutil.exe. Its long parameter reversedirection does not work, and has never worked since the tool was introduced with Vista.
I have tested it under Vista, Win7, Server 2012 R2 and Win10 1809 –
Nowhere is the parameter accepted. A concrete example of a command that anyone can test themselves:wevtutil qe Application /c:1 /f:text /reversedirection:true
ends with the following error message:
> Invalid option reversedirection. Option is not supported. The parameter
> is incorrect.And this although the parameter is exactly the same in the help, see wevtutil qe /?
The short form of the parameter works perfectly:Die kurze Form des Parameters funktioniert einwandfrei:
wevtutil qe Application /c:1 /f:text /rd:true
Now I have inspected the EXE file with Sysinternals Strings – and found that the parameter appears twice, once as reversedirection and once as reversdirection (i.e. without second e).
If you use the parameter in the form without e, there will be no Error message, but the parameter has no effect, i.e. the oldest event instead of the newest one.
Fun fact: In an example code uploaded by Microsoft itself for a slimmed down program called ReadEvents it looks correct (lines 97/98)
If you're wondering why the blog reader is addressing this, the blog reader wrote to me: "I prefer to use the long forms of parameters (if available) in scripts, since these are very often allow a clear statement about what a parameter does without having to look into the help first. He also thinks that every bug has to lie around for 20 years before it can be fixed ….
I then asked if the English version of the tool was also affected. He answered:
I have also tested it in an English Windows 7, the problem is
is also available there. More or less logical, because the EXE is the same, only the language files (*.exe.mui) are different. And the cause of the problem probably lies in the EXE, as the investigation of the EXE showed. The problem is therefore language-independent and affects all languages.In addition, on 64-bit Windows both EXEn are affected, i.e. the EXEs specified in 64-bit EXE in \Windows\System32 and the 32-bit EXE in \Windows\SysWOW64.
At this point my thanks to the blog reader for the hint. I have to see how I can transport this to Microsoft now.
Advertising
