次の方法で共有

  • [アーティクル]

Windows の管理

Windows Vista カーネルの内部 : 第 2 部

Mark Russinovich

 

概要:

  • メモリ管理
  • 起動とシャットダウン
  • 電源管理

先月、この 3 部シリーズの初回の記事では、プロセスと I/O の領域における Windows Vista カーネルの機能拡張を紹介しました。

今回は、Windows Vista のメモリ管理において進歩した点の他に、システムの起動、シャットダウン、および電源管理の主な改善点について説明します (第 1 部)。

Windows® のどのリリースでもスケーラビリティとパフォーマンスが向上していますが、もちろんこれは Windows Vista™ にも当てはまります。Windows Vista のメモリ マネージャでは、ロックフリー同期テクノロジの広範囲に及ぶ使用、細かい単位でのロック、強化されたデータ構造のパッキング、大容量のページング I/O、最新の GPU メモリ アーキテクチャのサポート、ハードウェア変換ルック アサイド バッファの効率的な使用などの数多くの機能が強化されています。さらに、Windows Vista のメモリ管理では、さまざまな負荷の要求に応じて動的にアドレス スペースを割り当てることができます。

新しいテクノロジを採用した 4 つのパフォーマンス向上機能 SuperFetch、ReadyBoost、ReadyBoot、ReadyDrive が、Windows Vista オペレーティング システムで初めて登場しました。これらの機能については後述します。

動的なカーネル アドレス スペース

Windows と Windows 上で実行されるアプリケーションは、32 ビット プロセッサのアドレス スペース制限に制約されてきました。Windows カーネルは、既定で 2 GB、つまり 32 ビット仮想アドレス スペースの半分に制限されており、残りの半分は、現在 CPU でスレッドが実行しているプロセス用に予約されています。その半分のスペースで、カーネルは、カーネル自体、デバイス ドライバ、ファイル システム キャッシュ、カーネル スタック、セッション単位のコード データ構造、およびデバイス ドライバによって割り当てられた非ページ バッファ (ロック済み物理メモリ) とページ バッファをマップする必要があります。Windows Vista までは、こうしたさまざまな目的に割り当てるアドレス スペースの量をメモリ マネージャが起動時に決定していましたが、柔軟性が低いために、他の領域に使用可能なスペースが大量にあっても 1 つの領域だけがいっぱいになる場合がありました。領域を使い切ると、アプリケーションに障害が発生し、デバイス ドライバの I/O 操作が完了しなくなるおそれがあります。

32 ビットの Windows Vista では、メモリ マネージャが、カーネルのアドレス スペースを動的に管理し、負荷に応じてさまざまな用途にスペースの割り当てや割り当ての解除を行います。こうして、ページ バッファの保存に使用される仮想メモリ容量は、デバイス ドライバからさらに要求されると大きくなり、ドライバがメモリを解放すると小さくなります。したがって、Windows Vista では幅広い負荷に対応できますが、32 ビット バージョンの次期 Windows Server® (コードネーム "Longhorn") でも同様に、より多くのターミナル サーバー ユーザーを同時に処理することができます。

もちろん、64 ビット Windows Vista システムでは、アドレス スペースの制限は今や現実的な制限でなくなっているので、システムが最大限に構成されているときでも特別な処理は必要ありません。

メモリの優先順位

Windows Vista には、前回の記事で説明した I/O 優先順位が追加されているだけでなく、メモリの優先順位も実装されています。Windows でメモリの優先順位がどのように使用されるかを理解するには、メモリ マネージャがスタンバイ リストと呼ばれるメモリ キャッシュをどのように実装しているかを把握する必要があります。Windows Vista より前の Windows のすべてのバージョンでは、プロセスが所有する物理ページ (一般にサイズが 4 KB) はシステムによって再利用され、メモリ マネージャは、そのページをスタンバイ リストの末尾に配置していました。プロセスが再びそのページへのアクセスを要求した場合、メモリ マネージャは、スタンバイ リストからページを取り出して、それをプロセスにもう一度割り当てていました。また、プロセスが物理メモリの新しいページを要求したときに使用可能な空きメモリがなかった場合、メモリ マネージャは、スタンバイ リストの先頭のページをプロセスに使用させていました。この方式では、スタンバイ状態のすべてのページは基本的に同等に扱われ、スタンバイ リストに配置してページを並べ替えるのに時間がかかっていました。

Windows Vista では、メモリの全ページが 0 ～ 7 の優先順位を持つので、メモリ マネージャは、スタンバイ リストを 8 つのリストに分割します。各リストには、特定の優先順位のページが格納されます。メモリ マネージャがスタンバイ リストからページを取り出す場合は、優先順位の低いリストから先にページを取り出します。通常、ページの優先順位には、最初に割り当てを行ったスレッドの優先順位が反映されます (ページが共有されている場合は、共有スレッドのうち最高のメモリの優先順位が反映されます)。スレッドは、そのスレッドが属するプロセスからページ優先順位の値を継承します。メモリ マネージャは、プロセスのメモリ アクセスを予想したときにディスクから推測で読み取るページには、低い優先順位を使用します。

既定では、プロセスのページ優先順位の値は 5 ですが、各種の関数を使用すると、アプリケーションやシステムでプロセスおよびスレッドのページ優先順位の値を変更できます。メモリの優先順位の本当の力は、ページの相対的な優先順位がマクロレベルで理解されるときにのみ発揮されます。そこで SuperFetch の出番です。

SuperFetch

メモリ マネージャで大きく変更されたのは、物理メモリの管理方法です。Windows の前のバージョンで採用されていたスタンバイ リスト管理には、2 つの制限があります。まず、ページの優先順位付けは、プロセスの最近の動作だけに依存し、プロセスの今後のメモリ要求を予測しません。2 つ目に、優先順位付けに使用されるデータは、任意の時点でプロセスが所有するページのリストに限られます。こうした欠点のせいで、"アフター ランチ症候群"、つまり、しばらくの間コンピュータから離れると、メモリを大量に使用するシステム アプリケーション (ウイルス対策スキャンやディスクの最適化など) が実行されている、ということになる場合があります。このようなアプリケーションは、ユーザーが使用していたアプリケーションでメモリにキャッシュしたコードやデータを、メモリを大量に使用する動作で強制的に上書きしてしまいます。ユーザーが戻ると、元のアプリケーションのデータやコードをディスクから呼び出す必要があるので、動作が遅くなっていることがわかります。

Windows XP では、プリフェッチ (前取り出し) をサポートするようになりました。このため、大量のディスク I/O を実行して前回のブートやアプリケーションの起動に基づいて予想されるコードやファイル システム データをメモリにプリロードすることによってブートおよびアプリケーション起動のパフォーマンスが向上しています。Windows Vista は、SuperFetch (履歴情報と事前対応型のメモリ管理により、"最も長い時間アクセスされていない" ものを重視するメモリ管理方式) でさらに高度になっています。

SuperFetch は、サービス ホスト プロセス (%SystemRoot%\System32\Svchost.exe) 内で実行される Windows サービスとして %SystemRoot%\System32\Sysmain.dll 内に実装されています。この方式では、メモリ マネージャのサポートを利用します。その結果、ページ使用状況履歴を取得したり、データやコードをディスク上のファイルまたはページング ファイルからスタンバイ リストにプリロードして、ページに優先順位を割り当てるようメモリ マネージャに指示することができます。SuperFetch サービスでは、基本的にページ追跡の範囲を、一度メモリ内に存在したデータやコードで、しかもメモリ マネージャが新しいデータやコードのスペースを確保するために再利用したデータやコードにまで拡大しています。また、この情報をアプリケーションの起動の最適化に使用される標準のプリフェッチ ファイルと共に、%SystemRoot%\Prefetch ディレクトリに拡張子が .db のシナリオ ファイルとして保存します。メモリの使用状況に関するこの詳しい情報を活かして、SuperFetch では、物理メモリが使用可能になったときにデータやコードをプリロードできます。

メモリが解放されるとき (たとえば、アプリケーションが終了するか、メモリを解放するとき) には必ず、SuperFetch からの依頼でメモリ マネージャが最近追い出されたデータやコードを取得します。この処理は、ユーザーや他のアクティブなアプリケーションがプリロードの影響を受けないように、最低優先順位の I/O によって毎秒数ページの割合で行われます。したがって、ユーザーがコンピュータから離れて食事に行き、その間に、実行していたアプリケーションのコードやデータが、メモリを大量に使用するバックグラウンド タスクによってメモリから追い出されても、多くの場合、SuperFetch でユーザーが戻る前にそうしたコードやデータのすべてまたは大部分をメモリに戻すことができます。SuperFetch では、休止状態、スタンバイ、ユーザーの簡易切り替え (FUS)、およびアプリケーションの起動のためといった特定のシナリオもサポートしています。たとえば、システムが休止状態になると、SuperFetch は、後で再開したときに前回の休止状態に基づいてアクセスが予想されるデータやコードを休止状態ファイルに保存します。対照的に、Windows XP を再開する場合、以前にキャッシュされたデータは参照時にもう一度ディスクから読み取る必要があります。

SuperFetch が使用可能なメモリにどのように影響するかを把握するには、補足記事の「SuperFetch の詳細」を参照してください。

SuperFetch の詳細

Windows Vista システムをしばらく使用した後でも、タスク マネージャの [パフォーマンス] ページにある物理メモリの空き領域カウンタの数値が低いことがわかります。この理由は、SuperFetch と標準の Windows のキャッシュで、使用可能なすべての物理メモリを利用してディスク データをキャッシュするためです。たとえば、初めて起動したときにすぐにタスク マネージャを実行すると、キャッシュ メモリの数値が大きくなるにつれて空きメモリの値が小さくなることに気付きます。または、メモリを大量に必要とするプログラム (大量のメモリを割り当てた後にメモリを解放する "RAM オプティマイザ" のフリーウェアなど) を実行して終了するか、単に非常に大きいファイルをコピーすると、空きメモリの数値が大きくなり、物理メモリ使用量のグラフは、割り当てが解除されたメモリをシステムが再利用するにつれて下降します。ただし、時間の経過と共に、強制的にメモリ外に追い出されたデータがもう一度キャッシュに読み込まれるので、キャッシュされたメモリの数値が大きくなり、空きメモリの数値は小さくなります。

Watching memory

Watching memory(画像を拡大するには、ここをクリックします)

ReadyBoost

CPU とメモリの速度はハード ディスクの速度を大幅に上回っているので、ディスクはシステム パフォーマンスの一般的なボトルネックです。ランダムなディスク I/O が特に不経済な理由は、ディスク ヘッドのシーク時間の約 10 ミリ秒が、現在の 3 GHz プロセッサにとっては無限に長い時間となっているためです。RAM はディスク データをキャッシュするのに理想的ですが、比較的高価です。ただし、フラッシュ メモリは一般により安価で、一般的なハード ディスクよりも最大 10 倍を超える速さでランダムに読み取ることができます。したがって、Windows Vista には、フラッシュ メモリ ストレージ デバイスを利用する ReadyBoost という機能が用意されています。このデバイス上には、メモリとディスクの間に論理的に介在する中間キャッシュ層が作成されます。

ReadyBoost は、サービス ホスト プロセス内で実行される、%SystemRoot%\System32\Emdmgmt.dll に実装されたサービス、およびボリューム フィルタ ドライバ %SystemRoot%\System32\Drivers\Ecache.sys から構成されます (Emd は、開発時の ReadyBoost の旧称である External Memory Device (外部メモリ デバイス) の略です)。USB キーのようなフラッシュ デバイスをシステムに挿入すると、ReadyBoost サービスは、そのデバイスを調べてパフォーマンス特性を判別し、テスト結果を HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt に保存します (図 1 参照)。

Figure 1 ReadyBoost device test results in the registry

Figure 1** ReadyBoost device test results in the registry **(画像を拡大するには、ここをクリックします)

キャッシュ用のデバイスをまだ使用しておらず、新しいデバイスのサイズが 256 MB ～ 32 GB、4 KB のランダム読み取りの転送速度が 2.5 MB/s 以上、512 KB のランダム書き込みの転送速度が 1.75 MB/s 以上の場合、最大 4 GB のディスク キャッシュ専用ストレージにするかどうかをたずねるメッセージが表示されます (ReadyBoost は NTFS を使用できますが、FAT32 の制限に対応するために最大キャッシュ サイズが 4 GB に制限されています)。同意すると、ReadyBoost がデバイスのルートに ReadyBoost.sfcache という名前のキャッシュ ファイルを作成し、バックグラウンドで事前にキャッシュに読み込むよう SuperFetch に依頼します。

ReadyBoost サービスがキャッシュを初期化したら、Ecache.sys デバイス ドライバがローカル ハード ディスク ボリューム (C:\ など) に対するすべての読み取りと書き込みをインターセプトし、作成されたキャッシュ ファイルに書き込まれるすべてのデータをコピーします。Ecache.sys が、通常 2:1 の圧縮比になるようにデータを圧縮するので、4 GB のキャッシュ ファイルには通常 8 GB のデータが格納されます。このドライバは、ランダムに生成されるブート単位のセッション キーによる Advanced Encryption Standard (AES) 暗号化を利用して、書き込む各ブロックを暗号化します。このため、キャッシュ デバイスをシステムから取り外してもデータのプライバシーが保たれます。

ReadyBoost はキャッシュからランダムに読み取ることができるとわかると、キャッシュから読み取りますが、順次読み取りアクセスはハード ディスクの方がフラッシュ メモリより優れているため、順次アクセスの読み取りパターンの場合は、データがキャッシュにあっても直接ディスクにアクセスするようにします。

ReadyBoot

Windows Vista では、メモリが 512 MB 未満のシステムの場合 Windows XP と同じ起動時のプリフェッチを使用しますが、システムに 700 MB 以上のメモリが搭載されている場合は、RAM 内のキャッシュを利用してブート プロセスを最適化します。キャッシュのサイズは、使用可能な RAM の合計によって異なりますが、適度なキャッシュを作成可能であり、かつシステムのスムーズな起動に必要なメモリを確保できる大きさとなります。

毎回ブート後に、ReadyBoost サービス (説明したばかりの ReadyBoost 機能を実装する同じサービス) では、CPU の空き時間を利用して、次回のブートに備えて起動時のキャッシュ計画を計算します。また、直前の 5 回のブートにおけるファイル トレース情報を分析して、アクセスされたファイルとそのディスク上の格納場所を特定します。さらに、処理されたトレースを %SystemRoot%\Prefetch\Readyboot に .fx ファイルとして格納し、HKLM\System\CurrentControlSet\Services\Ecache\Parameters の、.fx ファイルが参照する内部のディスク ボリュームの名前が付いた REG_BINARY 値にキャッシュ計画を保存します。

キャッシュは、ReadyBoost キャッシュ (Ecache.sys) を実装する同じデバイス ドライバによって実装されますが、キャッシュの生成は、システム起動時に ReadyBoost サービスによって行われます。ブート キャッシュは ReadyBoost キャッシュと同様に圧縮されますが、ReadyBoost と ReadyBoot のキャッシュ管理におけるもう 1 つの違いは、ReadyBoot モードでは ReadyBoost サービスの更新以外にキャッシュが変更されることはなく、起動中に読み取り/書き込みが行われたデータは反映されない点です。ReadyBoost サービスは、ブート開始 90 秒後にキャッシュを削除するか、他のメモリの要求のためにキャッシュが必要な場合は、キャッシュの統計情報を HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats に記録します (図 2 参照)。マイクロソフトのパフォーマンス テストでは、ReadyBoot のパフォーマンスは従来の Windows XP プリフェッチャを約 20 パーセント上回っていることが示されています。

Figure 2 ReadyBoot Performance statistics

Figure 2** ReadyBoot Performance statistics **(画像を拡大するには、ここをクリックします)

ReadyDrive

ReadyDrive は、H-HDD という新しいハイブリッド ハード ディスク ドライブを利用する、Windows Vista の機能です。H-HDD とは、不揮発フラッシュ メモリ (別名 NVRAM) が組み込まれたディスクのことです。一般的な H-HDD には、50 MB ～ 512 MB のキャッシュが搭載されていますが、Windows Vista のキャッシュ上限は 2 TB です。

Windows Vista では、ATA-8 コマンドを使用して、フラッシュ メモリに保持されるディスク データを定義します。たとえば、Windows Vista では、システムのシャットダウン時に、迅速に再起動できるようにブート データがキャッシュに保存されます。システムが休止状態になるときは、その後で迅速に再開できるように、休止状態ファイル データの一部もキャッシュに保存されます。ディスクが停止していてもキャッシュは有効になっているので、Windows では、システムがバッテリ電源で動作しているときにディスクが回転しないようにするために、フラッシュ メモリをディスク書込みキャッシュとして使用できます。ディスクのスピンドルを停止したままにすると、通常の使用状態でディスク ドライブに消費される電力よりも大幅に節約できます。

ブート構成データベース

Windows Vista では、起動とシャットダウンのいくつかの点が強化されました。起動は、システムと OS の起動構成を保存するためのブート構成データベース (BCD)、システム起動プロセスの新しいフローと構成、新しいログオン アーキテクチャ、および遅延自動起動サービスのサポートの導入によって改善されました。Windows Vista のシャットダウンに関する変更点には、Windows サービスのプレシャットダウン通知、Windows サービス シャットダウンの順序設定、および OS が電源の状態遷移を管理する方法の大幅な変更があります。

起動プロセスに対する最も目立つ変更点の 1 つは、システム ボリュームのルートから Boot.ini がなくなったことです。これは、Windows の旧バージョンでは Boot.ini テキスト ファイルに保存されていたブート構成が、Vista では BCD に保存されるためです。Windows Vista が BCD を使用する理由の 1 つは、現在 Windows でサポートされている 2 つのブート アーキテクチャ、つまり、マスタ ブート レコード (MBR) と拡張ファームウェア インターフェイス (EFI) を統合するためです。MBR は、一般に x86 と x64 デスクトップ システムで使用されていますが、EFI は Itanium ベースのシステムで使用されています (ただし、近い将来デスクトップ パソコンには EFI サポートが付属するようになりそうです)。BCD によりファームウェアが抽象化されることに加え、他にも Unicode 文字列や代替プレブート実行可能ファイルのサポートなど、Boot.ini を上回る利点を備えています。

BCD は、実際にはレジストリ API を介したアクセスによって Windows レジストリに読み込まれる、ディスク上のレジストリ ハイブに格納されます。パソコン上では、BCD は Windows によりシステム ボリュームの \Boot\Bcd に格納されます。EFI システムでは、BCD は EFI システム パーティションにあります。このハイブが読み込まれると HKLM\Bcd00000000 の下に設定されますが、その内部形式は公開されていないので、その値を編集するには、%SystemRoot%\System32\Bcdedit.exe のようなツールを使用する必要があります。BCD を操作するためのインターフェイスは、Windows Management Instrumentation (WMI) を介してスクリプトやカスタム エディタからも利用できますし、Windows システム構成ユーティリティ (%SystemRoot%\System32\Msconfig.exe) を使用して、カーネル デバッグ オプションのような基本パラメータを編集したり追加することができます。

BCD では、OS ブート オプションや OS ブート ローダーへのパスのような OS 固有の設定から、既定の OS の選択やブート メニュー タイムアウトのようなプラットフォーム全体にわたるブート設定を分離しています。たとえば、図 3 は、コマンド ライン オプションを指定せずに Bcdedit を実行すると、一番上の Windows ブート マネージャ セクションにプラットフォーム設定が表示され、続いて Windows ブート ローダー セクションに OS 固有の設定が表示されることを示しています。

Figure 3 Settings displayed in BCDEdit

Figure 3** Settings displayed in BCDEdit **(画像を拡大するには、ここをクリックします)

Windows Vista インストールを起動すると、この新しい方式では、Windows の旧バージョンのオペレーティング システム ローダー (Ntldr) で処理されていたタスクが \BootMgr および %SystemRoot%\System32\Winload.exe という 2 種類の実行可能ファイルに分割されます。Bootmgr は BCD を読み取って OS ブート メニューを表示し、Winload.exe はオペレーティング システムの読み込みを処理します。クリーン ブートを実行している場合、Winload.exe はブート開始デバイス ドライバとコア オペレーティング システム ファイル (Ntoskrnl.exe など) を読み込み、オペレーティング システムに制御を渡します。システムが休止状態から再開している場合は、%SystemRoot%\System32\Winresume.exe を実行して、休止状態データをメモリに読み込み、OS を再開します。

Bootmgr では、プレブート実行可能ファイルの追加もサポートしています。Windows Vista には、RAM の状態を確認するためのオプションとして構成済みの Windows メモリ診断ツール (\Boot\Memtest.exe) が付属していますが、サードパーティが、Bootmgr のブート メニューに表示されるオプションとして独自のプレブート実行可能ファイルを追加できます。

起動プロセス

Windows の旧バージョンでは、各種システム プロセス間の関係がわかりやすくありませんでした。たとえば、システムの起動時に、対話型ログオン マネージャ (%SystemRoot%\System32\Winlogon.exe) はローカル セキュリティ機関サブシステム サービス (Lsass.exe) とサービス コントロール マネージャ (Services.exe) を起動します。さらに、Windows では、セッションという名前空間コンテナを使用して、さまざまなログオン セッションで実行しているプロセスを分離します。しかし、Windows Vista より前では、コンソールにログオンするユーザーは、システム プロセスで使用されるセッションであるセッション 0 を共用していたため、セキュリティの問題が生じるおそれがありました。そのような問題が生じるのは、たとえば、セッション 0 で実行する品質の悪い Windows サービスが対話型コンソールにユーザー インターフェイスを表示する場合です。このとき、マルウェアはシャッター攻撃のような技術でウィンドウを攻撃して管理者特権を獲得できます。

こうした問題に対処するために、Windows Vista のいくつかのシステム プロセスはアーキテクチャが変更されました。セッション マネージャ (Smss.exe) は、Windows の旧バージョンのように起動時に作成される最初のユーザー モード プロセスですが、Windows Vista では、セッション マネージャは、それ自体の 2 つ目のインスタンスを起動してシステム プロセス専用のセッション 0 を構成します。セッション 0 用のセッション マネージャ プロセスは、Windows スタートアップ アプリケーション (Wininit.exe) と、セッション 0 用の Windows サブシステム プロセス (Csrss.exe) を起動した後、終了します。Windows スタートアップ アプリケーションは、サービス コントロール マネージャ、ローカルセキュリティ権限サブシステム、およびコンピュータのターミナル サーバー接続を管理する新しいプロセスであるローカル セッション マネージャ (Lsm.exe) を起動して続行します。

ユーザーがシステムにログオンすると、最初のセッション マネージャが、それ自体の新しいインスタンスを作成して新しいセッションを構成します。新しい Smss.exe プロセスは、新たなセッション用の Windows サブシステム プロセスと Winlogon プロセスを起動します。第 1 のセッション マネージャ自体のコピーを使用して新しいセッションを初期化しても、クライアント システムには何のメリットもありません。しかし、ターミナル サーバーとして動作する Windows Server "Longhorn" システムでは、複数のコピーが同時に実行して複数のユーザーが迅速にログオンできます。

この新しいアーキテクチャでは、Windows サービスなどのシステム プロセスは、セッション 0 に分離されます。セッション 0 で実行する Windows サービスがユーザー インターフェイスを表示すると、対話型サービス検出サービス (%SystemRoot%\System32\UI0Detect.exe) は、それ自体のインスタンスをユーザーのセキュリティ コンテキストで起動し、図 4 に示すメッセージを表示して、ログオンしているすべての管理者に通知します。ユーザーが [メッセージを表示する] ボタンをクリックすると、デスクトップが Windows サービス デスクトップに切り替わるので、ユーザーはそのサービスのユーザー インターフェイスとやりとりした後、元のデスクトップに戻ることができます。起動時の処理の詳細については、補足記事の「起動プロセスの関係の表示」を参照してください。

Figure 4 Service has displayed a window

Figure 4** Service has displayed a window **(画像を拡大するには、ここをクリックします)

起動プロセスの関係の表示

Sysinternals (microsoft.com/technet/sysinternals) (英語) の Process Explorer を使用すると、Windows Vista のプロセス起動ツリーを確認できます。

スクリーンショットには、セッション列が含まれていますが、この列は、Process Explorer の列ダイアログ ボックスを介して追加できます。強調表示されているプロセスは、最初の Smss.exe です。その下にセッション 0 の Csrss.exe と Wininit.exe があります。これらが左揃えになっているのは、その親プロセス (セッション 0 を構成した Smss.exe のインスタンス) が終了したためです。Wininit には、Services.exe、Lsass.exe、および Lsm.exe という 3 つの子があります。

セッション 1 (リモート デスクトップ接続を介して私がログインしているセッション) で実行しているプロセスが識別されています。また、Process Explorer は、それ自体と同じアカウントで実行しているプロセスを青の強調色で表示しています。最後に、コンソールにログインしているユーザーのために、セッション 2 が初期化され、新たなログオン セッションを作成できるようにしています。そのセッションでは、Winlogon が実行中であり、LogonUI を使用して新しいコンソール ユーザーに "ログオンするには Ctrl + Alt + Del を押してください。" という操作を要求しています。また、Logonui.exe がユーザーの資格情報の入力を求めています。

Startup process and session information

Startup process and session information(画像を拡大するには、ここをクリックします)

資格情報プロバイダ

Windows Vista ではログオン アーキテクチャも変更されています。Windows の旧バージョンでは、Winlogon プロセスが、レジストリで指定された GINA (Graphical Identification and Authentication) DLL を読み込み、ユーザーに資格情報の入力を求めるログオン UI を表示します。残念ながら、GINA モデルでは、GINA は 1 つしか構成できないこと、サードパーティが完全な GINA を作成するのは困難であること、および非標準のユーザー インターフェイスを持つ独自の GINA では Windows ユーザー エクスペリエンスが変わってしまうことなどの制限があります。

Windows Vista では、GINA に代わる新しい資格情報プロバイダ アーキテクチャを採用しています。Winlogon は、ログオン ユーザー インターフェイス ホスト (Logonui.exe) という別のプロセスを起動します。このプロセスは、HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers に構成されている資格情報プロバイダを読み込みます。Logonui は、複数の資格情報プロバイダを同時にホストすることができます。ちなみに、Windows Vista には対話型プロバイダ (Authui.dll) とスマートカード プロバイダ (Smart-cardcredentialprovider.dll) が付属しています。ユーザー エクスペリエンスを統一するために、LogonUI はエンド ユーザーに表示されるユーザー インターフェイスを管理しますが、LogonUI を使用することにより、資格情報プロバイダがテキスト、アイコン、編集コントロールのようなカスタム要素を指定することもできます。

遅延自動起動サービス

Windows システムの起動直後に Windows システムにログオンしたことがある方なら、デスクトップが完全に構成され、シェルやアプリケーションとやりとりができるようになるまでに時間がかかるのを経験したことがあると思います。ログオン中には、サービス コントロール マネージャが、起動時にアクティブにする自動起動サービスとして構成された多くの Windows サービスを開始しています。多くのサービスでは、ユーザーのログオン操作と競合する、CPU やディスクを大量に使用する初期化を実行します。これに対応するために、Windows Vista では、遅延自動起動という新たな種類のサービス開始機能が導入されています。この機能は、サービスが Windows の起動直後にアクティブでなくてもよい場合に使用されます。

サービス コントロール マネージャは、自動開始サービスによるサービスの開始が完了した後に遅延自動起動として構成されたサービスを開始し、THREAD_PRIORITY_LOWEST にそれぞれの最初のスレッドの優先順位を設定します。この優先順位レベルにより、スレッドが実行するすべてのディスク I/O が最低の I/O 優先順位になります。サービスが初期化を完了したら、サービス コントロール マネージャがその優先順位を標準の値に設定します。遅延起動の組み合わせ、CPU とメモリの低優先順位、およびバックグラウンドのディスク優先順位のおかげで、ユーザーのログオンが邪魔されにくくなります。Background Intelligent Transfer、Windows Update クライアント、Windows Media® Center をはじめとする、数多くの Windows サービスでは、この新たな種類のサービス開始機能を使用すると、ブート後のログオンのパフォーマンスを向上できるようになります。

シャットダウン

Windows サービスの開発者を悩ませる問題は、Windows のシャットダウン時のクリーンアップの実行に、既定で最大 20 秒しかないことです。Windows Vista より前のバージョンの Windows では、バグの多いサービスのせいでシャットダウンが無期限に停滞する場合があるため、すべてのサービスの終了を待つクリーン シャットダウンをサポートしていませんでした。ネットワーク関連のシャットダウン操作を必要とするサービスや大量のデータをディスクに保存するサービスのような一部のサービスは、より多くの時間がかかる可能性があるので、Windows Vista では、サービスがプレシャットダウン通知を要求できます。

Windows Vista がシャットダウンする場合は、最初にサービス コントロール マネージャが、プレシャットダウン通知を要求しているそれぞれのサービスに通知します。次に、こうしたサービスが終了するのを無期限に待ちますが、サービスにバグがあるために問い合わせに応じない場合、サービス コントロール マネージャは 3 分後に待つのをやめて先に進みます。そうしたサービスがすべて終了するか、タイムアウト期間が経過したら、サービス コントロール マネージャは、従来のスタイルのサービスについて、残りのサービスのシャットダウンを続行します。グループ ポリシーと Windows Update サービスは、Windows Vista の新規インストールの際にプレシャットダウン通知を登録します。

グループ ポリシーと Windows Update サービスでは、もう 1 つの Windows Vista サービス機能であるシャットダウンの順序設定も使用します。開始時のサービスの依存関係は、これまでも指定可能でした。つまり、サービス コントロール マネージャが、そうした依存関係を満たす順序でサービスを開始するように対応していました。しかし、Windows Vista まで、シャットダウン時のサービスの依存関係は指定することができませんでした。プレシャットダウン通知に備えて登録を実行するサービスでは、それ自体を、HKLM\System\CurrentControlSet\Control\PreshutdownOrder に格納されているリストに挿入することもできるようになったので、サービス コントロール マネージャはその順序に従ってサービスを停止します。こうしたサービスの詳細については、補足記事の「遅延自動起動とプレシャットダウン サービスの識別」を参照してください。

電源管理

スリープと休止状態はシャットダウンの別の形ですが、Windows 2000 で Windows NT® ベースの一連の Windows オペレーティング システムに電源管理が導入されて以降、ドライバやアプリケーションのバグだらけの電源管理は、外回りの多いビジネスマンにとってわざわいのもとになっていました。多くのユーザーは、出かける前にラップトップ システムのふたを閉じたときにシステムが中断または休止していると思っていましたが、着いた先ではキャリング バッグが熱を帯び、バッテリ切れで、データが失われた状態になるだけでした。これは、Windows では必ずデバイス ドライバやアプリケーションに電源の状態の変更を打診しますが、応答しないドライバやアプリケーションが 1 つでもあると中断や休止ができなくなることがあったためです。

Windows Vista では、カーネルの電源マネージャが、ドライバやアプリケーションが準備できるように、これまでどおり電源の状態の変更をドライバやアプリケーションに通知しますが、許可は求めなくなりました。さらに、電源マネージャは変更通知に対するアプリケーションの応答を、Windows の旧バージョンのように 2 分ではなく、最大 20 秒しか待ちません。その結果、Windows Vista ユーザーは、システムの休止や中断がより確実に行われることを体験できます。

次回のトピック

前述のように、今回は 3 部シリーズの第 2 回目をお届けしました。第 1 部では、Windows Vista カーネルの I/O とプロセスの強化点について説明しました。今回は、Windows Vista のメモリ管理、起動、およびシャットダウンにおける機能拡張について説明しました。次回は、信頼性とセキュリティの領域におけるカーネルの変更点を説明してこのシリーズを締めくくります。

遅延自動起動とプレシャットダウン サービスの識別

組み込みの SC コマンドは、遅延自動起動サービスとして構成されているサービスを表示するように Windows Vista では更新されています。

Using SC to display start type

Using SC to display start type(画像を拡大するには、ここをクリックします)

残念ながら、SC コマンドではプレシャットダウン通知を要求したサービスはレポートされませんが、Sysinternals の PsService ユーティリティを使用すると、サービスがプレシャットダウン通知を受け入れるかどうかを確認できます。

Viewing pre-shutdown status

Viewing pre-shutdown status(画像を拡大するには、ここをクリックします)

Mark Russinovich は、Microsoft の Platform and Services Division に所属するテクニカル フェローです。また、『Microsoft Windows Internals』(英語) (Microsoft Press、2004) の共同執筆者であり、IT カンファレンスや開発者向けカンファレンスで頻繁に講演を行っています。彼は、共同で設立した Winternals Software 社の Microsoft による先ごろの買収に伴い、Microsoft に入社しましたが、Sysinternals の設立者でもあり、同社では Process Explorer、Filemon、および Regmon の各ユーティリティを発表しています。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.