この出版物の最初の部分では、アルゴリズムの実装の原理が説明され、プロトタイプコードとdiskpart.exeの順次実行の敵対的な結果が示されています。
このパートでは、アルゴリズムの4つのステップのそれぞれについて簡単に説明し、最初のパートで宣言した原則を厳守していることを示します。 使用された情報源が提供されます。
アルゴリズムがデータを保存する方法。
アルゴリズムの4つのステップを実行するプロセスでは、最初にステップ1で作成されたストレージデバイスDevicesCollectionを表すオブジェクトを含む3つのコレクションが作成され、以降のすべてのステップで親オブジェクトを参照するために常に使用されます。 ステップ2でStorageVolumesCollectionが作成され、ステップ3でLogicalVolumesCollectionが作成されます。 すべてのコレクションは単一の原則に従って編成されます。すべての保存済みオブジェクトにインデックスが付けられ、保存済みオブジェクトに直接アクセスするには、XXXXXCollection [インデックス]を参照する必要があります。XXXXX：{Devices、StorageVolumes、LogicalVolumes}、インデックスは範囲内の任意の整数です[0、XXXXXCollection.Count]。 Countプロパティには、コレクション内の対応するタイプのオブジェクトの数が含まれています。
バイナリデータblobに格納されているデバイスの説明行には、DVD-ROMだけでなく、リムーバブルのDeviceGUIDも含まれていません。 前述のバイナリBLOBには、論理ボリュームの詳細な特性が含まれており、レジストリによって次のようにアドレス指定されます。
HKU \ SID \ Software \ Microsoft \ Windows \ CurrentVersion \ Explorer \ MountPoints2 \ CPC \ Volume \ GUID、GUIDはVolumeGUID、SID-現在のユーザーのセキュリティ識別子。 この点で、DevicesCollectionおよびLogicalVolumesCollectionコレクションには、8文字の短いDeviceGUID.F1と、DVD-ROMおよびRemovableの予測不可能な長い長さの両方の「直接アクセスキー」が含まれています。 ダイレクトアクセスキーは、指定されたキーに対応するオブジェクトのインデックスを返します。 したがって、長いキーPnPDeviceIDを使用してDevicesCollectionにアクセスすると、親デバイスのインデックスを取得できます。 このインデックスは、ParentIndexプロパティの値として、StorageVolumeまたはLogicalVolumeタイプのオブジェクトに直ちに割り当てられます。これらのオブジェクトは、独自のコレクションに配置する必要があります。
アルゴリズムの最初のステップの説明：DevicesCollectionの作成。
情報源：
1. cdromおよびpartmgrサービスによって作成された列挙。 ハードワーカーのpartmgrは、複数のデバイスドライバーから情報を受信するだけでなく、その主要なタスクであるメモリボリュームの列挙を作成するだけでなく、cdromサービスが提供するデバイスを除くすべてのデバイスの列挙を作成します。 パスに沿ったすべてのREG_SZ値の読み取りについて話していることは明らかです。
HKLM \ SYSTEM \ CurrentControlSet \ Services \ cdromおよび
HKLM \ SYSTEM \ CurrentControlSet \サービス\ partmrg。
2. PnPDeviceIDに基づいてデバイスに関する詳細情報を抽出します。 PnPDeviceIDには必ずデバイスの説明行のプレフィックスと、デバイスが接続されているインターフェイスを示すプレフィックスが含まれているという記述で、PnPDeviceIDの説明を補足する時が来ました。 また、このWindowsプレフィックスが、製造元または製造元自身が提供するデバイスの説明に起因するかどうかはわかりません。 いずれの場合でも、PnPDeviceIDは、詳細データを読み取るパスに関する正確な情報を提供します
HKLM \ SYSTEM \ CurrentControlSet \ Enum。 デバイスに関するこの最も重要な情報源、スクリーンショットを示します。
図4
HKLM \ SYSTEM \ CurrentControlSet \ Enum \ PnPDeviceIDに加えて、2つの追加の方法が使用されます。
HKLM \ SYSTEM \ CurrentControlSet \ Enum \ PnPDeviceID \ Device Parameters \ Partmgr。以前はDevGUIDと呼ばれていた最も重要なDiskIdプロパティの値が含まれています。
cdromサービスによってサービスが提供されるデバイスの場合、DiskIdは作成されないため、アルゴリズムはDevIDプロパティをPnPDeviceIDに設定し、「\」文字を「＃」文字に置き換えます。
HKLM \ SYSTEM \ CurrentControlSet \ Enum \ PnPDeviceID \ Device Parameters \ Storportには、REG_QWORD形式のデバイスの製造元のリリース日であるInitialTimestampが含まれています。
内蔵ドライブ専用の追加情報源は次のとおりです。
HKLM \ハードウェア\説明\システム\ MultifunctionAdapter \ 0 \ DiskController \ 0 \ DiskPeripheral
HKLM \ハードウェア\ DEVICEMAP \ Scsi \ Scsiポート1 \ Scsiバス0 \ターゲットID 0 \論理ユニットID M
最初のパスでは、Mbrフォーマットのディスクのディスクの署名を表すREG_SZプロパティ識別子が読み取られ、Gptフォーマットのディスクのゼロが含まれます。これは、ディスクにGptフォーマットのパーティションが含まれていることを示します。 これはアルゴリズムにとって非常に重要な情報ですが、残念ながら、この情報は内部ドライブでのみ利用可能です。
ストレージデバイスを表すオブジェクトに、レジストリから読み取られたすべてのプロパティとアルゴリズムに必要な追加のプロパティが完全に付与された後、オブジェクトには最も重要なプロパティOrderIndexが付与され、その値はDevicesCollection.Countに設定されます。 その後、オブジェクトはコレクションプロパティCountの値に等しいインデックスによってコレクションに配置され、Countがインクリメントされます。
さらに、すべてのリムーバブルおよびDVD-ROMのダイレクトアクセスキーが作成され、グループプロパティが初期化され、その実際の値は2番目と3番目のステップで設定されます。 これらのプロパティをここにリストします。
LVGroupStyle-書式設定スタイル。可能な値はMbr、Gptです。
NumberOfLV-デバイスパーティションでホストされる論理ボリュームの数。
LVGroup-論理ボリュームのオフセットのリスト
NumberOfSV-デバイスに配置されたパーティションの数、ストレージ＃ボリューム
SVGroup-セクションオフセットのリスト
アルゴリズムの2番目のステップの説明：StorageVolumesCollectionの作成
情報源：
1.列挙HKLM \ SYSTEM \ CurrentControlSet \ services \ volsnap \ Enum
ストレージ＃ボリューム、メモリボリュームの順序付きリストを提供する必要があります。 ただし、Windows 8.1のようななめられたシステムでも問題が発生します。 ファイル名BecameCrazy-volsnap.regで保存された保存済みレジストリフラグメントをデモンストレーションします。 このファイルの抜粋を次に示します。
[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ volsnap \ Enum]
「0」=「ストレージ\\ボリューム\\ _ ?? _ SD＃DISK＆Generic＆SA08G＆0.4＃6＆447d92＆0＆9c053461＃{53f56307-b6bf-11d0-94f2-00a0c91efb8b}」
「カウント」= dword：00000011
「NextInstance」= dword：00000011
"1" = "ストレージ\\ボリューム\\ {714ce426-d2a2-11e4-824f-806e6f6e6963}＃0000000000007E00"
"2" = "ストレージ\\ボリューム\\ {714ce426-d2a2-11e4-824f-806e6f6e6963}＃0000000016260000"
SDカードに対応する行「0」に注意してください。 このインデックスがこのカードに割り当てられた方法は、最初の内部ディスクの2番目のパーティションを読み取るときに障害が発生し、システムが障害を処理し、パーティションにダーティビットを設定したため、SDカードのメモリボリュームに関するpartmgrレポートがボリュームレポートより先だったという事実によって説明できます内蔵ドライブのメモリ。 システムの功績として、これは一度しか発生しなかったことを明確にする必要があります。正確な日付-2015年7月1日を指定することさえできます。
しかし、予期しないグリッチについて文句を言うのではなく、驚きに関係なく正しく動作できるアルゴリズムを作成する方が簡単です。 したがって、インシデントにより、アルゴリズムをすぐに修正する必要がありました。指定されたパスに沿って読み取られた行の順序をアルゴリズムが完全に信頼する前に、何が起こった後、親インデックスとそれ自体のオフセットに従ってアルゴリズムで自己順序付けの原則が定められました。
論理ボリュームのコレクションを作成する場合、同じ原則がステップ3に適用され、「partmgr」サービスとオフセットが昇順で停止しない限り、順序が正しいことが保証されます。 既に述べたように、ボリュームGUIDの順序付けアルゴリズムが変更されたのは、Windows 10 RTM TH1で発生したのはこれ（オフセットのシーケンスの中断）でした。 当然、最初は嵐のような感情と、MSプログラマーに向けられたあらゆる種類の不親切な言葉を引き起こしました。使用されたアルゴリズムが機能しなくなったわけではありませんが、LVGroupの無秩序なオフセットリストが本当に目を痛めました。 そして、ほんの数時間後に、アルゴリズムのこの変更の原因、それがもたらしたもの、そしてその瞬間から、新しい順序付けアルゴリズムのアイデアの作者に称賛を歌うだけでした。
2. HKLM \ SYSTEM \ CurrentControlSet \ Enum \ STORAGE \ Volume \ _ ?? _ SD＃DISK＆Generic＆SA08G＆0.4＃6＆447d92＆0＆9c053461＆0＃{53f56307-b6bf-11d0-94f2-00a0c91efb8b}
次のプロパティが含まれます。
「機能」= dword：000000b0
"ContainerID" = "{33b560f6-21b5-11e5-b2ff-806e6f6e6963}"
"HardwareID" = hex（7）：530054004f00520041004700450045c0056006f006c0075006d00650000000000
"ClassGUID" = "{71a27cdd-812a-11d0-bec7-08002be2092f}"
「サービス」=「volsnap」
"DeviceDesc" = "@ volume.inf、％storage \\ volume.devicedesc％;汎用ボリューム"
「ドライバー」=「{71a27cdd-812a-11d0-bec7-08002be2092f} \\ 0000」
"Mfg" = "@ volume.inf、％msft％; Microsoft"
「ConfigFlags」= dword：00000000
これらのプロパティのほとんどには、ペンで事前に書き込むことができます。 興味深いのは、一意のプロパティであるContainerIDだけですが、このGUIDのアプリケーションの検索に時間を浪費するのが面倒で、ドライバーのGUIDを表している可能性が高いです。 したがって、これらのプロパティの読み取りに貴重なミリ秒を費やすことが一般的に意味があるかどうかはわかりません。 メモリボリュームの説明行で表されるオブジェクトを親デバイスにすぐに関連付けることが非常に重要です。 したがって、HKLM \ SYSTEM \ CurrentControlSet \ Enum \ STORAGE \ Volume \から情報を読み取る前であっても、次のプロパティの値を決定するために、メモリボリュームを説明するテキスト文字列が記述されます。
タイプ= {「パーティション」、「リムーバブル」}、
サブタイプ= {「SD」、「Flash」、「仮想」}、
オフセット、DevID
最後のプロパティは、Type = "Partition"のオフセットの前のF1 GUIDフィールドに等しく設定されます。 それ以外の場合、接頭辞「STORAGE \ Volume \」と接尾辞「＃{53f56307-b6bf-11d0-94f2-00a0c91efb8b}」が切り捨てられ、SDカードの「crazy」という名前のファイルの上記の行が次のようになります。
_ ?? _ SD＃DISK＆Generic＆SA08G＆0.4＃6＆447d92＆0＆9c053461＆0
この文字列は、DevIDのプロパティとして割り当てられます。 それでは、「子」のいずれかの最も重要なプロパティ、親デバイスの定義が計算されます。
obj.ParentIndex = DevicesCollection [obj.DevID]
親デバイスのインデックスを学習すると、Removablesの親のDevGUIDを見つけることができます。より正確には、アルゴリズムにはDevGUIDは必要ありませんが、DevGUIDのF1フィールド値のみが必要です。 親は、この値をDCUniqueIDネイティブプロパティの値として保存します。 親DCUniqueIDがわかっている場合、独自の一意の識別子の値を形成できます。
obj.SVUniqueID = DevicesCollection [obj.ParentIndex] .DCUniqueID + obj.Offset
「パーティション」タイプのメモリボリュームの場合、実際のオフセットが使用され、リムーバブルでホストされるメモリボリュームの場合、オフセットは「00000000」に設定されます。
これで、SVGroupを記述する親オブジェクトのプロパティと、親デバイスに割り当てられたメモリボリュームの数を更新できます。 つまり、カウンターDevicesCollection [obj.parentIndex] .NumberOfSVを増分し、カウンターDevicesCollection [obj.parentIndex] .SVGroupに現在のオブジェクトのオフセットを含めます。
論理ボリュームに適用されるのとまったく同じアクションがステップ3で実行されます。
ここで、列挙から読み取った文字列を処理するサイクルにいることを思い出させてください。 StorageVolumesCollectionクラスのオブジェクトに必要なすべてのプロパティを既に決定しましたが、列挙の正確さを信頼できないことに留意して、オブジェクトをターゲットコレクションではなく、単純な一時的なオブジェクトに保存します。 しかし、一般的に言えば、現在のオブジェクトはグループのメンバーです。したがって、一時コレクション内の親インデックスは、オブジェクト自体ではなく、それぞれが同じ親を持つオブジェクトのグループです。
列挙型読み取りサイクルが完了すると、適切に順序付けられたターゲットコレクションStorageVolemesCollectionを作成できます。 これを行うには、親コレクションDevicesCollectionを介してループを実行し、同じ親を持つグループを介していくつかの短いネストされたループを実行します。 ループ内で、StorageVolumesCollection.Countをインデックスとして使用してオブジェクトを配置し、オブジェクトを配置した後にこのプロパティをインクリメントして、StorageVolumesCollectionの一時コレクションからオブジェクトを配置します。 StorageVolumesCollectionは、形成の原則に従って最も単純であり、追加の直接アクセスキーを作成する必要はありません。
アルゴリズムの3番目のステップの説明：LogicalVolumesCollectionの作成
情報源：
リスティング
HKU \ SID \ソフトウェア\ Microsoft \ Windows \ CurrentVersion \ Explorer \ MountPoints2 \ CPC \ Volume \ GUID
GUIDはVolumeGUID、SIDは現在のユーザーのセキュリティ識別子、VolumeGUIDのリストを提供し、指定されたキーでアドレス指定されたDataという名前のバイナリBLOBのコンテンツには詳細データが含まれます。 Blobデータは、UTF-16テキスト文字列とバイナリデータの両方を含むかなり複雑な構造です。 さらに、このBLOB内のテキストフィールドのサイズとオフセットは、ビルド9600以前のWindowsのバージョンに依存します。 プロトタイプコードでは、GetBlobs関数がこのblobのコンテンツの並べ替えを実行します。 使用されるアルゴリズムは、Windowsのバージョンに依存しないように構築されており、テキストフィールドの既知のオフセットは使用されません。 上記に、ステップ2を説明するときに、論理ボリュームが含まれているため、DVD-ROMなどのデバイスは無視されないことを追加します。
ステップ3では、フォームの直接アクセスキーの作成が最も重要です。
mbr-formattedの場合：ディスク署名+オフセット
mbr-formattedの場合：VolGUID.F1 + offset
gpt形式の場合：VolumeGUID.F1
ただし、LogicalVolumesCollectionコレクションに含めるオブジェクトの処理サイクルが実行される瞬間、USBディスクの署名はまだ不明であり、さらに、MHD / GptフォーマットSTYLESはVHDパーティションと外部ディスクの両方で不明です。
したがって、最初にPathフィールドのWMIクラスMSFT_Volumeに登場した特別なタイプのVolumeGUIDに言及する価値があります。実際のVolumeGUIDとともに、{1036c1c4-0000-0000-007e-000000000000}という形式の架空のものもありました。 次に、アセンブリの1つ（おそらく9926）で、そのようなGUID形式が9879から10166までのすべてのアセンブリに現れて存在しましたが、10240ではVolumeGUID生成アルゴリズムの変更により再び消えました。
このGUIDのF1フィールドはディスクの署名であり、F4、F5フィールドは論理ボリュームのオフセットであるため、この形式に言及しています。 そのため、システムでそのようなVolumeGUIDを発見すると、すべてのLVGroupメンバーのLogicalVolumesCollectionオブジェクトに一意の直接アクセスキーを割り当てることが可能になりました。 ここで与えられたVolumeGUID形式に言及するもう1つの理由は、アセンブリ10240で最初に導入された論理ボリュームのマウント順序に従ってVolumeGUIDを編成するという疑いのない革新的なアイデアにもかかわらず、GUID生成アルゴリズムはそれでも失敗したことですそれぞれ4つのパーティションと4つの論理ボリュームを持つMbrディスクの場合、最後の2つは間違った順序で到着します。後者は最後から2番目の論理ボリュームよりも少ないオフセットを持っています。
このような重大な告発は事実によって証明される必要があるため、最後から2番目の「子」のデータブロブの内容は以下のようになります。オフセット= 000020789000000
Windowsレジストリエディターバージョン5.00
[HKEY_USERS \ S-1-5-21-1478854878-1022661374-1075113013-1004 \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Explorer
\ MountPoints2 \ CPC \ボリューム\ {714ce432-d2a2-11e4-824f-806e6f6e6963}]
「データ」= 16進数：000000000df0adba0100000008000000000000800000 \
0000000000300000000000000000ff00e703ff000000160000 \
0026980b421f00000004000000000000000000000000000000 \
0000000000005c005c003f005c00530054004f005200410047 \ \\？\ STORAG
004500230056006f006c0075006d00650023007b0037003100 \ E＃Volume＃{71
3400630065003400320036002d0064003200610032002d0031 \ 4ce426-d2a2-1
003100650034002d0038003200340066002d00380030003600 \ 1e4-824f-806
6500360066003600650036003900360033007d002300300030 \ f6e6963}＃00
00300030003000300032003000370038003900300030003000 \ 0000207890000
3000300023007b00350033006600350036003300300064002d \ 00＃{5
0062003600620066002d0031003100640030002d0039003400 \
660032002d00300030006100300063003900310031006500660062 \
そして今、最後の「子」のデータblobの内容、オフセット= 000000001620000
Windowsレジストリエディターバージョン5.00
[HKEY_USERS \ S-1-5-21-1478854878-1022661374-1075113013-1004 \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Explorer \
MountPoints2 \ CPC \ Volume \ {f0fd3322-2d89-11e5-82e0-806e6f6e6963}]
「データ」= 16進数：000000000df0adba0100000008000000000000800000 \
0000000000300000000000000000ff00e703ff000000160000 \
00cd14ff0e1f00000004000000000000000000000000000000 \
0000000000005c005c003f005c00530054004f005200410047 \ \\？\ STORAG
004500230056006f006c0075006d00650023007b0037003100 \ E＃Volume＃{71
3400630065003400320036002d0064003200610032002d0031 \ 4ce426-d2a2-1
003100650034002d0038003200340066002d00380030003600 \ 1e4-824a-806
6500360066003600650036003900360033007d002300300030 \ e6f6e963}＃00
00300030003000300030003000310036003200360030003000 \ 000000162600
3000300023007b00350033006600350036003300300064002d \ 00＃{5
0062003600620066002d0031003100640030002d0039003400 \
660032002d00300030006100300063003900310031006500660062 \
00380062007d00000000000000000000000000000000000000 \
そして最後に、上記のVolumeGUIDを含むRegistryブランチのスナップショットは、私がORDER OF FOLLOWINGの子供たちと間違われていないことを証明します。
結論として、論理ボリュームのコレクションに配置するオブジェクトのサイクルの最後に、外部ディスクおよびVHD上のパーティションのフォーマットスタイルを最終的に処理する機会があることに注意してください。 これを行うには、NumberOfSVプロパティとNumberOfLVプロパティの値を比較するだけです。 値の一致は、ディスク上のパーティションがMbrフォーマットスタイルを持っていることを明確に示しています。一方、NumberOfLV <NumberOfSVは、Gptパーティションの最初のMSRに論理ボリュームを含めることができないため、Gptフォーマットスタイルを明確に示します。
アルゴリズムの4番目のステップの説明：論理ボリュームへの文字の割り当て
情報源：HKLM \ SYSTEM \ MountedDevices
Windowsの初心者ユーザーでさえ、この保存方法をよく知っていますが、必要な情報とともに、完全に不要な情報もたくさんあります。 これは、USBスティックおよび電話の場合に特に当てはまります。電話のほとんどは現在、micro-SDを装備しています。 そのようなすべてのデバイスに関する情報は、MountedDevicesをすぐに詰まらせます。 MountedDevicesには、これらのデバイスごとに2つのエントリがあることに注意してください。1つは名前フィールドの値が\ ?? \ Volume \ VolumeGUIDで、もう1つは名前フィールドの形式の値が\ DosDevices \ Qです。 両方のエントリの値フィールドには非常に長い16進テキストがあり、UTF-16では、すでにおなじみのPnPDeviceIDを「\」を「＃」に置き換えた形式で表します。 このような直接アクセスキーはLogicalVolumesCollectionで作成されたため、不要なRemovableを簡単に除外できます。
上記はすべて、内部と外部の両方のディスクパーティションに適用されます。内部ディスクの1つを変更しましたが、そのすべてのパーティションに関する情報は、Windowsを最初からインストールするまでMountedDevicesに格納され続けます。既存のレジストリを破壊することはありませんが、すべての更新により、MountedDevicesコンテンツは更新されたシステムから更新されたシステムに移動します。
次に、MountedDevicesエントリの値フィールドの値によって、Mbr形式のディスクとGpt形式のディスクに対応する論理ボリュームを区別する方法について説明します。 : value 24 , Signature, , 8 , 16 .
LogicalVolumesCollection , Signature Offset, , . , , , LogicalVolumesCollection.
MountedDevices \DosDevices\x:, , , , VolumeGUID.F1 + value. VolumeGUID.F1 + , , + .
Gpt- . value 48 , 16 , 8- utf-16 32 16- , QWORD, VolumeGUID. :
String.prototype.ConvertQWORD = function()// converts 32-bytes heximal string
{
//.... xxyyzztttttt
// 00 02 04 06 08 10 12 14 16 18 20 22 24 26 28 30
// 3ab0aea1c467eb4fb392a1a746d349a7 3a b0 ae a1 c4 67 eb 4f b3 92 a1 a7 46 d3 49 a7
var t = this.toLowerCase();
return t.substr( 06, 02 ) + t.substr( 04, 02 ) + t.substr( 02, 02 ) + t.substr( 00, 02 ) +
t.substr( 10, 02 ) + t.substr( 08, 02 ) + // 4 xx
t.substr( 14, 02 ) + t.substr( 12, 02 ) + // 4 yy
t.substr( 16, 02 ) + t.substr( 18, 02 ) + // 4 zz
t.substr( 20, 12 ); // 12 }
Mbr- , Gpt- MountedDevices . Gpt- , , MountedDevices . VolumeGUID , F1 .
5.
5 4: MountedDevices, VolumeGUID, Signature+Offset, DosDevices, “SetMountNameForMountPoint”.
. Github , EnumerateVolumes-LLD.docx, EnumerateVolumes-LLD.pdf. . , , . Github , , , . , 99.5% JS- Web-, . PShell vbs.
, 10 : , . , , . DevicesCollection, StorageVolumesCollection LogicalVolumesCollection , , . , , , .
最初の部分で与えられた敵対的結果についてコメントする
, , , , TopGear, 1 . , . . , diskpart.exe , , . , . Windows . , , diskpart EnumDevicesAndVolumes.wsf . , .
GUID
, Github , GUID, : Volume GUID Gpt- Volume GUID Mbr-, 3? : , Field 3 Volume GUID “11e4” “11e5”, , MS GUID .
StdRegWrapperClass, Registry
, “”, , , Registry, TestCase. , Set, Delete — Set / Delete . StdRegProv. , .
4 , MountedDevices: , VolumeGUID , , , DosDevices. , , , . , , VolumeGUID , DosDevices . N , . .
REG_QWORD . , . , - Registry, REG_QWORD. “ ”, .
, Identifier, HKLM\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\0\DiskController\0\DiskPeripheral, «Identifier»=«9cb5ff90-00000000-A». , Registry . - , .
Data MountPoints2\CPC\Volume. , . , , , . .
www.script-coding.com/WMI.html — WMI coding, , Scripting, .
WSF- “” JS. .
www.microsoft.com/en-us/download/details.aspx?id=12028 — “” WMI-, ScriptomaticV2.hta. MUST HAVE JS, VBS, Perl WMI-. WMI- .
www.forensicmag.com
www.forensicmag.com/articles/2011/12/windows-7-registry-forensics-part-2
www.forensicmag.com/articles/2012/02/windows-7-registry-forensics-part-3
www.forensicmag.com/articles/2012/06/retrieving-digital-evidence-methods-techniques-and-issues-part-3
www.forensicmag.com/articles/2012/04/windows-7-registry-forensics-part-4
, , . , , “” , Registry , “”, , . , Registry, , , .
winintro.ru/diskmgt.ru/html/ebd2bd6e-8b1e-43b6-a2e3-483def6ad763.htm — (Spanned Volumes) .
xp-7.ru/blog/2011-01-13-101 — , .
www.webtropy.com/articles/art14-2.asp?Interop=WbemScripting — Reference WbemScripting C# and VB.NET
, , , reference Microsoft. , .
“ ”
, , , , . , , , .
2015.03.24 22:10:19 — 2015.03.31 15:45:14 Windows 8.1 Pro 9600
2015.03.31 16:26:15 — 2015.04.23 02:56:17 Windows 10 Pro Technical Preview 10049
2015.04.23 03:44:13 — 2015.04.29 06:36:13 Windows 10 Pro Technical Preview 10061
2015.04.29 07:25:43 — 2015.05.21 11:32:07 Windows 10 Pro Insider Preview 10074
2015.05.21 14:21:40 — 2015.05.28 21:13:37 Windows 10 Pro Insider Preview 10122
2015.05.28 22:04:16 — 2015.05.30 19:11:22 Windows 10 Pro Insider Preview 10125
2015.05.30 20:16:43 — 2015.07.01 11:17:37 Windows 10 Pro Insider Preview 10130
2015.07.01 12:11:53 — 2015.07.01 13:25:29 Windows 10 Pro Insider Preview 10158
2015.07.01 23:22:08 — 2015.07.03 22:25:40 Windows 10 Pro Insider Preview 10159
2015.07.03 23:21:16 — 2015.07.09 24:24:29 Windows 10 Pro Insider Preview 10162
2015.07.10 01:21:50 — Windows 10 Pro Insider Preview 10166
github:
github.com/sysprg-46/EnumerateDevicesAndVolumes/tree/master
.