CHKDSK
各ファイル レコード セグメントの内部的な整合性を検証して、使用中のファイル レコード セグメントを表すビットマップと、ボリューム上の使用中のクラスタを示すビットマップの 2 つのビットマップを作成する。 このフェーズの最終段階で、MFT 内とボリューム全体の両方について、使用中の領域と使用可能な領域を識別し、MFTとは別にNTFS では、ディスク上に保存されている独自のビットマップでこれと同様の情報を追跡・保持しているので、その比較差分をの出力情報に表示する。 使用中のファイル レコード セグメントに破損が検出された場合、対応するディスク クラスタを使用可能とするか使用中とするか、など。
フェーズ 2 : インデックスのチェック
ディレクトリエントリのチェックを行う。ボリューム上の各ディレクトリのNTFSインデックスに対し、ディレクトリ内で参照されている全てのファイルやサブディレクトリが、MFT 内の有効なファイル レコード セグメントとして実際に存在しているか、ディレクトリの循環参照がないか、ファイル のタイム スタンプとサイズが最新の情報であるかどうかを確認する。
Windows 7の正式リリース前、InfoWorld(英語版)はCHKDSKにメモリリークがあるという疑惑を報告した。この報告によると、chkdsk /rコマンドがメモリを最大まで消費してシステムをクラッシュさせる、とのこと。Infoworldのランドール・C・ケネディ (Randall C. Kennedy) は情報の出所を「様々なWeb情報源」とし、彼のテストでもメモリの消費が90%以上に達したものの、クラッシュまでには至らなかったとした。それにもかかわらず、ケネディはメモリの消費を重大なバグとみなして、Windows 7のリリース計画を狂わせるつもりだったのかマイクロソフトを冷笑的に非難した。
Neowin(英語版)のトム・ウォーレン (Tom Warren) はケネディのメモリリーク疑惑の意見を却下した。マイクロソフトのスティーブン・シノフスキー (Steven Sinofsky) は、マイクロソフトではクラッシュを再現できなかったことに加え、大量のメモリ消費はパフォーマンスを向上するための仕様上の動作でありメモリリークではないと回答した。ZDNetのエド・ボット (Ed Bott) はケネディによるテストでの指摘について、クラッシュは発生しないことを観測したとレビューした。chkdsk /rについて補足すると、設計上、Windowsのオンライン中ではシステムドライブには実行できないようになっている。ボットは「それは恐らくバグではなく機能であって、またこの方法でシステムがクラッシュすることは非常に稀であり完全に回避可能である。」と結論づけた。
正当なファイル レコード セグメントがあるが、どのディレクトリ一覧にも存在しない孤立したファイルを適切と見なされるディレクトリへ復帰させ、適切なディレクトリが既に削除されているなどで見当たらない場合はルート ディレクトリに仮ディレクトリを作成し、そこにファイルを格納する。ディレクトリ一覧に対応するファイル実体がない場合は、そのファイル レコード セグメントに対するディレクトリ エントリの方を削除して整合性を取る。
フェーズ 3 : セキュリティ記述子のチェック
ファイルやディレクトリの所有者、NTFS アクセス許可、監査に関する情報などのセキュリティ記述子の整合性を取る。 但し、記載のあるユーザーやグループが実際に存在するかや、付与されているアクセス許可が適切かの検証は行われない。
フェーズ 4 : セクタのチェック
ボリュームの空き領域にある不良セクタのチェックを行う(/R オプションまたは /B オプション)。ボリューム上のすべてのセクタを読み取って、使用可能セクタかを確認し、読み取り不能なセクタを含むクラスタを不良クラスタの一覧に追加する。不良クラスタのデータを修復して、不良クラスタに代わる新しいクラスタにデータを書き込む。もしデータの修復ができない場合は、0xFF バイトのパターンを新しいクラスタに設定する。