Можно ли полагаться на данные, извлекаемые WMI классами?

[gotch]

Подскажите, что имеется в виду под MSFT-классами, аналогичными описанным выше Win32-классам?

[sysprg_46]

msft_disk — отличная замена win32_DiskDrive:
SELECT * FROM MSFT_Disk", «WQL»,…
…
SerialNumber: 5VH4135F
Signature: 272024004
…
NumberOfPartitions: 5 < — учтен Extended Partition на Mbr, Extended присваивает индекс 0, в точности как и Diskpart.exe, Primary индексируются с 1, Logical внутри Extended индексируются начиная с 4.
BusType: 11
Location: PCIROOT(0)#PCI(1F02)#ATA(C00T00L00) — важная информация

MSFT_Partition, замена Win32_Partition. Здесь и корректная индексация и забавнейший
AccessPaths: \\?\Volume{2c654a1d-e045-11e4-826d-806e6f6e6963}\,\\?\Volume{1036c1c4-0000-0000-007e-000000000000}\
немного ЖУЛЬНИЧАЮТ, нет уже под Windows 10 RTM TH1 такого GUID:
{1036c1c4-0000-0000-007e-000000000000}, но в этом классе он появился еще под 8.1 и был ОЧЕНЬ ПОЛЕЗЕН тем, что содержал parent Disk Signatue в поле Field 1 GUID и смещение раздела в последних двух полях. Такой GUID просуществовал во всех сборках Windows 10 начиная с 9826 и заканчивая 10166, но в в 10240 изменилась логика генерации GUID и такой формат GUID в десятке уже отсутствует.

Забавно и то, что в этом классе они фактически объединили и РАЗДЕЛЫ и ТОМА, поскольку и БУКВЫ ТОМОВ также отображаются этим же классом

AccessPaths: B:\,\\?\Volume{f0fd3322-2d89-11e5-82e0-806e6f6e6963}\,\\?\Volume{1036c1c4-0000-0000-0000-261600000000}\
DiskId: \\?\scsi#disk&ven_&prod_st9320423as#4&3516b3b5&0&000000#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}
DiskNumber: 0
DriveLetter: 66
GptType: null

ну просто море удовольствия, все что нужно, и индекс родителя, и буква тома и пометка Gpt/Mbr

MSFT_PartitionToVolume — снимает ВСЕ вопросы о связи разделов и томов
MSFT_PhysicalDisk — малость добавляет к тому, что уже известно с помощью msft_disk
MSFT_Volume -важные дополнения к тому, что уже известно из MSFT+Partition

[gotch]

Но это тоже WMI классы, из того же namespace? Тогда остается лишь еще раз вспомнить про фатальный недостаток.

[sysprg_46]

простите мою темноту, не въехал в «фатальный недостаток». А namespace наверное вот здесь затаился:
winmgmts:\\\\" + arrComputers[i] + "\\root\\Microsoft\\Windows\\Storage

Мне MSFT классы понравились лишь в сравнении с Win32 классами, но у них есть очень серьезный недостаток — под семеркой таких классов нет вообще.

[gotch]

Фатальный недостаток

[sysprg_46]

Думаю, что Вы правы и зависимость от DLL в WMI сильная. Но я уже давно стал считывать нужную информацию непосредственно из Registry, поскольку твердо убежден, что в Registry есть ВСЕ, что может выдать любой из WMI-классов.

[xtraroman]

А еще можно добавить нулевой пункт. WMI сервис может быть банально выключен у пользователя на компьютере :).

[sysprg_46]

For sure, как говорят у них или «естессно», как принято у нас. Но я ведь и начал свои публикации с описания алгоритма, который читает информацию непосредственно из ОСНОВНОГО ИСТОЧНИКА ЗНАНИЙ, а именно Windows Registry.