Member Avatar for zelkea

Hello All,
I am troubleshooting a problem with a 2k3 server that has been throwing Blue Screens. I am trying to figure out how to translate the datestamp to an actual time. Does anyone know the algorithm for windows DateStamp or how to figure out what time this DateStamp is for "45ed063d"?

Thanks,
AJZ

  • 4 Contributors
  • 6 Replies
  • 184 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by zelkea

Dani AI

Generated

Short answer: that hex is a Unix/time_t-style timestamp (seconds since 00:00:00 UTC, Jan 1 1970) — not the 64-bit FILETIME (100‑ns ticks since 1601). The PE/COFF header field TimeDateStamp and the minidump timestamp fields use the 32‑bit time_t/epoch style value, so you should interpret the hex as an epoch seconds value in UTC. (learn.microsoft.com)

How to convert (practical, repeatable): parse the hex as an unsigned 32‑bit integer, then interpret that integer as Unix epoch seconds and convert to UTC (or to the server’s local timezone for matching logs). Example conversions you can paste/run quickly:

# Python (modern, timezone-aware)
from datetime import datetime, timezone
ts = int("45ed063d", 16)        # -> 1173161533
print(datetime.fromtimestamp(ts, timezone.utc))   # 2007-03-06 06:12:13+00:00
# PowerShell (Windows)
$ts = 0x45ed063d
[DateTimeOffset]::FromUnixTimeSeconds($ts).UtcDateTime
# -> 3/6/2007 6:12:13 AM (UTC)

(Use ToLocalTime() / convert from UTC if you need the server local time.) (docs.python.org)

Two important cautions for correlation: the module TimeDateStamp is the image/linker timestamp (build time), not necessarily the crash time — conversely the minidump header contains a TimeDateStamp (time_t) that records when the dump was written, and the per‑module TimeDateStamp in the module list is the module’s stamp. Verify which field you’re reading before correlating with app/backup logs. Also watch for clock skew / DST / time zone differences when matching events. (learn.microsoft.com)

Tie‑back: was right to think of Windows time formats (FILETIME is used widely), but the debug/module datestamps you see in PE/minidump output are epoch seconds — use the conversion above to get UTC/local time. As and noted, cross‑check the dump header and the Event Viewer/system logs to pinpoint the crash time, then correlate with your backup software logs.

Recommended Answers

All 6 Replies

Member Avatar for rneuschul

I believe that debug datestamps are in 64bit UTC format from dateline 00:00 January 1, 1601, using 100 nanosecond 'ticks' - but I could well be wrong.

How you decode one to human readable is a whole different question though; fraid I don't have a clue.

Member Avatar for DimaYasny

what is really important in BSOD analysis is the memory dump file. that is what should be checked, not the time

Member Avatar for rneuschul

Sorry, but that's not a proper basis on which to conduct any form of investigation: whilst it's correct to say that the content of the dump are important it is NOT correct to say [or imply] that the time is unimportant. This is especially true if one is seeing repeated events of a similar type on the same machine, or a spread of events across multiple machines.

Knowing precisely when an event occurs can help one to track causes.

In IT Forensics, just as in any other branch of forensics, one NEVER EVER throws any of the evidence away.

Member Avatar for DimaYasny

well, in 2003 systems, the error times can be viewed in system logs. while BSOD reasons are generally seen in minidump files.
that's not IT forensics, that's experience.

Member Avatar for Michael_Knight

rneuschul, evidence is one thing, but this is not forensic casework. DimaYasny is correct. the MiniDump is the first step (as well as looking at the Event Viewer) to diagnosing a BSOD.

zelkea, what I would suggest, is that you go into the dump settings and change it from a mini dump to a full complete memory dump, you will get far more information.

There is also software that you can download to analyze the dump logs and interpenetrate the information for you.

Member Avatar for zelkea

Hey Guys,
Hehe the confusion in my troubleshooting steps is due to that fact I did not post everything I have done up to this point (following the KISS philosophy in trying to get an answer to my question). I have already reviewed the memory.dmp and events on this box that indicated our backup software as being the culprit.

Rneuschul is correct, the exact time is important to me reason being is the backup software in question backs up lets say transaction for simplicity and the system is crashing when it hits a corrupt/orphaned transaction which are known to exist (long story but unavoidable). Therefore, if I am able to figure out the exact time the server is crashing I can use that information with other logs to track down the corrupted/orphaned transaction and fix it.

There is also software that you can download to analyze the dump logs and interpenetrate the information for you.

Michael,
I have been using Microsoft Debug Tools and dumpchk is there another application you would recommend?


AJZ

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.