Changing the system clock or timezone is a security event, and if security logging is on then it will generate entries in the SecEvent.evt(x) file.
Not sure why you're not finding the InstallDate key though?? It's still there in Windows 7, and has been since Windows 2k… Are you looking at your own live Registry? If so, it should be there in Regedit… If you're looking at the Registry from a dead box, then it's in the Software file.
Where you used P2 to look at the created date for the setuplog.txt file, did you look at the actual MFT record for that file? Of course, assuming that it's NTFS? As far as I recall (and it's been a while!), FAT dates and times are stored in local?
Regards
Paul
….
I think I have come across this in the past and it was the explanation in that instance.
H
I really like your avatar, clever! I have considered what you said, but how can I prove it, and ascertain when it was changed?
Thanks, best way is by experimentation, try it on a VM, record the process and compare the times.
H
Changing the system clock or timezone is a security event, and if security logging is on then it will generate entries in the SecEvent.evt(x) file.
Not sure why you're not finding the InstallDate key though?? It's still there in Windows 7, and has been since Windows 2k… Are you looking at your own live Registry? If so, it should be there in Regedit… If you're looking at the Registry from a dead box, then it's in the Software file.
Where you used P2 to look at the created date for the setuplog.txt file, did you look at the actual MFT record for that file? Of course, assuming that it's NTFS? As far as I recall (and it's been a while!), FAT dates and times are stored in local?
Regards
Paul
Looks like security logging wasn't enabled, so unfortunately the SecEvent.evt is empty.
Due to a glitch in Paraben, the InstallDate wasn't showing up, I restarted everything and now it finally appeared. The value that appears is
1092955707
which appears to be UNIX time. Converted is 8/19/04 224827 UTC
So, here's what I've got. Five different potential install dates
- setuplog.txt created date 8/19/04, 459pm UTC
- setuplog.txt first entry 8/19/04, 165913 (timezone unknown, UTC?)
- systeminfo.exe original install date 8/19/04, 54827pm CST(? time zone indicates Central Standard Time, the OS was virtualized to run this tool)
- InstallDate registry value 8/19/04, 224827 UTC
- SysEvent.evt first entry 8/19/04, 45852pm UTC
So… I badly need to understand which one is "correct" and how to explain each difference. My biggest concern is the difference between the SysEvent and the InstallDate registry value. How can this be?
PS I did look at the MFT record, but there's no useful information there? What should I be finding of value? And, this is an NTFS volume, it was converted at some point.
Hello,
I've had a quick look about this morning and here's a possible solution.
The InstallDate registry value is the only date in UTC. The dates from setuplog.txt and SysEvent.evt are in CST.
Reading about the CST timezone, it seems that in some areas there is a 1 hour Daylight Savings between "mid-March and early November". This explains the date and time from systeminfo.exe, because it takes into account daylight savings. I can only assume that the other times and dates don't.
Dates in the MFT are stored in UTC, and the operating system applies a time offset in order to present those in local time. If you look at an MFT record you'll see dates within it which are in Windows FILETIME format (64 bit). If you look at everything as UTC then it might be easier to work out what's going on.
Possibilites for things that may have happened are -
Windows was installed at UTC 2248 on 19th August, = 1648 Central Standard time.
Windows was originally installed on a FAT volume, so file dates/times were recorded in Local Time.
During the installation process, the time zone was changed from PST to CST.
At a later stage, the volume was upgraded to NTFS, so dates/times are now recorded in UTC, with the operating system applying an offset.
Paraben is reporting your dates and times with an offset applied, and where there was a change from FAT to NTFS, it hasn't picked up that some dates and times were orginally in Local time, and some were in UTC, so is applying an offset when it doesn't need to. Have you tried getting it to report all dates/times in UTC?
Regards
Paul
P.S How are you viewing that entry in the SysEvent.evt file? In the Event Viewer in the virtualised machine, or in raw hex? The date is stored in Unix format, in UTC. I think the Event Viewer may be applying an offset to convert it to Local time when it's displaying to you…