この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "CHKDSK" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL（2024年2月）

CHKDSK（チェックディスク、"check disk"の略語）はMS-DOS、OS/2およびWindowsに付属するシステムユーティリティコマンド。ディスクボリュームのファイルシステム整合性をチェックし、論理ファイルシステムエラーを修復する機能を持つ。UNIXにおけるfsckコマンドに類似する。DOSではメモリの使用状況を出力する機能もあり、MS-DOS 4.0でMEMコマンドが追加されるまで、メモリの使用状況を確認する方法の一つであった。

Windows NT系では、CHKDSKはディスクの表面に不良セクタがあればそれをマークする機能も持っている（MS-DOS 6.xやWindows 9x系では、スキャンディスクがこの機能を持つ）。Windows ServerのCHKDSKは、RAID1またはRAID5構成のディスクで不良セクタが見つかったとき、他のディスクが正常であればそこからデータを完全に修復する機能を持つ[1]。

CHKDSKはDOSプロンプト、Windowsエクスプローラー、Windowsコマンドプロンプトまたは回復コンソールから実行することができる[2]。
概要

Windows NT系では、CHKDSKの標準スキャンにはファイルメタデータのテスト処理に3つのフェーズがある。もしエラーが見つかっても、明示的に修復するよう指定しない限り修復は行われない。表面スキャンでも同様である。このテストは大容量または低性能のディスクでは非常に時間が掛かり、明示的に指定されない限り行われない。CHKDSKは修復操作を行うために、ボリュームへの排他的書き込みアクセスを要求する[3][4]。

排他的書き込みアクセスを要求することに加え、CHKDSKの処理に時間が掛かるため、Windows Vistaではオペレーティングシステムがボリュームのエラーを検出した時にそれを修復するという新しいファイルシステム正常性モデルを実装している。問題が発生して完全スキャンの必要性が生じたとき、アクションセンターがユーザーに都合の良いときにボリュームをオフラインにするように通知する[5]。

Windows VistaおよびWindows Server 2008ではCHKDSKコマンドに加えて自己回復機能が追加されており、標準で有効になっている。これは物理ファイルシステムエラーを検出して暗黙的に修復するものである。このように、多くの問題はCHKDSKの実行で表示されることはなく、それよりも前に発見される。自己回復機能はfsutil repairコマンドで管理できる[6][7]。
関連バイナリ モジュール

コマンドラインからCHKDSK を実行する場合はChkdsk.exeが実行され、Untfs.dll や Ufat.dll などのDLLも使用する。コンピュータの再起動時に実行スケジュールされた場合には、Chkdsk.exeではなくAutochk.exe が実行されて、Chkdsk.exeと同様のDLLを使用するが、仮想メモリや Win32 サービスを使用せず、アプリケーション イベント ログにもイベントが出力される[8]。
CHKDSKで実行される処理

NTFS では、トランザクション ログを使用して（ファイルの実体であるユーザデータではなく、）ボリュームに保存されているすべてのファイルに関する情報を追跡するためのメタデータ（各アロケーション ユニットに於ける未使用、不良セクタの所在などに関する情報）を保持している。CHKDSKがチェック、修復をするのは、これら各アロケーション ユニットとファイルの実体とを紐付けるメタデータの整合性情報である。

ディスクの破損が発生した場合、すぐに CHKDSK の完全な処理を実行しても、NTFS では（MFTとNTFSのメタデータ相互の整合性は取るが）ファイル実体であるユーザー データの整合性は保証されない。CHKDSK では修復できないファイルが存在する場合や、CHKDSK で修復したファイルに内部的な破損が残っている場合がある[8]。

フェーズ 1 : ファイルのチェック

ファイルエントリのチェックを行う。ボリュームのマスター ファイル テーブル (MFT) 内の各ファイル レコード セグメントを検証し、NTFS ボリューム上の各ファイルおよびディレクトリを一意に識別する。各ファイル レコード セグメントの内部的な整合性を検証して、使用中のファイル レコード セグメントを表すビットマップと、ボリューム上の使用中のクラスタを示すビットマップの 2 つのビットマップを作成する。このフェーズの最終段階で、MFT 内とボリューム全体の両方について、使用中の領域と使用可能な領域を識別し、MFTとは別にNTFS では、ディスク上に保存されている独自のビットマップでこれと同様の情報を追跡・保持しているので、その比較差分をの出力情報に表示する。使用中のファイル レコード セグメントに破損が検出された場合、対応するディスク クラスタを使用可能とするか使用中とするか、など。

フェーズ 2 : インデックスのチェック

ディレクトリエントリのチェックを行う。ボリューム上の各ディレクトリのNTFSインデックスに対し、ディレクトリ内で参照されている全てのファイルやサブディレクトリが、MFT 内の有効なファイル レコード セグメントとして実際に存在しているか、ディレクトリの循環参照がないか、ファイル のタイム スタンプとサイズが最新の情報であるかどうかを確認する。正当なファイル レコード セグメントがあるが、どのディレクトリ一覧にも存在しない孤立したファイルを適切と見なされるディレクトリへ復帰させ、適切なディレクトリが既に削除されているなどで見当たらない場合はルート ディレクトリに仮ディレクトリを作成し、そこにファイルを格納する。ディレクトリ一覧に対応するファイル実体がない場合は、そのファイル レコード セグメントに対するディレクトリ エントリの方を削除して整合性を取る。

フェーズ 3 : セキュリティ記述子のチェック

ファイルやディレクトリの所有者、NTFS アクセス許可、監査に関する情報などのセキュリティ記述子の整合性を取る。但し、記載のあるユーザーやグループが実際に存在するかや、付与されているアクセス許可が適切かの検証は行われない。

フェーズ 4 : セクタのチェック

ボリュームの空き領域にある不良セクタのチェックを行う（/R オプションまたは /B オプション）。ボリューム上のすべてのセクタを読み取って、使用可能セクタかを確認し、読み取り不能なセクタを含むクラスタを不良クラスタの一覧に追加する。不良クラスタのデータを修復して、不良クラスタに代わる新しいクラスタにデータを書き込む。もしデータの修復ができない場合は、0xFF バイトのパターンを新しいクラスタに設定する。
欠陥
MS-DOS 5 バグ

MS-DOS 5.0のCHKDSKとUNDELETEにはデータを破壊するバグがある。ディスクのFATで256セクタを使用している環境でCHKDSK /Fを実行するとデータを消失し、UNDELETEを実行すると予測不能な結果を引き起こす。通常、この問題は128MBの倍数の容量を持つディスクで発生する。これは1991年4月9日付のタイムスタンプのCHKDSK.EXEとUNDELETE.EXEに適用される。このバグはMS-DOS 5.0aでは修正されている[9]。
PC DOS J6.3/V USモードのバグ

PC DOS J6.3/Vでは、CHKDSKをUSモード（英語モード）で実行すると日本語文字のディレクトリ下にあるファイルやディレクトリが消去される場合がある。これを回避するため、バージョンJ6.30A/VのCSD（問題修正ディスケット）でUSモード用のCHKDSKUS.COMが追加された[10]。
Windows 7のバグ疑惑

Windows 7の正式リリース前、InfoWorld（英語版）はCHKDSKにメモリリークがあるという疑惑を報告した。この報告によると、chkdsk /rコマンドがメモリを最大まで消費してシステムをクラッシュさせる、とのこと。Infoworldのランドール・C・ケネディ (Randall C. Kennedy) は情報の出所を「様々なWeb情報源」とし、彼のテストでもメモリの消費が90%以上に達したものの、クラッシュまでには至らなかったとした。それにもかかわらず、ケネディはメモリの消費を重大なバグとみなして、Windows 7のリリース計画を狂わせるつもりだったのかマイクロソフトを冷笑的に非難した[11]。

Neowin（英語版）のトム・ウォーレン (Tom Warren) はケネディのメモリリーク疑惑の意見を却下した[12]。マイクロソフトのスティーブン・シノフスキー (Steven Sinofsky) は、マイクロソフトではクラッシュを再現できなかったことに加え、大量のメモリ消費はパフォーマンスを向上するための仕様上の動作でありメモリリークではないと回答した。ZDNetのエド・ボット (Ed Bott) はケネディによるテストでの指摘について、クラッシュは発生しないことを観測したとレビューした。chkdsk /rについて補足すると、設計上、Windowsのオンライン中ではシステムドライブには実行できないようになっている。ボットは「それは恐らくバグではなく機能であって、またこの方法でシステムがクラッシュすることは非常に稀であり完全に回避可能である。」と結論づけた[13]。