Invalid dates inside some events

By | February 13, 2016

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 report that Event Log Explorer breaks loading the system event log on Windows 10 with error: “Invalid argument to date encode”. 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 (“The system resumed from sleep”). 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…

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

<EventData>
  <Data Name="TargetState">6</Data>
  <Data Name="EffectiveState">5</Data>
  <Data Name="WakeFromState">5</Data>
  <Data Name="ProgrammedWakeTimeAc">1601-01-01T00:00:00.000000000Z</Data>
  <Data Name="ProgrammedWakeTimeDc">1601-01-01T00:00:00.000000000Z</Data>
  <Data Name="WakeRequesterTypeAc">0</Data>
  <Data Name="WakeRequesterTypeDc">0</Data>
</EventData>

That’s it! Although event description doesn’t refer any event parameters, there are 7 parameters stored with the events. And the problem is obviously linked  with ProgrammedWakeTimeAc and ProgrammedWakeTimeDc. Unfortunately Microsoft doesn’t have the detailed description of this event it the knowledgebase, but I suppose these parameters linked with a programmable system wake up when computer plugged in or on battery.

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 –xx 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.

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.

An updated version of Event Log Explorer is available from our site at

http://eventlogxp.com/download/elex_setup.exe

 

Facebooktwitterredditpinterestlinkedinmail