sfc /scannowはWindowsのprotected system fileを検査・修復するtoolで、disk故障、third-party app、user document、driver全般を直す万能commandではありません。Microsoftの現行案内では、online Windowsのcomponent sourceをDISMで修復してからSFCを実行します。
結論は「管理者Command PromptでDISM /RestoreHealthを完了させ、その後sfc /scannowを100%まで待ちます。最終messageを分類し、必要ならCBS.logからSFC行だけを抽出します」です。
SFCが対象にするsystem fileを理解する
SFCの主なoptionは/scannow、/verifyonly、/scanfile、/verifyfile、offline修復用の/offbootdirと/offwindir等です。通常の起動中Windowsでは/scannowを使います。offline optionはdrive letterがrecovery environmentで変わるため、適用先を誤ると意味のないscanになります。
- 症状と発生時刻、Windows build、pending update
- 管理者権限のCommand Promptか
- DISM RestoreHealthが成功したか
- system driveのfree spaceとstorage error
- SFCの最終messageとCBS.logのtimestamp
SFCを実行する前にReliability Monitor、Event Viewer、Windows Update履歴を取得します。hardware errorやdisk I/O errorがある場合はrepairを繰り返さずstorage healthを優先します。SFC終了後はconsoleの最後の一行だけでなく開始・終了時刻とexit contextを記録します。
SFCを実行する前に、Windows build、症状、直前の更新、Application/Systemログ、空き容量を記録します。アプリ一つの設定不良やハードディスク故障をSFCだけで直せるとは限りません。sfc /verifyonlyは保護システムファイルを検査し修復しないため、まず状態把握に使えます。Windowsが起動しない場合はオフラインWindowsのドライブ文字がWinREで変わる点を確認します。
DISMからSFCへ進む標準順序
管理者Command PromptでDISM.exe /Online /Cleanup-Image /RestoreHealthを実行し、完了後にsfc /scannowを行います。100%になるまでwindowを閉じません。「could not perform requested operation」ならSafe Mode等のMicrosoft案内を確認し、原因なしに何度も再実行しません。
component sourceを修復
DISM.exe /Online /Cleanup-Image /RestoreHealthWindows Updateをsourceとして利用する場合があり、network/source errorを記録します。
protected fileをscan・修復
sfc /scannow管理者Command Promptで実行し、verification 100%まで待ちます。
変更せずverifyのみ
sfc /verifyonlyintegrity violationの有無だけを調べ、修復は行いません。
特定fileをscan
sfc /scanfile=C:\Windows\System32\kernel32.dll対象pathを公式helpで確認し、random DLLをinternetから置換しません。
SFC記録を抽出
findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log > "%USERPROFILE%\Desktop\sfcdetails.txt"CBS.log全体でなくSFC関連行をcopyし、user pathを含む共有fileをreviewします。
オンラインWindowsでは管理者端末でDISM /Online /Cleanup-Image /RestoreHealthを完了させ、その後sfc /scannowを実行するのがMicrosoftの案内です。途中で閉じず100%完了を待ち、表示された結果をそのまま保存します。オフラインSFCでは/offbootdirと/offwindirを実際のWindowsパーティションへ指定し、推測したC:を使いません。CBS.logから必要な行だけを抽出して修復対象を確認します。
scan・verify・offline optionと四種類のresultを読む
「did not find any integrity violations」はprotected system fileに問題を検出しなかった結果です。「found corrupt files and successfully repaired」は修復後のrestartと再確認が必要です。「found corrupt files but was unable to fix some」はCBS.logとDISM sourceを確認します。「could not perform requested operation」はscan自体が完了していません。
- MicrosoftはDISM RestoreHealthをSFCより先に行う手順を案内している
- /scannowはすべてのprotected system fileをscanし可能なら修復する
- /verifyonlyは修復せずintegrityを検証する
- SFC詳細は%windir%\Logs\CBS\CBS.logへ記録される
- SFCはthird-party appやuser documentを修復するtoolではない
DISM RestoreHealthはWindowsイメージのcomponent storeを修復し、SFCはその健全なsourceを利用してWindows Resource Protection対象ファイルを検査・置換します。SFC成功はユーザーファイル、すべてのdriver、第三者アプリ、ディスク表面の健全性を保証しません。「破損を検出し修復」「破損を検出したが一部修復不能」「整合性違反なし」を区別して次の判断へ進みます。
途中終了や手動置換を避ける
CBS.logの一部を根拠にsystem fileを手動delete・download置換しません。DISMの/Sourceを使う場合は同じversion/edition/buildに合うtrusted sourceを確認します。SFC実行中にpowerを切らず、laptopをACへ接続します。業務serverではmaintenance windowとbackupを確保します。
- DISMを行わずSFCだけ繰り返す
- verification途中でwindowを閉じる
- 修復成功messageだけで症状が直ったとする
- untrusted siteからDLLをdownloadして置換する
- offline Windowsのdrive letterを通常起動時と同じだと思う
SFC/DISM中に強制終了せず、ノートPCはAC電源へ接続します。古いinstall.wimをsourceへ指定するとbuild不一致で失敗するため、組織の正規mediaと同じedition・language・buildを使います。CBS.logを丸ごと公開するとユーザー名やパスを含む場合があります。修復前に重要データとBitLocker回復キーを保全し、ディスクI/Oエラーがある場合は先にhardware診断を計画します。
再起動後にSFCと元症状を再検査する
restart後にsfc /verifyonlyまたは必要な再scanを行い、元症状、Windows Update、Event Viewerを確認します。修復fileがあった場合はCBS.logのtimestampと対象を記録し、application crashやExplorer動作等の実症状が再現しないことを確認します。
- DISMとSFCを正しい順序で完了した
- SFCの最終messageを四分類で記録した
- 修復後に元症状とWindows Updateを再testした
- 未修復fileがあればCBS.logとbuildを添えてescalateできる
修復後に再起動し、再度sfc /verifyonlyまたは/scannowで整合性違反がないか確認します。元の症状を同じ操作で再現し、Windows Update、主要アプリ、イベントログを確認します。CBS.logに同じファイルの修復不能が残る場合は、ファイルを手動置換せず、DISM source、更新状態、ストレージエラーを見直します。
修復結果に応じて次の手段を判断する
integrity violationなしならSFCを止め、driver、app、profile、hardware等の別仮説へ移ります。修復不能が残る場合はmatching repair source、in-place repair、support依頼を検討しますが、backupとBitLocker keyなしにresetへ進みません。
整合性違反なしで症状が残るなら、SFCを反復するのではなくアプリ、driver、ユーザープロファイル、ハードウェアへ調査を移します。DISM/SFCで修復不能が続く場合は、ログ、OS build、source、エラーコードを添えてin-place repairを計画します。リセットや再インストールはバックアップ復元とアプリ再導入を検証した後の選択です。
コメント