Can I rely on data retrieved by the WMI classes?

Using the example of several WMI classes Win32_xxxx, it is shown that at least some of the object properties returned by the specified classes do not correspond at all to the real values ​​of these properties.

Below are examples of WMI classes issuing Win32_CDROMDrive, Win32_DiskDrive, Win32_DiskPartition, Win32_LogicalDisk, Win32_Volume and demonstrate that the output is, to put it mildly, not true or is issued in a very inconvenient format or simply omitted. The program ScriptomaticV2.hta, developed by the “Scripting Guy” development team from Microsoft, is used as a stand for performing WQL queries to WMI classes. ScriptomaticV2.hta supports VBS, JS, Perl, Python. Due to the absence of the latter two, only the outputs of JS and VBS were used. Therefore, I apologize in advance to the developers of the mentioned WMI classes if Perl and / or Python provide the correct information. In addition, I hope that using the same WMI classes in C #, C ++ programs ensures that results are output correctly.

1. Invalid or omitted date of creation or mounting of an object.

All the classes listed above in the property list contain a property called “InstallDate”. This property in the Windows Registry corresponds to REG_QWORD. On Windows 8.1+ (8.1 and all Windows 10 builds) CDROMDrive, DiskDrive, this value is stored in the InitialTimeStamp addressable
')
HKLM \ SYSTEM \ CurrentControlSet \ Enum \ SCSI \ \ Device Parameters \ StorPort

The InitialTimeStamp value MAY take a NULL value, but in most cases it contains a very real date in a format that is beautifully described in the Microsoft documentation:

“Unique value that indicates the time when an event is generated.
This is a 64-bit FILETIME value that represents the number of 100-nanosecond intervals after January 1, 1601. This information is in the Coordinated Universal Time (UTC) format. This property is inherited from __Event. SetFileTime and GetFileTime. ”

Apparently the developers of the Win32-WMI classes did not want to use SWbemDateTime methods, and therefore issuing the JS code in the InstallDate field always substitutes null date, issuing a VBS code — this field is modestly omitted. But after all, no methods are needed to convert a 64-bit QWORD number of the above format into a number representing the date in milliseconds, on the basis of which you can create a Date object. This will require elementary arithmetic.

2. Conflicting data, error in the InterfaceType field, Win32_DiskDrive

Index: 0
InstallDate: null date should be Sun Jul 19 08:12:08 UTC + 0300 2015
InterfaceType: IDE
...
Model: ST9320423AS
Name: \\. \ PHYSICALDRIVE0
...
PNPDeviceID: SCSI \ DISK & VEN_ & PROD_ST9320423AS \ 4 & 3516B3B5 & 0 & 000000

Someone can give a reasonable explanation for the InterfaceType field value, which directly contradicts the PNPDeviceID listed below and the fact that since Windows 8.1, HKLM \ SYSTEM \ CurrentControlSet \ Enum \ IDE is completely missing from Windows 8.1 and last time it was present only in Windows 7 ?

3. Negative values ​​in the fields SerialNumber, Signature by the classes Win32_DiskDrive, Win32_Volume

SerialNumber: Hitachi HT100219FCC400NEJTBU5G
Signature: -1498719820
...
Purpose: null
QuotasEnabled: false
QuotasIncomplete: false
QuotasRebuilding: false
SerialNumber: -1408044882

This is generally the favorite "chip", the issuance of very important information in a completely indigestible format. Both SerialNumber and Signature are all used to reading in the 16th form.

4. Incorrect partition indexing for Gpt-formatted disks, Win32_DiskPartition class

Caption: Disk # 3, Partition # 0
...
Description: GPT: Basic Data

Well, explain to me, the Gpt-formatted partition of the type “Basic Data” has acquired the index 0, which rightfully belongs to the MSR-section? Naturally, the MSR-section of the Win32_DiskPartition in the list of sections is generally coldly ignored.

5. Presence of fields containing NULL for JS or empty for VBS for all objects in a WQL query

As an example, I can give the values ​​of the Access and Description properties for the Win32_Volume class. I have 9 mounted devices, including two internal disks, a pair of virtual DVD-ROMs, several VHDs with Gpt-formatted partitions, a USB disk, an SD card and a flash drive, 16 volumes are located and all of them contain the specified fields or NULL for JS -discharge or empty for VBS-issue. The question is what should be the device on which the device is located so that for him at least one of the specified properties would be significant? And if this can not be, then why bother to include these properties in the output?
I decided to check with PS and “gwmi win32_volume” for all the volumes I gave out empty values ​​for the Access, Description properties.

Conclusion

The main point of this short, perhaps overly emotional publication is to attract the attention of all those who use WMI classes in their code, critically evaluate the extracted data, recheck them from other sources. Immediately I will add that MSFT-classes, similar to the Win32-classes described above, always give out correct information, although they also sin by issuing negative numbers in the Signature fields.