{"id":62,"date":"2016-02-13T19:57:06","date_gmt":"2016-02-13T19:57:06","guid":{"rendered":"http:\/\/eventlogxp.com\/blog\/?p=62"},"modified":"2016-03-30T02:06:14","modified_gmt":"2016-03-30T02:06:14","slug":"invalid-dates-inside-some-events","status":"publish","type":"post","link":"https:\/\/eventlogxp.com\/blog\/invalid-dates-inside-some-events\/","title":{"rendered":"Invalid dates inside some events"},"content":{"rendered":"

You have probably heard that due to a date bug, it is easy to brick iPhone by changing its system date to Jan 1, 1970. If you are not aware of this issue, you may read it here<\/a>. We found a very similar problem with event logging. Fortunately, nothing crashes, but the problem may stop a log from being loaded.<\/p>\n

Recently we received a bug report that Event Log Explorer breaks loading the\u00a0system event log on Windows 10 with error: \u201cInvalid argument to date encode\u201d. This happened only sometimes and if a log was loaded using New API. Researching the issue, we discovered that the problem is linked with Event ID = 107 of Microsoft-Windows-Kernel-Power (\u201cThe system resumed from sleep\u201d). Moreover, in our time zone (GMT+3) all seems to work fine, but in GMT-5 it fails to load this event. However, Event Viewer loads this event without problems in all time zones. Really strange…<\/p>\n

What is\u00a0event 107 of Microsoft-Windows-Kernel-Power? At first glance, this is an absolutely harmless event \u2013 event date and time are correctly stored in the event log. The description of this event has no parameters. \u00a0But let’s investigate it deeper. The event details contain additional parameters:<\/p>\n

<EventData>\r\n  <Data Name=\"TargetState\">6<\/Data>\r\n  <Data Name=\"EffectiveState\">5<\/Data>\r\n  <Data Name=\"WakeFromState\">5<\/Data>\r\n  <Data Name=\"ProgrammedWakeTimeAc\">1601-01-01T00:00:00.000000000Z<\/Data>\r\n  <Data Name=\"ProgrammedWakeTimeDc\">1601-01-01T00:00:00.000000000Z<\/Data>\r\n  <Data Name=\"WakeRequesterTypeAc\">0<\/Data>\r\n  <Data Name=\"WakeRequesterTypeDc\">0<\/Data>\r\n<\/EventData><\/pre>\n
That\u2019s it! Although event description doesn’t refer any event parameters, there are 7 parameters stored with the events. And the problem is obviously linked \u00a0with ProgrammedWakeTimeAc and ProgrammedWakeTimeDc. Unfortunately Microsoft doesn’t have the detailed description of this event it the knowledgebase, but I suppose these parameters\u00a0linked with a programmable system wake up when computer plugged in or on battery.<\/p>\n
What is the exact reason of the problem? Windows Event Viewer displays all these parameters as is. But Event Log Explorer is smarter than Event Viewer. It automatically corrects times according to your time zone. So, if you are in the Western hemisphere (more correctly you are in UTC \u2013xx time zone), Event Log Explorer will subtract something from Jan 1, 1601 (which is a starting point for Windows time) causing an error (negative value). It’s very similar to the iPhone date bug with 2 differences: the starting point for iPhone time (Unix time) is Jan 1, 1970 and Event Log Explorer does no harm.<\/p>\n
Nevertheless it is a bug, and we immediately fixed it by checking the date\/time value. If it is Jan 1, 1601 00:00, we do not apply time correction, and now it works correctly.<\/p>\n
An updated version of Event Log Explorer is available from our site at<\/p>\n
http:\/\/eventlogxp.com\/download\/elex_setup.exe<\/a><\/p>\n
 <\/p>\n\"Facebook\"<\/a>\"twitter\"<\/a>\"reddit\"<\/a>\"pinterest\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>","protected":false},"excerpt":{"rendered":"
You have probably heard that due to a date bug, it is easy to brick iPhone by changing its system date to Jan 1, 1970. If you are not aware of this issue, you may read it here. We found a very similar problem with event logging. Fortunately, nothing crashes, but the problem may stop a log from being loaded. Recently we received a bug\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":66,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[43,39],"tags":[19,32,21,30,50],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/eventlogxp.com\/blog\/wp-json\/wp\/v2\/posts\/62"}],"collection":[{"href":"https:\/\/eventlogxp.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/eventlogxp.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/eventlogxp.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/eventlogxp.com\/blog\/wp-json\/wp\/v2\/comments?post=62"}],"version-history":[{"count":3,"href":"https:\/\/eventlogxp.com\/blog\/wp-json\/wp\/v2\/posts\/62\/revisions"}],"predecessor-version":[{"id":65,"href":"https:\/\/eventlogxp.com\/blog\/wp-json\/wp\/v2\/posts\/62\/revisions\/65"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/eventlogxp.com\/blog\/wp-json\/wp\/v2\/media\/66"}],"wp:attachment":[{"href":"https:\/\/eventlogxp.com\/blog\/wp-json\/wp\/v2\/media?parent=62"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/eventlogxp.com\/blog\/wp-json\/wp\/v2\/categories?post=62"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/eventlogxp.com\/blog\/wp-json\/wp\/v2\/tags?post=62"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}