{"id":5873,"date":"2019-01-27T22:36:07","date_gmt":"2019-01-27T22:36:07","guid":{"rendered":"http:\/\/www.hexacorn.com\/blog\/?p=5873"},"modified":"2019-01-28T01:28:06","modified_gmt":"2019-01-28T01:28:06","slug":"too-much-makes-event-viewer-drunk","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2019\/01\/27\/too-much-makes-event-viewer-drunk\/","title":{"rendered":"Too much % makes Event Viewer drunk"},"content":{"rendered":"\n

Update:<\/strong><\/p>\n\n\n\n

After I posted it Daniel Bohannon<\/a> provided a link<\/a> to his earlier research (March 2018) where he described the very same problem. He has some interesting examples so please have a look!<\/p>\n\n\n\n

Old Post:<\/strong><\/p>\n\n\n\n

This is a short post about a funny side effect of using the % sign and how these are being interpreted by Windows Events Log Viewer.<\/p>\n\n\n\n

When you use this character as a part of a file name, or as a Registry data the program will assume these % signs are referring to actual parameters and will resolve them into actual strings.<\/p>\n\n\n\n

I know it doesn’t make any sense, so let’s do a test.<\/p>\n\n\n\n

Name your program %1.exe. Run it. This is what the Viewer will show:<\/p>\n\n\n\n

\"\"<\/a><\/figure><\/div>\n\n\n\n

Now try to add this Registry value:<\/p>\n\n\n\n

reg add HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run \/v Foo \/t reg_sz \/d test%1%2%3%4%5%6%7%8%9%10%100<\/pre>\n\n\n\n
The result? Very strange details:<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
What about naming the program %1%2%3.exe?<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Look at the image and the command line. One is: C:\\Test\\2019-01-27 22:28:29.601{670b5bbc-308d-5c4e-0000-00105f407c03}.exe<\/em>, and the other “C:\\Test\\Incorrect function.The system cannot find the file specified.The system cannot find the path specified..exe”<\/em>.<\/p>\n\n\n\n
Only the viewer is fooled, because the actual data is logged properly (although there is an inconsistency in the way %s are doubled in command line) — one just needs to go to Details tab and see what it really shows:<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
 That’s it. Yet another quirky behavior to be aware of.<\/p>\n","protected":false},"excerpt":{"rendered":"
Update: After I posted it Daniel Bohannon provided a link to his earlier research (March 2018) where he described the very same problem. He has some interesting examples so please have a look! Old Post: This is a short post … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[43,13,19,46,9],"tags":[],"_links":{"self":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/5873"}],"collection":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/comments?post=5873"}],"version-history":[{"count":4,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/5873\/revisions"}],"predecessor-version":[{"id":5883,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/5873\/revisions\/5883"}],"wp:attachment":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/media?parent=5873"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/categories?post=5873"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/tags?post=5873"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}