Link to home
Start Free TrialLog in
Avatar of mjgardne
mjgardne

asked on

Determine volume creation datatime?

Hello,

In our application, we need to determine when a volume was created.  I thought that this would be easy to determine by calling Win32's GetVolumeInformationW(), but to my amazement, it does not include this data.  Is there another function that I can call to get it or is there some low-level way that I can get it?  We use C++/CLI and C#, so low-level code doesn't scare me! ;)

Thanks,

Mike
Avatar of Darrell Porter
Darrell Porter
Flag of United States of America image

http://www.integriography.com/
analyzeMFT - a Python tool to deconstruct the Windows NTFS $MFT file

I had two other links but lost them

Google search resulting in this hit:
http://www.google.com/search?q=windows+determine+volume+creation+date&hl=en&ei=iQfuTO0ujOSxA-3BxJ8L&start=20&sa=N
Avatar of mjgardne
mjgardne

ASKER

Hello WalkaboutTigger,

Before I posted here, I did extensive searches in Google, like yours, and did not find anything...  I looked at the info that you provided about the $MFT file, but I didn't see anything about the volume's creation date.  Could you please point it out to me?  I looked in my NTFS references at the MFT and didn't see anything that would be helpful.

Happy Thanksgiving!
Mike
Hmmmm...  It seems that the closest I can get to an answer of when the volume was created is by examining one of the following WMI functions.  I am a little surprised that the volume creation date (when it was formatted) was not in the results from GetVolumeInformation().  If there aren't any other ideas, I will make due with what I have found.

Win32_LogicalDisk
InstallDate
Data type: datetime
Access type: Read-only
Date and time the object was installed. This property does not require a value to indicate that the object is installed.

Win32_Volume Class
InstallDate
Data type: datetime
Access type: Read-only
Indicates when the object was installed. A lack of a value does not indicate that the object is not installed.
Look at the "Sample Output" section and read through the comma-delimited header.  You're looking for

"Std Info Creation date"

and in the output, it is listed as

"2009/12/27 18:35:57.625000"

Also, have you looked at
http://www.ntfs.com/ntfs-system-files.htm
 or
http://www.ntfs.com/ntfs-partition-boot-sector.htm
 or
http://42llc.net/index.php?option=com_myblog&task=tag&category=Windows&Itemid=39
(some interesting discussions on forensics and volumes)


I don't know if this discussion is useful to you
http://www.sepago.de/helge/2009/09/24/how-to-determine-the-windows-installation-date-with-and-without-powershell/
but it talks about how to determine when Windows was installed.

Is there a specific reason you're looking for volume creation date?
Also look at

http://windowsir.blogspot.com/2009_05_01_archive.html

and search for

volume creation date

in the page.
If it is a Windows XP system, it appears, based on some rudimentary experimentation, that the volume creation date coincides with the "System Volume Information" directory creation date.
Hi WalkaboutTigger,

Well, I tried to use the InstallDate from WMI and it seems to always return null, but the other information from the volume is correct...  So, my idea is a no-go...  I am not in the office right now, but I will look over your suggestions tomorrow.  

The reason that we would like the volume's creation date is that it we need to have a unique key to reference any volumes that might be seen by our application.  From my research, a volume's serial number is not guaranteed to be unique throughout the world, so my idea was to combine the serial number with the volume's creation date.  This would tremendously reduce the possibility of a key collision.  On another note, it floors me that this DateTime is not readily available! :P!

Anyway, thank you for your research and ideas...  I will follow up with you soon!

Have a great holiday!
Mike
How about this - volume serial number and the creation time/date stamp of the Windows, Program Files and  Recycler directory?  This way you have 4 pieces of data that, combined, should have a fairly low collision rate, at least for Windows boot volumes.  If you need something more generic, let me know.

I presume you're trying to identify the drive and not the computer, correct?
Hmmm... Good ideas, but...  They assume that the volume on the hard disk has Windows installed on it...  Some volumes that we will process will only contain data.  I am thinking about combining the physial hard drive's serial number with the volume serial number.  This would be guaranteed to be unique...  What do you think?
ASKER CERTIFIED SOLUTION
Avatar of Darrell Porter
Darrell Porter
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I agree...  As strange as it sounds, I've been meaning to create a function to grab the serial number from USB/SATA/IDE hard drives, so this is a good reason to do it!  In the end, using the hard drive's serial number with the volume's serial number is a much better key than using the formatting date.

Thanks for your help!

Mike
Just realize the low-level calls for reading USB memory sticks may not provide consistent results.  Please test it extensively with a variety of thumb drives prior to blessing it for production.
Yup...   I have read many tales of woe from others trying to get serial numbers from flashdisks...  It will be rare that a user would want to use a flashdisk with our application, but if they do and we cannot determine a hardware serial number, the volume serial number should suffice.  In truth, the risk of collision with two drives having the same volume serial number is quite small.

Over the last few days, I've written about 1/2 of the IOCTL and Setup API code to extract the serial number from a SATA/IDE/USB hard drive...  In the near future, I will need to write similar code to extract S.M.A.R.T. information, too.  I am not looking forward to the latter task because the data varies from manufacturer to manufacturer.

Thanks again for your help and advice! :)  

Mike