• [アーティクル]

[ニュースレターアーカイブ ^][< Vol. 1、No. 4][Vol. 2、No. 1 >]

Systems Internals ニュースレター Vol. 1、No. 5

http://www.sysinternals.com
Copyright 1999 Mark Russinovich

1999 年 10 月 12 日 - 本号では:

  1. Systems Internals の新機能

    • NTFS for Windows 98/NTFSDOS Professional
    • DebugView v3.21
    • Filemon と Regmon v4.21
    • Diskmon v1.1
    • Systems Internals (www.microsoft.com)
    • 10 月 "NT Internals"
    • 新しくない内容

  2. 内部ニュース

    • Win2K RC2 DDK がリリースされました
    • 新しい Win2K RC カーネル API
    • Software Development '99 East
    • DiskEdit の使用

  3. 近日公開予定

    • Win2K API Explosion

スポンサー: WINTERNALS SOFTWARE

Systems Internals ニュースレターは、http://www.winternals.com. の Web で Winternals Software によって後援されています。 Winternals Software は、Windows NT/2K 用の高度なシステム ツールの主要な開発者およびプロバイダーです。 Winternals Software 製品には、FAT32 for Windows NT 4.0、ERD コマンダー (Windows NT 向けブート ディスク機能)、NTRecover などがあります。

Winternals Software の Remote Recover を使用すると、社内のどこからでも TCP/IP 経由で起動できないコンピューターのドライブにアクセスできます。 NT または Win9x システムをオフラインで維持しているドライバー、ファイル システム、構成の問題をリモートで修正することで、時間とコストを節約できます。 Remote Recovery を使用してリモート chkdsk またはパーティション分割操作を実行することもできます。これにより、汎用性の高いディザスター リカバリー ツールになります。 http://www.sysinternals.com/rrecover.htm で無料の読み取り専用試用版をダウンロードし、http://www.winternals.com. で読み取り/書き込みバージョンを購入します

皆さん、こんにちは。

Systems Internals ニュースレターへようこそ。 現在、ニュースレターの購読者数は 10,000 人です。

Windows 2000 (Win2K) のリリースは、差し迫った後に先送りされるというパターンに従っているように見えます。 最新の噂では、2 月に入手可能になるということです。 また、Microsoft が OEM やパートナーに出荷時期を知らせていないため、Win2K の出荷日に関する情報は噂のみです。 噂では、「準備ができたら出荷される」ということです (ワインの販売に関する古いことわざを無理強いしません)。

Microsoft に関してもどかしい点は、製品に関する報道では、製品がベイパーウェアである場合であっても出荷の寸前であるかのように常に見えることです。 最新の例は、Windows 98 の後継版である Millennium です。 Microsoft は以前から、すべての家庭電化製品をインテリジェントなデバイスに変換できる完成品であるかのように、報道で強力に後押ししました。 皮肉なことに、Microsoft がまだ製品を十分に定義しておらず、市販されるまでにおそらく 1 年以上かかることが、少し後に記事で明らかになりました。

このパターンは新しいものではなく、私が最初にそれについて書いたわけでもありません。 しかしそれでも、慎重に調整された計画がどのくらい一進一退を繰り返すかや、ソフトウェア エンジニアリング プリンシパルの完全な欠如の結果がどの程度であるかについて推測するのを止めることはできません。 前者の視点を取り上げると、陰謀論者のように、Microsoft は、その素晴らしい製品で顧客をじらすことで競争を見事に抑え、もう少し待てば、待ったことが価値のあるものになり、Microsoft 以外の製品に頼る必要がなくなります。 後者の視点では、Microsoft はソフトウェア開発プロセスを決して学習せず、エンジニアリング作業を引き続き過少評価し、ベータ コードの品質を過大評価します。

どちらの理論をとるかについて、私はどっちつかずです。 実際には、このパターンはどちらの理由からでもあると思います。 これは、Active Directory がここ 2 年間ほぼ準備できていたように Microsoft が振る舞うのに役立ったと思います。 確かに、Win2K を待つ必要がある時間を前もって知っていたら、ずっと前に Novell Directory Services に頼っていたお客様はいます。 一方、Microsoft は、有望な製品の出荷や遅延から報道で不評を繰り返してきました。 Microsoft の経営陣は、バグの最後の 5% を再現、分離、修正することがどれほど難しいかを理解していないだけだと思います。

Microsoft の開発手法と言えば、プレリリースの名前付けスキームは、私が見た中で最も不可解なものの 1 つです。 ベータ版は実際にはアルファであり、リリース候補は実際にはベータ版です。 これらの定義の使用さえも拡大解釈です。Microsoft には、あるリリース候補から次のリリース候補に移動したり、新しいリリース候補を追加したりする際に、ソフトウェアから機能を取り込むことに問題はありません。 NT 4.0 でそれを実行し、Win2K で実行中です。 この手法では、確かにリリース サイクルは高速化されません。

では、Win2K は 2 月に出荷されますか? トンネルの端に光が見えていると思います。 結局のところ、RC2 にはいくつかの新しい API しかありません。

Microsoft での頭字語の混乱について話した前回のニュースレターのフォローアップとして、読者の George Janczuk が別の例を見つけました。 "Extending to the Mainframe Transaction-Processing World" というタイトルのセクションで、http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm にある記事では CISC - Complex Instruction Set Computing と記載されています。 メインフレーム アプリケーションに精通している人にとって、対象の頭字語が CICS - Customer Information Control System であることは明らかです。 文字の順序を逆にすると、全く異なる技術分野になります。

いつもどおり、このニュース レターに興味を持ってくれそうな友達に伝えてください。

ありがとうございます。

-Mark

Systems Internals の新機能

NTFS FOR WINDOWS 98/NTFSDOS PROFESSIONAL

最終的に完了しました。 Bryce と私は 1996 年の春に NTFSDOS 1.0 をリリースして以来、Windows ファイルシステムの互換性の目標、すなわち Windows 9x と DOS からの NTFS の読み取り/書き込みアクセスを求めてきました。 NTFS 形式をリバース エンジニアリングし、この複雑なジャーナリング ファイルシステムのドライバーを作成することは、困難でリスクを伴う提案であるとずっと以前に判断しました。 形式の微妙な違いを正確に判断した場合でも、Win2K の NTFS v5.0 などの形式を更新するには、まったく新しいリバース エンジニアリングと開発作業が必要です。 さらに、NTFS と同様に複雑な形式のファイル システム ドライバーの正確性を検証することは、困難な提案です。

だから、私たちはうまく逃れました。

NTFS for Windows 98 は、Windows 95 または Windows 98 から NTFS ドライブへの完全な読み取り/書き込みアクセスを提供し、NTFSDOS Professional は DOS からの完全な NTFS 読み取り/書き込みアクセスを提供します。 NTFS for Windows 98 にも NTFSDOS Professional にも、NTFS ファイル システム形式に関する知識はありません。 代わりに、Windows NT または Windows 2000 インストールからの NTFS ドライバーを利用して、その知識を実装します。 どちらのユーティリティも、NTFS ファイル システム ドライバーの環境ラッパーとして機能する同じコード ベースを使用します。 NTFS for Windows 98 は、NTFS の上の Windows 9x ファイル システム API と NTFS の下の Windows 9x ディスク サービスとのインターフェイスを提供します。 NTFS for Windows 98 が NTFS に提示するインターフェイスは、NTFS のネイティブ Windows NT/2K 環境のように見え、IRP、I/O マネージャー、キャッシュ マネージャー、NT スタイルのディスク デバイス、NTFS が対話するその他の NT/2K サブシステムを備えています。

NTFSDOS Professional は NTFS for Windows 98 と同じように動作しますが、NTFS を上の DOS サービスと下の BIOS 割り込み 13 ディスク サービスとインターフェースで連結する点を除きます。 NT/2K のような環境を作成するために、NTOSKRNL、NT/2K カーネル ファイル内の多くの機能を利用します。 どちらのユーティリティも NTFS と連携して NTOSKRNL を読み込んで、NTFS はカーネルのネイティブ サービスの多くを直接使用できるようにします。

NTFS 環境を構築するのはとても楽しく、さらに一歩踏み出しました。NT の起動時の chkdsk ユーティリティ Autochk でも同じことを行いました。 NTFSDOS Professional と NTFS for Windows 98 には、NTFSCHK という名前の NTFS chkdsk ユーティリティが付属しています。 NTFSCHK は NTFS ファイル システム ラッパーと同じプリンシパルで動作します。この場合、Autochk プログラム用の NT のような環境が作成され、Autochk が Windows 95/98 と DOS で実行されます。 この複雑な処理の結果として、Windows 95/98 と DOS に対する NTFS 読み取り/書き込みサポートが完了します。

NTFS for Windows 98 の無料読み取り専用バージョンは http://www.sysinternals.com/ntfs98.htm でダウンロードでき、NTFSDOS Professional の無料読み取り専用バージョンは http://www.sysinternalscom/ntfspro.htm. でダウンロードできます。 両方のツールの完全な読み取り/書き込みバージョンは、Winternals Software (http://www.winternals.com.) で購入できます。

DEBUGVIEW V3.21

DebugView は、Windows 95、Windows 98、NT 4.0、Windows 2000 でカーネルと Win32 の両方のデバッグ出力をキャプチャするデバッグ出力モニターです。 高度なフィルター処理、強調表示、ログ記録機能を備え、ネットワーク経由でシステムからのデバッグ出力をキャプチャすることもできます。 最新リリースの 3.21 では、Windows 95 と Windows 98 で 16 ビットの OutputDebugString 出力を監視する機能が導入されています。

DebugView v3.21 は、http://www.sysinternals.com/dbgview.htm. でダウンロードできます

FILEMON と REGMON V4.21

Filemon と Regmon は、Windows 95、98、NT 4.0、Win2K 用のファイル システムおよびレジストリ スパイ ユーティリティです。 新しいユーザビリティ機能とリリース 4.21 (Filemon と Regmon ではバージョン番号が同期されています) で進化し続けています。最近のフィルター リスト、強調表示フィルターを定義する機能 (カスタム色も含む)、カスタマイズ可能なフォント、クリップボードのサポート、CUI 互換性の高いホット キーを使用して、より高度なフィルター機能が導入されています。 ドライバーのソース コードも修正され、GUI インターフェイス関数におけるより確実なパラメーター検証が組み込まれています。

Filemon v4.21 を http://www.sysinternals.com/filemon.htm でダウンロードし、Regmon v4.21 を http://www.sysinternals.com/regmon.htm. でダウンロードします。

DISKMON V1.1

Diskmon は、論理と物理のディスク アクティビティを監視および表示するツールです。 バージョン 1.1 では、Windows 2000 で動作するように Diskmon が更新され、新しい使いやすさの向上が導入されています。 さらに、Diskmon は多数のディスクおよび大容量ストレージ I/O 制御コードを解釈して、16 進数コードを Diskmon 出力ウィンドウでテキスト表現に変換するようになりました。

Diskmon v1.1 はディスク モニターとして機能するだけでなく、ソフトウェア ベースのディスク ライトとしても使用できます。 ディスク ライト モードで設定すると、Diskmon は、ディスク読み取りアクセスがあるときは緑色、ディスク書き込みアクセスがあるときは赤色のライトとしてシステム トレイに最小化されます。

Diskmon v1.1 のダウンロード: http://www.sysinternals.com/diskmon.htm.

WWW.MICROSOFT.COM における SYSTEMS INTERNALS

Systems Internals (旧 NT Internals) の歴史を考えると、Microsoft が顧客用のリソースとして sysinternals.com に言及していることはいかにもお世辞です。 Systems Internals ユーティリティを指す Microsoft サポート技術情報の記事が増えています。 最新の情報を次に示します。

  • Q183060 INFO: 80004005 のトラブルシューティング ガイドおよびその他のエラー メッセージ http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
    この記事では、Filemon を使用して、OLE DB、ActiveX Data Objects、Remote Data Service のデータ アクセス エラーの原因を確認できることが説明されています。

  • Q196453 - NTVDM および WOW スタートアップ エラーのトラブルシューティング http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
    この記事では、NTVDM (NT の Win16/DOS 互換性環境) のスタートアップ エラーの原因となっている欠落ファイルを特定するためのツールとして Filemon も参照しています。

  • Q216368 - PRB: ファイル使用中のアプリケーション セットアップ時のアクセス違反 http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP
    HandleEx と DLLView は、Visual Basic セットアップ ウィザードと配置ウィザードによって生成されるセットアップ プログラムの実行中に発生するエラーの原因を特定するための推奨ツールです。

  • Q232830 - HOWTO: ファイル ハンドルの所有権を決定する http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
    ファイルまたはディレクトリが開かれているプロセスを見つける方法について説明するこの記事で、HandleEx は再び推薦を受けています。

10 月 "NT Internals"

Windows NT Magazine 10 月号の "NT Internals" コラムは、"Inside Win2K の信頼性の強化、パート 3" です。 この 3 部構成のシリーズの 3 番目では、開発者と管理者がバグのあるドライバーを特定するのに役立つ 2 つの強力な Win2K 機能 (書き込み保護カーネル メモリとドライバー検証ツール) について説明します。

ロシアの読者は、母国語で記事を読めるようになりました。 ロシア語版の Windows NT Magazine (http://www.osp.ru/win2000/) に移動し、最初に翻訳された NT Internals コラム Inside the Boot Process (http://www.osp.ru/win2000/1999/10/59.htm). を確認してください。 これを知らせてくれた Ivan Rouzanov に感謝します。

8 月上旬の時点で、Windows NT Magazine のオンライン版の記事にはサブスクライバーのみがアクセスでき、新しい号ごとに記事がオンラインに投稿されます。 サブスクライブしていない場合は、http://www.sysinternals.com/publ.htm のサブスクリプション リンクから、Systems Internals サブスクリプションの割引を受けてください。

新しくない内容

WinObj は、Windows NT/2K Object 名前空間を探索するための強力なツールです。 Object 名前空間は、NT/2K の 3 つの名前空間 (Object 名前空間、Registry 名前空間、およびファイルシステム名前空間) の 1 つです。 Object 名前空間内のオブジェクトを介して、Registry 名前空間とファイルシステム名前空間にアクセスします。 たとえば、Win32 プログラムがレジストリ キー HKEY_LOCAL_MACHINE\Software\Microsoft を開くと、ADVAPI32.DLL ライブラリは名前を \Registry\Machine\Software\Microsoft に変換してから、カーネル サービス NtCreateKey を呼び出します。 WinObj の Object 名前空間のルートを見ると、Registry という名前の "key" 型のオブジェクトが表示されます。 Registry という名前は、キー名の最初のコンポーネントと一致するため、NT/2K オブジェクト マネージャーは、キー オブジェクトを定義するサブシステムに名前の残りの部分 \Machine\Software\Microsoft を渡します。 Configuration Manager カーネル サブシステムは Registry とキー オブジェクトを保持するので、名前の残りの部分を解析して目的のキーを見つけます。

WinObj を使用して、Object 名前空間を調べ、オブジェクトのセキュリティ プロパティを表示または設定できます。 Winobj は http://www.sysinternals.com/winobj.htm. でダウンロードしてください。 1997 年 10 月の NT Internals コラム "Inside the Object Manager" で、オブジェクト マネージャー名前空間と WinObj について説明しています。 このコラムのオンライン版については、http://www.sysinternals.com/publ.htm. からリンクを開いてご覧ください。

内部ニュース

WIN2K RC2 DDK がリリースされました

Microsoft の Device Driver Development Kit (DDK) の Win2K RC2 リリースは、http://www.microsoft.com/ddk/ddkRC2.htm. で今すぐダウンロードできます。 キットを無料でダウンロードすることも、オンラインでドキュメントを参照することもできます。

新しい WIN2K RC2 カーネル API

最新の Win2K カーネルで事態が安定しそうです。 ベータ 3 から RC1 まで約 12 個が出現し (さらに別の 6 個が消えた) とは対照的に、RC3 では、エクスポートされた新しいカーネル API は 4 つしかありません。 いくつかの新しい関数はやや興味深いので、それらについて記載することにしました。 1 つ目は MmGetSystemRoutineAddress です。文書化されていませんが、そのプロトタイプは RC2 DDK の ntddk.h ヘッダー ファイルに含まれています。

NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
    IN PUNICODE_STRING SystemRoutineName
    );

その使用法は、見た目と同じくらい簡単です。 NTOSKRNL.EXE または HAL.DLL のいずれかに存在する関数の名前を渡すと、エントリ ポイント アドレスが返されます。 この関数は、Win2K の最初のリリースでは実際に役に立ちませんが、今後非常に便利になる可能性があります。これは、Microsoft が NT の最初のリリース (3.1) に組み込む必要があった関数です。 Win32 アプリケーションのユーザー空間における GetProcAddress のように、この関数を使用すると、ドライバーは API の可用性を動的に確認できます。 Microsoft が Win2K サービス パックに新しい API を追加すると (そうすると確信しています)、API を利用するためにドライバーを作成できますが、古いバージョンの Win2K で適切な手順でエラーになるか、API を使用しないモードで実行することもできます。 これを行うことができるドライバーにとって重要なのは、読み込み後に API が存在するかどうか確認できることです。 この機能がないと、ドライバーは使用する関数と静的にリンクする必要があります。ドライバーが読み込まれるときに関数が存在しない場合、カーネル ローダーはユーザーに醜いエラーを報告し、ドライバーの読み込みに失敗します。

2 つ目の新しい API は MmGetPhysicalMemoryPages です。 ここでも、そのプロトタイプは RC2 ntddk.h にありますが、文書化されていません。 そのプロトタイプは次のとおりです。

NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
    VOID
    );

ここで、PHYSICAL_MEMORY_RANGE は次のとおりです。

typedef struct _PHYSICAL_MEMORY_RANGE {
    PHYSICAL_ADDRESS BaseAddress;
    LARGE_INTEGER NumberOfBytes;
} PHYSICAL_MEMORY_RANGE, *PPHYSICAL_MEMORY_RANGE;

この関数は、PHYSICAL_MEMORY_RANGE エントリの配列を戻し、配列の末尾は、BaseAddress と NumberOfBytes の両方に 0 を持つエントリでマークされます。 MmGetSystemRoutineAddress と同様に、非常に単純な API です。 Win2K が認識しているすべての物理メモリの説明が返されます。 Win2K では、MmAddPhysicalMemory API と MmRemovePhysicalMemory API を使用して、実行時のメモリの追加と削除がサポートされます。 このため、メモリ範囲にクエリを実行できるようにする API が存在します。 MmAddPhysicalMemory は RC1 で追加され、MmRemovePhysicalMemory は RC2 で追加されました。 これらの関数はどちらも、ntddk.h でプロトタイプ化されています。

他の新しい RC2 API は何ですか? PoShutdownBugCheck および RtlInvertRangeList。 PoShutdownBugCheck では、システムをクラッシュさせ、中断などの電源関連のアクションを実行できます。 RC2 カーネルによっていくつかの場所で使用されます。 範囲は一般的な開始終了の指定であり、ユーザーによって定義され、管理、並べ替え、反復処理のために複数のカーネル API によってサポートされます。 Win2K プラグ アンド プレイ リソース アービターでは、それらを使用してハードウェア リソース要件を追跡および整理します。 range-list API は文書化されていませんが、すべてのプロトタイプと構造体定義は ntddk.h に含まれているため、API を使用して独自の開始終了指向データを管理できると考えられます。

今後のニュースレターでは、文書化されていない API に引き続きご注目ください。

SOFTWARE DEVELOPMENT 99 EAST

1999 East Coast edition of Software Development が、11 月 8 日から 12 日までワシントン D.C. で行われます。 最終日に、What's New in Windows 2000 For Developers、Inside the Windows NT/2000 Blue Screen、Inside Windows NT/2000 Networking.という 3 つの講演を行います。 さらに、Inside Windows NT 2nd Edition の著者であり、隣人 (彼はコネティカット州ダンベリーで我が家からほんの 20 分のところに住んでいます) である Dave Solomon と私は、Windows NT/2K 内部機能の円卓会議のホストを務めます。 Windows NT/2K の内部に関する最も難しい質問に一緒に答えます。 声を掛けてニュースレターについて言及してください。無料の Systems Internals Tシャツを差し上げます。

ソフトウェア開発 Web サイトには http://www.sdexpo.com. でアクセスしてください。

DISKEDIT の使用

ご存じないかもしれませんが、実績のある Norton Disk Edit for DOS のスタイルで Windows NT 用のディスク エディター ユーティリティがあります。 その上、このユーティリティは FAT と NTFS を理解し、無料です。 Microsoft は、Windows NT 4.0 Service Pack 4 CD で DiskEdit を誤って出荷したようです。これは、ファイル システム チーム用の内部デバッグ ツールでなければなりません。 DiskEdit には、文書化するには小さなマニュアルが必要になる独特のインターフェイスがありますが、簡単なチュートリアルから始めるつもりです。 DiskEdit は、NTFS を理解していることが分かっている唯一の公開ツールであるため、DiskEdit を使用して NTFS ファイルシステム形式を解明することに焦点を当てます。

まず、Service Pack 4 (SP4) CD-ROM から DiskEdit を取得する必要があります。 \i386 ディレクトリからお使いのハード ディスクにコピーするだけです。 Win2K で DiskEdit を使用する場合は、専用ディレクトリを作成し、SP4 winnt\system32 ディレクトリ (または SP4 CD) から DiskEdit と同じディレクトリに DLL (IFSUTIL.DLL、ULIB.DLL、UNTFS.DLL、UFAT.DLL) をコピーする必要があります。 これで DiskEdit を開始できます。

このチュートリアルでは、NTFS ドライブのルートに TEMP というディレクトリを作成し、そのディレクトリに OUT.TXT という名前のファイルを作成します。これには、現在のディレクトリとして TEMP を使用してコマンド プロンプト ウィンドウに次のコマンドを入力します echo hello > out.txt。 DiskEdit で新しい OUT.TXT ファイルを含むドライブを選択します。これには、[ファイル]|[開く] メニューを選択し、表示されるダイアログ ボックスの [ボリューム名] フィールドにドライブの文字を入力します。 必ずコロンを含めてください (例: "d:")。 DiskEdit のほぼすべての機能を使用するには、ドライブを開いている必要があります。

NTFS ドライブのルート ディレクトリから始めて、OUT.TXT ファイルを見つけます。 メニューエントリ [読み取り]|[NTFS ファイル レコード] を選択して、番号を入力するだけで MFT レコード エントリを表示できるようにするダイアログ ボックスを開きます。 すべての NTFS ドライブの最初の 16 個の MFT レコード エントリは予約済みであり、事前に定義済みの NTFS メタデータ ファイルに対応します。 番号の割り当てを次に示します (DiskEdit ではすべての入力が 16 進数として解釈されることに注意してください)。

        0: $MFT - MFT
        1: $MFTMirr - MFT Mirror (a copy of the first 4 entries of the MFT)
        2: $LogFile - NTFS LogFile
        3: $Volume - volume information file
        4: $AttrDef - the attribute definition file
        5: . - the root directory
        6: $Bitmap - the volume allocation bitmap file
        7: $Boot - the boot sector
        8: $BadClus - the bad cluster database file
        9: $Secure - new to SP4, the security attribute database
        A: $UpCase - the lower-to-upper case mapping file
        B: $Extend - new to Win2K, the directory that contains
                             the reparse, object ID, and quota metadata files
        C-F: Unused as of NTFS v5.0 (Win2K)

次に進み、これらの MFT エントリのいくつかを調べます。 共通のテーマに気付き始めます。これらはすべて、$INDEX_ROOT、$FILE_NAME、$DATA のような属性で構成されています。 ファイルに固有のデータが格納されている属性にあります。 属性データが小さい場合、NTFS はファイルの MFT レコード内にデータを "常駐" データとして格納します。データが大きい場合、NTFS はディスク上のクラスターにレコード外部のデータを "非常駐" データとして格納します。

次に、ファイル番号として「5」と入力すると、ルート ディレクトリのファイルが表示されます。 ディレクトリの $INDEX_ALLOCATION 属性 (ディレクトリの内容を記録する、ディレクトリに固有の属性) を表示して、ルート ディレクトリ内にあるファイルとディレクトリを確認します。 これを行うには、[読み取り]|[NTFS 属性] メニュー エントリを選択します。別のダイアログ ボックスが開きます。 DiskEdit では大文字と小文字が区別されるため、次のように正確に入力してください。

        Base Frs Number: 5

Base Frs (ベース ファイル レコード セグメント) は、MFT 番号の別の名前です。 ルート ディレクトリから属性を読み取ることを指定するには、「5」と入力します。

        Attribute Type: $INDEX_ALLOCATION

これは、ディレクトリのコンテンツ データを読み取ることを DiskEdit に示します。 DiskEdit は属性の種類の入力方法に非常にこだわるので、プルダウン メニューを使用して必要な属性を選択することをお勧めします。

        Attribute Name: $I30

ルート ディレクトリの $INDEX_ALLOCATION 属性を表示すると、"$I30" が名前として "Type code, name" 行に表示されます。そのため、それを属性名として入力します。

[OK] を押すと、属性の内容の 16 進ダンプが表示されます。 もっと分かりやすいものを見たいので、[表示]|[NTFS インデックス バッファー] メニュー エントリを選択します。 ディレクトリの内容の一覧が表示されます。 "TEMP" という名前のエントリが表示されるまで、一覧をスクロールします。 表示されない場合、エントリは、ディレクトリにも関連付けられている属性の種類である、ルート ディレクトリの $INDEX_ROOT 属性に配置され、その値は常に MFT レコードに格納されます。 インデックス ルート エントリと割り当てエントリをまとめて、ディレクトリのすべてのエントリを格納する B+ ツリー構造が形成されます。 $INDEX_ROOT 属性を表示する必要がある場合は、$INDEX_ALLOCATION 属性を表示する場合と同じ手順に従って、その属性を表示します。 インデックス バッファーをスクロールすると、2 行のアスタリスクが表示される場合があります。これらは、1 つのインデックス バッファーの末尾と次のインデックス バッファーの先頭を指定します。

TEMP ディレクトリのエントリが見つかったら、そのファイル参照 (FRS) を書き留めます。 [読み取り]|[NTFS ファイル レコード] を選択し、TEMP の FRS を入力します。 次に、TEMP ディレクトリの MFT レコードを確認します。 OUT.TXT ファイルを見つけたいので、TEMP の内容を調べて見つける必要があります。 TEMP ディレクトリの $INDEX_ALLOCATION (または $INDEX_ROOT) 属性を表示し、データを NTFS インデックス バッファーとして表示するように切り替えて、OUT.TXT ファイルを見つけます。 属性選択ダイアログで、TEMP の FRS を基本 FRS 番号として入力してください。 TEMP を作成したばかりの場合は、$INDEX_ROOT のみがあります (何かを誤って入力すると、DiskEdit の空のエラー ダイアログが表示されます)。

OUT.TXT が見つかり、その FRS を判別したら、[読み取り]|[NTFS ファイル レコード] を使用して MFT エントリを調べます。 $DATA 属性が見つかるまでスクロール ダウンします。 これで、OUT.TXT のデータの場所が表示されます。 小さいファイルを作成したので、データは MFT レコードに格納されます。 DiskEdit を使用して OUT.TXTの $DATA 属性を表示しようとすると、DiskEdit に常駐データが正しく表示されないため、何も表示されません (DiskEdit の多数のバグの 1 つ)。 そのため、やや大きい (> 2KB) テキスト ファイルを \TEMP\ OUT.TXT にコピーします。 次の 2 つの方法のいずれかで OUT.TXT データを表示できます。[読み取り]|[NTFS クラスター] を使用し、OUT.TXT の $DATA 属性 "Extent List" に表示される最初の "lcn" 値を指定することで、データの開始 (またはディスクに連続して格納される場合はそのすべて) を調べることができます。または、[読み取り]|[NTFS 属性] を使用し、属性の種類として "$DATA" と入力し、属性名として何も入力しません (そのフィールドには何も入力しないので)。

エクステント リストは、属性の非常駐データの場所を記述します。 最大 16 個の長さのクラスターの連続した各データ ブロックは、1 つのエクステント・リスト・エントリによって記述されます。 エクステント・リスト エントリは、仮想クラスター番号 (vcn)、論理クラスター番号 (lcn)、およびランレングスを指定します。 Vcn は、エントリによって記述されたデータが開始されるファイル内のクラスターです。 Lcn は、データがディスク上に格納されている論理クラスターを指定し、ランレングスは、その場所にある属性データのバイト数です (DiskEdit は 16 進数値を表示することに注意してください)。

ディレクトリの内容をスキャンする方法を示すことで、OUT.TXT ファイルの MFT レコードを見つける方法を長々と説明しました。 ただし、ショートカットがあります。[クラック]|[NTFS パス] を選択し、「TEMP\OUT.TXT」と入力します。 OUT.TXT の FRS が表示され、[読み取り]|[NTFS ファイル レコード] を使用してすぐに進むことができます。

これにより、DiskEdit 入門の最後に進みます。 FAT または NTFS ドライブを参照することによって、この気の利いたツールを試してみることをお勧めします。 ディスクを救うために DiskEdit を使用してデータを変更する機会はほとんどありませんが、NTFS のディスク上のフォーマット (FAT フォーマットは明確に文書化されています) に興味がある場合は、調査に最適なツールです。

近日公開予定

WIN2K API EXPLOSION

RC2 でデビューした新しいエクスポート カーネル モード API は 4 つしかありませんが、カーネルとコア Win32 DLL の両方で、NT 4.0 以降に Microsoft が導入した API の総数は爆発的に増加しました。 来月、新しい API の数とそれらが出現した場所を正確にお知らせします。残念ながら、Win2K が肥大化したモンスターであると信じている人々に、alt.advocacy.linux Usenet の騒ぎの大きな攻撃材料を与えることにもなります。

Systems Internals ニュースレターをお読みいただき、ありがとうございました。

公開日: 1999 年 10 月 20 日 (水) 午後 7:10 by ottoh

[ニュースレターアーカイブ ^][< Vol. 1、No. 4][Vol. 2、No. 1 >]