• [アーティクル]

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

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

http://www.sysinternals.com

1999 年 5 月 15 日 - 本号の内容:

  1. Systems Internals の新機能

    • SDelete
    • BlueScreen スクリーン セーバー Win2K 更新プログラム
    • "Linux とエンタープライズ"
    • "NT ユーティリティの内部"
    • Windows NT Magazine 5 月号のコラム
    • 新しくない内容

  2. 内部ニュース

    • Dr. GUI のまずい対応
    • WinDev '99 East
    • Numega ドライバー製品リリース間近
    • Beta 3 DDK のリリース
    • Win2K のキュー スピンロック

  3. 近日公開予定

    • Win2K System File Protector (SFP)

スポンサー: 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 などがあります。

皆さん、こんにちは。

Systems Internals ニュースレター第 2 版へようこそ。 このニュースレターの購読者は現在 2,700 人で、購読者数は依然として好調です。

前回のニュースレター以降、Microsoft は Windows 2000 Beta 3 を正式にリリースしました。 Beta 3 カーネルのビルド番号は 2031 ですが、NT 4.0 の初期リリース カーネルのビルド番号は 1381、NT 3.51 のビルド番号は 1025 でした。 . 私が奇妙に感じる (そしてやや迷惑な) のは、Microsoftがオペレーティングシステムのフル ビルドを行うたびに (毎日) ビルド番号をインクリメントすることです。ただし、報告されるカーネルのビルド番号は、最初のパブリック リリースのビルド番号を反映しています。 たとえば、NT 4.0 Service Pack 5 カーネルの実際のビルド番号が 1381 よりもはるかに大きい場合でも、カーネルはビルド番号として 1381 を報告します。

Windows 2000 の Beta 3 リリースは、開発者コミュニティへのウェイクアップ コールを目的としています。 Microsoft は、10 月に Windows 2000 を出荷すると発表しました。Beta 3 は、出荷される製品の機能が完全なバージョンを表しているため、開発者は、根本から変更されるのを心配する事なく新しい製品を作成し始めることができます。

Windows 2000 には、新しい API、階層化されたサービス、カーネルの機能強化が組み込まれています。 デバイス ドライバー開発者にとって特に顕著な変更の 1 つは、ブルー スクリーン (BSOD) が変更されたことです。 NT の以前のバージョンでは、BSOD には、システム上のすべてのドライバーのリンク時間と読み込みアドレス情報に加えて、クラッシュ時に存在していたスタックのダンプが表示されていました。 Windows 2000 では、停止コードと関連するアドレス行 (アドレス行によって、1 つ以上の停止コード パラメータがデバイス ドライバー内の位置に変換されます) のみが、詳細メッセージと共に表示されます。 サポート メッセージでは、BIOS とハード ドライブの設定を確認し、ソフトウェアとウイルス スキャナーの最適化を無効にして、再度クラッシュが発生するのを回避することが提案されます。 Microsoft Premier サポート サービス (PSS) は、経験と顧客からのフィードバックに基づいて、NT 4 スタイルの BSOD がクラッシュの原因を特定するのに役立たないと判断しました。

私は個人的に、読み込まれたドライバーの一覧、特にスタック ダンプが、ユーザーからドライバーのバグ レポートを取得するときに役立つと感じました。ユーザーに数メガバイトのクラッシュ ダンプを送信させるよりも、この情報を取得する方がはるかに簡単かつ迅速です。 スタック ダンプに基づいてクラッシュの原因を特定し、ドライバーの一覧に表示されるバージョン情報に基づいてユーザーが読み込んだドライバーのバージョンを確認することがよくあります。 皆さんがどう思っているか興味があります。NT 4 スタイルの BSOD が Windows 2000 に引き継がれることを望みますか、それとも新しい BSOD 形式で十分ですか? ご意見がございましたら、メールをお送りください。 この非公式アンケートの結果については、次回のニュースレターで報告する予定です。 BSOD の話題のついでに、今号で取り上げている大人気の Systems Internals BlueScreen スクリーン セーバーの Windows 2000 更新プログラムもぜひチェックしてください。

ありがとうございます。

-Mark

Systems Internals の新機能

SDELETE

C2 セキュリティ評価要件を満たす Windows NT 4.0 の一部として、"オブジェクト再利用保護" が実装されています。 これは、アプリケーションが初めてリソースにアクセスするときに、NT がアプリケーションに割り当てられたファイルおよびメモリ リソースをゼロにすることを意味します。 これにより、たとえば、アプリケーションが大きなファイルを作成すると、その中身を調べてディスクに以前何が保存されていたかを確認できなくなります。 ただし、オブジェクト再利用保護は、標準のリソース関連 API をバイパスする、またはオペレーティング システムを完全にバイパスするアプリケーションがアクセスできるリソースの保護には適用されません。 たとえば、リソース キットの DiskProbe などのディスク エディターを使用して、ディスクの未割り当て部分の内容を調べることができます。 これにより、削除されたファイルに以前属していたデータを表示できます。

多くの環境では、"安全な削除" 機能が必要です。 この機能を使用すると、ユーザーは機密データを完全に削除して、オペレーティング システムの保護機能をバイパスするツールで表示されないようにすることができます。 暗号化ファイル システム (EFS) の登場により、Windows 2000 において安全な削除機能の必要性が浮き彫りになりました。 以前に暗号化されていなかったファイルを暗号化する場合、EFS ではディスク割り当てを解放するときに、そのファイルの暗号化されていないデータを含むディスク割り当ての内容は消去されません。 したがって、暗号化したファイルのアクティブなバージョンは安全ですが、NTFS がその部分に割り当てる新しいファイル データによって上書きされるまで、古いバージョンのファイルはディスクの未割り当て部分に存在したままになります。

この穴を埋めるために、SDelete (Secure Delete) を作成しました。 これは、標準ファイルを安全に削除するだけでなく、ディスクの未割り当て部分に存在する、以前に削除されたデータも安全に削除できるコマンドライン ツールです。 さらに、Windows NT/2000 圧縮、暗号化、およびスパース ファイルでも動作し、defragmentation API を使用する必要があります。 SDelete は、国防総省のクリアとサニタイズの標準 DOD 5220.22-M に準拠しているため、データを削除すると、そのデータは永久に失われます。

SDelete の完全なソース コードとその仕組みの説明を提供します。これにより、SDelete が defragmention API をどのように利用しているのかを確認できるようになり、削除された機密データの回復を妨げるという私の主張を検証できるようになります。

Windows NT/2000 の defragmentation API に関するドキュメントは、http://www.sysinternals.com/defrag.htm. にあります 完全なソース コードを含む SDelete は http://www.sysinternals.com/sdelete.htm. からダウンロードしてください。

BlueScreen スクリーン セーバー Win2K 更新プログラム

Microsoft が Windows 2000 の NT スタートアップ画面 とブルー スクリーン (BSOD) レイアウトに加えた変更により、System Internals BlueScreen スクリーン セーバーにメジャー アップデートが必要になりました。 BSOD のリアリズムを最大限に提供し続けるため、スクリーンセーバーのバージョン 2.0 をリリースしました。 これは、BSOD 形式の変更を反映するだけでなく、Windows 2000 の起動画面を正確に模倣しており、回転する進行状況ストライプと進行状況バーの更新を備えています。 このスクリーンセーバーは Windows 2000 のエキスパート ユーザーや開発者ですらだまされるほどリアルです。 もちろん、NT 4.0 の BlueScreen スクリーン セーバーでは、引き続き NT 4.0 BSOD および起動画面が表示されます。

どうやって Windows 2000 のスタートアップ画面を完璧に再現し、しかも著作権法に違反しないようにしたのでしょうか? このスクリーン セーバーには、Windows 2000 スタートアップ ビットマップ グラフィックスは含まれていません。 代わりに、DirectX を使用して、起動シーケンス中にグラフィックス モードを Windows 2000 で使用されるのと同じモードに切り替えてから、Windows 2000 カーネル ファイル (ntoskrnl.exe) のビットマップ リソースを参照しています。 これらのリソース (Visual Studio で ntoskrnl.exe のリソースを開いて表示できます) は、カーネルが表示するものであり、スタートアップ・グラフィックスが実際には別のファイルであった Windows 9x の方法に変更を加えたものです。 Windows 2000 のスタートアップ エクスペリエンスをカスタマイズする機会は、コンピューター OEM には与えられていないようです。

BlueScreen スクリーン セーバーは、http://www.sysinternals.com/bluescreen.htm. からダウンロードできます。 スクリーンセーバーで誰かをだましたユーモラスなエピソードがあれば、ぜひ教えてください。

BSOD の仕組みと理由の詳細については、1997 年 12 月の Windows NT Magazine の「NT Internals」コラム「ブルー スクリーンの内部」を参照してください。 Systems Internals Publications ページのリンク (http://www.sysinternals.com/publ.htm) をクリックすると、そのコラムのオンライン バージョンに移動します。 このページには、私が執筆した他の記事やコラムのオンライン プレゼンテーションへのリンクも含まれています。

"Linux とエンタープライズ"

Windows NT Magazine 4 月号に掲載された Linux カーネルのスケーラビリティの欠陥に関する私の記事に対する Linux コミュニティからの大きな反響を受けて、記事のオンライン バージョンを予定より早く掲載することになりました。 「Linux とエンタープライズ」という記事へのリンクは、http://www.sysinternals.com/publ.htm. の「記事」セクションにあります。 この記事では、効率的なイベント待機メカニズムの欠如、重要なシステムコールのシリアル化、非同期 I/O の欠如、および sendfile (NT では TransmitFile と呼ばれる) socket API の不十分な実装など、Linux カーネルの現在のリリース (2.2x) のいくつかの制限について説明しています。 これらの制限の組み合わせにより、Linux は、Web サーバー、データベース サーバー、電子メール サーバーなどのエンタープライズ クラスのアプリケーションにおいて、パフォーマンスの面で NT やその他の UNIX と真っ向から競争するのを妨げられています。

"NT ユーティリティの内部"

Filemon、Regmon、または HandleEx を使用したことがあり、それらがユーザーに何を伝え、どのように実装されているかについて詳しく知りたい場合は、2 月の Windows NT Magazine コラム「NT ユーティリティの内部」に興味があるでしょう。このコラムでは、これらのツールの内部について説明しており、Regmon と Filemon については、レジストリやファイル システムのアクティビティのキャプチャ中にログに記録されるエラー コードと要求の種類について少し紹介しています。 利用可能になったばかりのこの記事のオンライン バージョンへのリンクは、http://www.sysinternals.com/publ.htm. にあります。

Windows NT Magazine 5 月号のコラム

Windows NT/2000 がレジストリの内容をメモリ内またはディスク上でどのように整理しているのか疑問に思ったことはないですか? Windows NT Magazine の最新号 (5 月号) には、このことなどを説明しているコラム「レジストリの内部」が掲載されています。 たとえば、Configuration Manager カーネル モード サブシステム (レジストリの管理を担当するサブシステム) がどのようにキーを検索し、値データを保存し、検索を最適化し、ディスク上のレジストリ ファイルの整合性を保護しているのかを説明しています。 Windows NT Magazine (http://www.winntmag.com) は、Borders および Barnes and Nobles で入手できます。

新しくない内容

Windows 2000 Beta 2がリリースされて間もなく、私はカーネル イメージ ファイル (ntoskrnl.exe) のチェック (デバッグ) ビルドを取り出し、カーネルを文字列検索したところ、カーネルのビルドに使用されたソース ファイル名のリストが出てきました。 NT/2000 カーネルのチェック ビルドには、Assert が存在するファイルのファイル名を含む多数の Assert ステートメント (整合性チェック) が含まれています。 カーネル ソース内の実質的にすべての重要なファイルに少なくとも 1 つの Assert があると仮定すると、このリストはかなり包括的なものになります。 このリストを Java スクリプトにダンプすると、Windows 2000 ソース ツリーのディレクトリ構造を示すエクスプローラーのようなツリー ビューが得られました。 http://www.sysinternals.com/nt5src.htm. でご確認ください

内部ニュース

Dr. GUI のまずい対応

Microsoft Developer Network News の 3 月/4 月号で、Dr. GUI は、ドライバーがそのスレッドをアフィニティ化 (特定の CPU の使用を強制) する方法を尋ねる読者からの質問に回答しました。 Dr. GUI は、ドライバーからシステム上のプロセッサの数を判断する方法がなく、ドライバー スレッドは実行されているプロセッサを見分けることができないと返答しました。 残念ながら、Dr. GUI はこの診断を覆しました (Dr. GUI は GUI に専念するべきかもしれません)。

NT カーネル (ntoskrnl.exe) は、NTTDK.H で次のように定義されている KeNumberProcessors という名前の変数をエクスポートします。

extern PCCHAR KeNumberProcessors;

これは、次のようにドライバーで直接参照できます。

CHAR    i;

for( i = 0; i < *KeNumberProcessors; i++ ) {

    // do processor specific stuff
}

ドライバー スレッドが実行されているプロセッサを特定するには、KeGetCurrentProcessorNumber() を使用します。これは、NTTDK.H で定義されているだけでなく、DDK にも実際に文書化されている別のカーネル エクスポートです。

Dr. GUI が、この病気に対して間違った薬を処方したため、私は丁寧にメールで Dr. にその旨を伝えました。 驚いたことに、Dr. GUI はそのメールに応答すらしませんでした。 次号で善良な Dr. が間違いを認めるかどうか見てみましょう。

WinDev '99 East

Windows 開発者向けのプレミア会議の 1999 東海岸版は、間もなく開催されます。 WinDev '99 East は、6 月 14 日から 18 日に Boston Cambridge Marriot で開催されます。 Jeff Richter、Jeff Prosise、Don Box など、Windows 開発の多くのビッグ ネームが登壇します。 私は、デバイス ドライバーのトラックに Jamie Hanrahan と Brian Catlin と一緒に参加します。プレゼンテーションには、NT 内部に関する 1 日のチュートリアルと、Windows NT/2K ファイル システム ドライバーの作成に関するチュートリアルと、高度なデバイス ドライバー開発の問題に関するチュートリアルがあります。 ぜひご参加ください。

Numega ドライバー製品リリース間近

Compuware NuMega Labs は、強力な新しい Windows 9x/NT/2K デバイス ドライバー開発キット DriverStudio のリリースを目前に控えています。 DriverStudio は、DriverAgent、DriverWorks、SoftICE、VtoolsD など、NuMega の既存のすべてのデバイス ドライバー ツールを組み合わせ、ドライバー用の BoundsChecker と FieldAgent (Windows NT/2K のみ) を追加します。

BoundsChecker のデバイス ドライバー バージョンは、ドライバーが使用するすべてのカーネル API の包括的な監視を提供します。これを使用して、ドライバーとシステム上の他のデバイス ドライバーとの相互作用を監視できます。 FieldAgent を使用すると、クライアント システムに BoundsChecker のドライバー バージョンを展開して、クライアントが分析可能なトレースを収集できるようになります。 DriverStudio のお客様向けの無料更新プログラムとして、TrueTime for drivers と TrueTime for drivers が近日中に提供される予定です。これらは、デバイス ドライバーのパフォーマンス チューニングとカバレッジ テストを簡単に行えるツールです。

このパッケージは究極のドライバー開発キットであり、心からお勧めします (私はベータ プログラムに参加しています)。 詳細については http://www.numega.com. をご覧ください

Beta 3 DDK のリリース

Windows 2000 Beta 3 のリリースに関連して、Microsoft は Windows 2000 Beta 3 DDK (デバイス ドライバー キット) を無料でダウンロードできるようにしました。 DDK は http://www.microsoft.com/ddk/ddk2kb3.htm. で入手できます。 Beta 3 には MSDN の 4 月版の時点で文書化されていない Win32 API が多数あるため、SDK がすぐに続くことを期待しています。

Win2K のキュー スピンロック

Windows 2000 では、グローバル ロックに "キュー スピンロック" と呼ばれる新しい種類のスピンロックが使用されます。 Windows 2000 のグローバル ロックは、Windows NT 4.0 のロックと同じであり、次のものが含まれます。

  • KiDispatcherLock: スケジューラ データベース ロック
  • KiContext-SwapLock: トレッド スワップ ロック
  • MmPfnLock: 物理ページ フレーム データベース ロック
  • MmSystemSpaceLock: カーネル モード アドレス空間ロック
  • CcMasterSpinLock: キャッシュ マネージャーのグローバル スピンロック
  • CcVacbSpinLock: キャッシュ マネージャーのマッピング配列ロック

ユニプロセッサでは、キュー スピンロックは通常のスピンロックとまったく同じように機能します。 ただし、NT のマルチプロセッサ ビルドでは、キュー スピンロックは大きく異なります。 標準のスピンロックと同様に、キュー スピンロックは HAL に実装されます。 カーネルは、HAL 関数 KeAcquireQueuedSpinlock を呼び出してキュー スピンロックを取得し、KeReleaseQueuedSpinlock を呼び出してキュー スピンロックを解放します。 KeAcquireSpinlock および KeReleaseSpinlock (カーネルが標準のスピンロックの取得と解放に使用する HAL 関数) には、パラメータとして、指定されたスピンロックのアドレスが必要です。 これに対し、キュー スピンロックの関数は、グローバル スピンロックのインデックス番号を受け取ります。 カーネルは、配列内のグローバル スピンロックを初期化します。各スピンロックには、カーネルが HAL に対してそれらを識別するために使用する定義済みのインデックス番号があります。 したがって、キュー スピンロックのグローバル配列を拡張する方法がないため、キュー スピンロックを定義してデバイス ドライバーで使用することはできません。

Windows 2000 では、SMP 内の各プロセッサ制御領域 (PCR) (プロセッサごとに 1 つの PCR があります) には、キュー スピンロックと同じ数のエントリを持つ配列があります。 各配列エントリには、2 つのフィールド (対応するキュー スピンロックへのポインター ("スピンロック" フィールド) と "キュー" フィールド) が含まれています。 次の説明で、スピンロックおよびキュー フィールドに言及するときは、取得または解放されるスピンロックの配列エントリに関連付けられているフィールドについて話しています。

KeAcquireQueuedSpinlock は次のように動作します。この関数は、インターロック交換 CPU 命令を使用して、現在のプロセッサの PCR のアドレスをスピンロックに配置することにより、スピンロックの取得を試みます。 スピンロックが保持されている場合、この関数は交換操作の一部として、別のプロセッサの PCR のアドレスを持ちます。 その後、関数は、自身の PCR 内のスピンロック フィールドの下位ビットを切り替えることで、自身を "待機中" として識別します。 次に、スピンロックから取得した PCR のキュー フィールドに、自身の PCR アドレスを配置します。 最後に、スピンロック フィールドの下位ビットがオフに切り替わるまでビジー ループで待機します。ビットがオフになると、現在のプロセッサにスピンロックが付与された状態になるため、取得関数の呼び出し元に戻ります。

プロセッサは、キュー スピンロックを取得し、ロックを保持している間に必要な処理を完了した後、KeReleaseQueuedSpinlock を呼び出します。 KeReleaseQueuedSpinlock は、現在のプロセッサの PCR 内の指定されたスピンロックのキュー フィールドを確認します。 キュー フィールドが 0 以外の場合、別のプロセッサがそこに PCR を "キュー登録" しています。 KeReleaseQueuedSpinlock は待機中の PCR のスピンロック フィールドの下位ビットをクリアし、その後、自身のキュー フィールドをクリアして戻ります。 待機中の PCR のスピンロック フィールドの下位ビットをクリアすることで、次の CPU にロックを設定できることを通知したことになります。 キュー・フィールドがゼロの場合、ロックを待機している他のプロセッサはなく、KeReleaseQueuedSpinlock は単にインターロック交換操作を実行してグローバル・スピンロックをクリアします。

キュー スピンロックの操作は、プロセッサが、保持されているスピンロックの待機を "一列に並べる" ものです。 各プロセッサは、前に並んでいるプロセッサに待機中であることを通知することで、自分自身をキューに登録します。 これにより、キュー スピンロックの取得に決定的な順序が与えられ、プロセッサは要求された順序でスピンロックを取得します。 標準のスピンロックの場合、そのような順序はありません。 キュー スピンロックには、さらに大きな利点があります。 プロセッサがスピンロック フィールドの下位ビットがクリアされるのを待ってスピンしている間、自分専用のメモリ上でスピンしています。 ビジー状態のプロセッサが標準のスピンロックを待機しているときは、すべてのプロセッサで共有されるグローバル スピンロック自体でスピンします。 したがって、キュー スピンロックは、ビジー待機中に共有キャッシュライン アクセスがないため、より優れたマルチプロセッサ バス特性を備えています。 さらに、キュー スピンロックのキューイングの性質上、通常、ロックが複数のプロセッサの競合下にある場合、標準のスピンロックよりもバス ロック操作が少なくなります。

キュー スピンロックは、Microsoft が Windows 2000 のマルチプロセス スケーラビリティを実現したいくつかの機能強化の 1 つです。

近日公開予定

Windows 2000 には、オペレーターのエラーやアプリケーションの誤動作に対する回復性を高める多数の機能が含まれています。 そのうちの 1 つは、%systemroot%\system32 および %systemroot%\system32\drivers ディレクトリにある DLL とドライバーの多くが、System File Protector (SFP) と呼ばれるウォッチドッグによって保護されていることです。 その system32 ディレクトリに移動し、ntoskrnl.exe の名前を変更することで、その存在を確認できます。 ウォッチドッグが起動し、保護されたシステム ファイルの改ざんを検出して、修復中であることを通知します。 ディレクトリを再度確認すると、ntoskrnl.exe が魔法のように置き換えられていることがわかります。 次回は、このしくみについて説明します。

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

公開日: 1999 年 5 月 15 日 (土) 午後 7:15 by ottoh

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