Can I rely on data retrieved by WMI classes?

    Using the example of several Win32_xxxx WMI classes, 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 it is shown that the output information is, to put it mildly, not true or issued in a very inconvenient format or simply omitted. ScriptmaticV2.hta, developed by the Microsoft Scripting Guy team, is used as a stand for executing WQL queries to WMI classes. ScriptomaticV2.hta supports VBS, JS, Perl, Python. Due to the absence of the latter two, only the results 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 the use of the same WMI classes in C #, C ++ programs ensures the correct output of results.

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

    All of the above classes 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 InitialTimeStamp, addressed to

    HKLM \ SYSTEM \ CurrentControlSet \ Enum \ SCSI \\ Device Parameters \ StorPort

    The InitialTimeStamp value MAY be NULL, but in most cases it contains a very real date in a format perfectly described in 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. The information is in the Coordinated Universal Time (UTC) format. This property is inherited from __Event. To convert this value to other time formats, use the SWbemDateTime methods SetFileTime and GetFileTime. ”


    Apparently, the Win32-WMI class developers didn’t want to use the SWbemDateTime methods either, and therefore issuing JS code in the InstallDate field always substitutes null date, issuing VBS code - this field modestly lowers. But after all, no methods are needed to convert the 64-bit QWORD number of the format described above 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_ & PRO23_ST93 \ 4 & 3516B3B5 & 0 & 000000

    Someone can give a reasonable explanation of the value of the InterfaceType field, which directly contradicts both the PNPDeviceID specified below and the fact that, starting with Windows 8.1, the HKLM \ SYSTEM \ CurrentControlSet \ Enum \ IDE is completely absent and the last time it was present only in the environment 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 a favorite feature, giving out very important information is completely inconvenient. Both SerialNumber and Signature are all used to reading in the 16th form.

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

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

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

    5. The presence of fields containing NULL for JS or empty for VBS for all objects in the WQL query

    As an example, I can cite the values ​​of the Access and Description properties for the Win32_Volume class. I have on 9 mounted devices, including two internal disks, a couple 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 either NULL for JS in the indicated fields Issue or empty for VBS issue. The question is, what should be the volume on which the device is located in order for at least one of the indicated properties to be significant for it? And if this cannot be, then why include these properties in the results?
    I decided to check with PS and “gwmi win32_volume” for all volumes returned empty values ​​for the Access, Description properties.

    Conclusion

    The main point of this short, perhaps overly emotional publication is to attract the attention of everyone who uses WMI classes in their code, critically evaluate the extracted data, and recheck it from other sources. I’ll immediately add that MSFT classes, similar to the Win32 classes described above, always provide correct information, although they also sin by issuing negative numbers in Signature fields.

    Also popular now: