Member Avatar for Deva.VG

Hi,

We are reading the event log information in our application from using query in windows management service and Java script. The required event log is based on the current system time that we send through the query to fetch the details. We face a problem while fetching a event log of Windows xp and Windows-7 as the actual time the error message logs differs from the system time. Also the time difference is not same in all the machines of same configuration.

Example : Conider an error is logged in windows event log at 05.00 AM but the time logged as 02.00 AM (which can also 07.00 AM or any difference of time) in the event log. Now I was unable to decide the exact time of an error log.

We made a workaround in Windows-7 by fetching it using Record ID which is increasing for every event log but the same does not work in Windows-XP as the record id is not increasing and does not look to have a standard format.

Kindly provide us some solution to fetch the error log information of the particular time.

Thanks,
Deva Veluchamy.

  • 3 Contributors
  • 2 Replies
  • 259 Views
  • 6 Hours Discussion Span
  • Latest Post Latest Post by CimmerianX

Dani AI

Generated

As and pointed out, the problem almost always comes from mismatched clocks/time zones combined with how WMI/event APIs represent timestamps. The Win32_NTLogEvent class exposes TimeGenerated and TimeWritten as WMI datetime values, so sending a caller-local wall‑clock string into a WMI WHERE clause will miss or misalign events unless the query time is converted to the same absolute timeline the remote machine uses. (learn.microsoft.com)

WMI uses the fixed CIM_DATETIME format (yyyymmddHHMMSS.mmmmmm±UUU) and compares those strings character-for-character, so the practical fix is to convert the desired window to UTC (offset +000) and send a CIM_DATETIME string in the WHERE clause, or let the remote machine build the filter locally. The SWbemDateTime helper exists to parse/format WMI times when working from script or automation. Converting to GMT/UTC before querying avoids local timezone/DST differences. (learn.microsoft.com)

Practical recommendations:

  • Run the WMI query on the target host (ConnectServer) so the machine’s own local clock and timezone are used, or
  • Convert the search start/end to UTC and format as CIM_DATETIME with “+000” and use TimeGenerated (or TimeWritten) in the WQL WHERE clause.
  • For Vista/7 and newer, prefer the newer Eventing API (EvtQuery / event XML): the XML contains TimeCreated/SystemTime (UTC) and EventRecordID (monotonic on modern systems). For XP, RecordNumber exists but can be affected by log clearing/overwrite/wrap, so treat it as a fallback for ordering, not an absolute timestamp source. (learn.microsoft.com)

Example JavaScript formatter to build a UTC CIM_DATETIME for WQL:

function toCimUtc(d) {
  function p(n,w){ return ('000' + n).slice(-w); }
  return p(d.getUTCFullYear(),4) +
         p(d.getUTCMonth()+1,2) +
         p(d.getUTCDate(),2) +
         p(d.getUTCHours(),2) +
         p(d.getUTCMinutes(),2) +
         p(d.getUTCSeconds(),2) +
         '.000000+000';
}
// use: "SELECT * FROM Win32_NTLogEvent WHERE TimeGenerated >= '" + toCimUtc(startDt) + "'"

Finally, enforce correct time sync across the estate (central NTP / Windows Time service) and check the Time-Service operational logs when troubleshooting persistent offsets. That prevents most inconsistent timestamps. (learn.microsoft.com)

Recommended Answers

All 2 Replies

Member Avatar for rneuschul

You need to be considering the fact that 'remote' machines may not be synched correctly or consistently either to a local NTP service or to a remote NTP service, and that the regional time zones for different remote machines may also be different.

You should consider ALSO retrieving the remote UTC values, which are absolute values.

See the following MS page for more information for W7/W2008 etc: as I recall it there are similar WMI calls for XP

http://msdn.microsoft.com/en-us/library/system.datetime.utcnow.aspx

If these are all machines on the same LAN - and especially if they are within the same AD - then consider implementing NTP correctly so all systems use only a local server as their RTS source, and then configure that server to synch time with an appropriate external RTS such as pool.ntp.org. Allowing individual machines to synch their NTP with external sources is a recipe for trouble.

You may well find that you can do this task far better and more easily using Powershell. See the following for some examples:

http://www.computerperformance.co.uk/powershell/powershell_eventlog_remote.htm#Example_2:_PowerShell_Get-Eventlog_on_Remote_Computer

Member Avatar for CimmerianX

rneuschul has it correct. You need to verify that all the systems have syncronized to a common NTP server or to one of the public NTP servers. Ensure that you have accounted for differences in timezone and DST.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.