Windows Vistaでは、システムの信頼性と、システムとアプリケーションの問題を診断する能力が、多くの新機能と改善によって向上しています。たとえば、カーネルのWindows Event Tracking（ETW）ロガーは常に実行されており、ファイル、レジストリ、割り込み、およびその他のアクティビティの種類に関するトレースイベントを生成し、それらを循環バッファに保存できます。問題が発生すると、新しいWindows診断インフラストラクチャ（WDI）がバッファスナップショットをキャプチャし、ローカル分析を実行するか、トラブルシューティングのためにマイクロソフトサポートにアップロードします。新しいWindowsパフォーマンスと安定性モニターは、システム構成を変更することによって、クラッシュやハングなどのエラーをユーザーが相関させるのに役立ちます。強力なシステム修復ツール（SRT）が、起動不可能なシステムのオフライン回復のために回復コンソールに代わるものです。システムに対するカーネルレベルの変更に依存する3つの側面があります。これらは、記事の以下の側面で注意深く読む必要があります。Kernel Transaction Manager（KTM）、改良されたクラッシュ処理、および以前のバージョン。 1.カーネルトランザクションマネージャソフトウェア開発の最も厄介な側面の1つはエラー状態を扱うことです。特に、高度な操作中に、アプリケーションはファイルシステムまたはレジストリの変更を引き起こす1つ以上のサブタスクを完了します。たとえば、アプリケーションのソフトウェア更新サービスは、いくつかのレジストリ更新を行い、アプリケーションの実行可能ファイルの1つを置き換え、2番目の実行可能ファイルを更新しようとするとアクセスを拒否される可能性があります。サービスがアプリケーションを結果として不整合な状態にしたくない場合は、すべての変更を追跡し、それらを取り消す準備をする必要があります。エラー回復コードをテストすることは困難でしばしばスキップするので、コード内のエラーを回復することは無駄な努力をすることができます。 Windows Vista用に作成されたアプリケーションは、NTFSで新しいトランザクションサポートを使用し、カーネルトランザクションマネージャのレジストリを使用することによって、最小限の労力で自動的なエラー回復を実現できます。アプリケーションがいくつかの関連する変更を加えたい場合は、分散トランザクションコーディネータ（DTC）トランザクションとKTMトランザクションを作成するか、またはKTM処理を直接作成して、ファイルとレジストリキーへの変更をトランザクションに関連付けることができます。すべての変更が成功すると、アプリケーションはトランザクションをコミットして変更が有効になりますが、アプリケーションはトランザクションをロールバックしてから変更を破棄することができます。利点は、他のアプリケーションがトランザクションのコミット後にトランザクションの変更を確認できることです。WindowsVistaおよび次期Windows Server（コードネーム "Longhorn"）でDTCを使用するアプリケーションはMicrosoftのSQL Serverに合格します。 Message Queue Server（MSMQ）と他のデータベースはそれらのトランザクションを調整します。したがって、KTMトランザクションを使用するアプリケーション更新サービスでは、アプリケーションが矛盾した状態になることはありません。これが、Windows Updateとシステムの復元がトランザクションを使用する理由です。トランザクションサポートの中核として、KTMはNTFSやレジストリなどのトランザクションリソースマネージャがアプリケーションによる特定の変更に対する更新を調整することを可能にします。 Windows Vistaでは、NTFSはトランザクションをサポートするためにTxFという拡張子を使用します。レジストリはTxRと呼ばれる同様の拡張子を使用します。ユーザーモードのリソースマネージャーがDTCを使用してマルチユーザーモードのリソースマネージャー間でトランザクションの状態を調整するのと同様に、これらのカーネルモードのリソースマネージャーはトランザクションの状態をKTMと調整します。第三者もKTMを使用して独自のリソースマネージャを実装できます。 TxFとTxRの両方とも、ファイルシステムとレジストリAPIの新しいセットを定義します（トランザクションパラメータを含むことを除いて、既存のものと同様です）。アプリケーションがトランザクションでファイルを作成したい場合は、最初にKTMを使用してトランザクションを作成してから、その結果のトランザクションを新しいファイル作成APIに渡します。 TxFとTxRはどちらも、Windows Server 2003 R2で導入された共通のジャーナリングファイルシステム、またはCLFSの高速ファイルシステムログ機能（％SystemRoot％\\ System32 \\ Clfs.sys）に依存しています。 TxRとTxFはCLFSを使用して、トランザクションをコミットする前にトランザクション状態の変更を永続的に保存します。これにより、彼らはトランザクション回復を提供し、停電の場合でも回復を確実にすることができます。 CLFSログに加えて、TxRは（図1に示すように）％Systemroot％\\ System32 \\ Config \\ Txr内のシステムレジストリファイルへのトランザクションの変更を追跡する一連の関連ログファイルと各ユーザーレジストリを作成します。本機は複数のログファイルを別々に作成します。 TxFは各ボリュームのトランザクションデータを\\ $ Extend \\ $ RmMetadataという名前のボリュームの隠しディレクトリに格納します。 2.クラッシュサポートの強化（デバイスドライバのエラー、ハードウェアの障害、またはオペレーティングシステムの問題による）回復不能なカーネルモードエラーが発生すると、「ブルースクリーンの死」現象が発生し、物理メモリの一部または全部が存在します。クラッシュダンプファイルに書き込んだ後（これを行うように設定されている場合）、ディスクデータの破損を防ぐためにシステムを終了しようとします。システムクラッシュの後に再起動すると、Microsoftオンラインクラッシュ分析（OCA）サービスがこれらのファイルを分析して根本的な原因を見つけるため、ダンプファイルは便利です。ご希望の場合は、Windows用のMicrosoftデバッグツールを使用して自分で分析することもできます。ただし、Windowsの以前のバージョンでは、クラッシュダンプファイルのサポートは、セッションマネージャ（％Systemroot％\\ System32 \\ Smss.exe）プロセスがページングファイルを初期化した後にのみ有効になりました。これは、これより前に重大なエラーが発生するとブルースクリーンが表示されることを意味します。 Smss.exeが起動する前に多数のデバイスドライバの初期化が行われるため、初期クラッシュによってクラッシュダンプが発生することはなく、原因の診断が非常に困難になります。 Windows Vistaでは、すべてのブートスタートデバイスドライバが初期化された後、システムブートドライバがロードされる前に、ダンプファイルサポートを初期化することによって、ダンプフリーファイル生成の時間枠を短縮します。この変更により、起動プロセスの開始時にクラッシュが発生した場合、システムはクラッシュダンプを取得してOCAに問題の解決を支援することができます。さらに、Windows Vistaではデータをダンプファイルに格納するために64KBブロックを使用していましたが、以前のバージョンのWindowsではファイルの書き込みに4KBブロックを使用していました。この変更により、大きなダンプファイルへの最大10倍の高速書き込みが可能になります。 Windows Vistaでは、アプリケーションのクラッシュ処理も改善されています。以前のバージョンのWindowsでは、アプリケーションがクラッシュしたときに、未処理の例外ハンドラを実行していました。ハンドラーは、Microsoft Application Error Reporting（AER）プロセス（％Systemroot％\\ System32 \\ Dwwin.exe）を開始し、プログラムがクラッシュしたことを示すダイアログボックスを表示して、エラー報告をMicrosoftに送信するかどうかを尋ねます。ただし、クラッシュ時にプロセスのメインスレッドのスタックが破損した場合、未処理の例外ハンドラが実行時にクラッシュし、カーネルはプロセスを終了し、プログラムウィンドウはすぐに消え、エラー報告ウィンドウは表示されません。 Windows Vistaでは、エラー処理をクラッシュプロセスのコンテキストから新しいサービスであるWindows Error Reporting（WER）に移しました。このサービスは、サービスホスティングプロセスのDLL（％Systemroot％\\ System32 \\ Wersvc.dll）によって実装されています。アプリケーションがクラッシュしても、未処理の例外ハンドラが実行されますが、ハンドラはWERサービスにメッセージを送信し、サービスはWERエラー報告プロセス（％Systemroot％\\ System32 \\ Werfault.exe）を開始してエラーを表示します。レポートダイアログスタックが破損し、未処理の例外ハンドラがクラッシュした場合、ハンドラは再度実行されて再度クラッシュし、最終的には（スレッドをメモリ領域を使用して）すべてのスレッドのスタックを消費します。