windows-ops

windows-ops

解決できる問題

起動が遅い、または遅くなっている、ドライブが気付かれないまま故障している、明確な原因のないクラッシュ、管理者権限がないと無効にできない HKLM のスタートアップエントリ、ダンプが残らない BSOD、説明のない UAC プロンプト、「このドライブを安全に取り外せるか？」、故障しかけたドライブのクローン作成、起動不能からの復旧、リモート診断、起動時に原因が分からないまま高温になったり、コミット上限を超えたりするマシンに対応します。各シグナルの場所については、references/symptom-guide.md をご覧ください。

普遍的な知見

適切なログに適切な方法で問い合わせれば、Windows は問題の原因を教えてくれます。 ほとんどのユーザー（そしてほとんどのチュートリアル）はタスクマネージャーに頼ります。実際の診断シグナルは、イベントログ、レジストリの StartupApproved キー、ストレージドライバーのリセットイベント、カーネルのバグチェック記録にあります。このスキルは、ノイズを診断結果に変えるクエリをまとめたものです。

最もよくある診断上の失敗は、症状を個別に扱うことです。「起動が遅い」→スタートアップアプリを無効にする。「BSOD」→ドライバーを再インストールする。「ランダムにクラッシュする」→メモリテストをする。これらは最終手段としては妥当ですが、実際の原因を特定するデータは、手付かずのままシステムログに残っています。対処する前に、必ず監査してください。

診断の段階

各レイヤーを順番に確認してください。各段階には、二者択一の結果があります。

0. Is it even local?  — a "drive" that is a network mapping belongs to net-ops
1. Hardware errors    — WHEA-Logger events (CPU/RAM/PCIe-level faults)
2. Storage health     — disk events 7/52/153/154, storahci 129 (controller reset)
3. Crash record       — Event 41 (Kernel-Power) + BugCheck code + dump files
4. Pre-crash timeline — events in N minutes before each crash
5. Boot inventory     — all 5 startup mechanisms (registry, services, tasks, folders, group policy)
6. Resource pressure  — CPU RATE sample, commit hoarders, orphans, stale hosts
7. Verdict            — what's failing, what to do

最も興味深い障害は、段階 2（ストレージ）と段階 5（スタートアップの肥大化）に集中します。最もよく対処され、最も誤読されるのは段階 6 です。そこでのタスクマネージャーのスナップショットは本当に情報価値が低く、そのため無視されがちです。しかし、同じ段階で CPU のレートをサンプリングすると、スナップショットでも孤立チェックでも検出できない、ハングしたプロセスを見つけられます。

ワークフロー

0. まずドライブ文字の正体を見極める

「Z: ドライブが壊れている」と言うユーザーには、それが故障中の物理ディスク（このスキルの対象）なのか、SMB／名前解決の障害（net-ops）なのか分かりません。どちらもドライブ文字は同じように見えます。他の処理を実行する前に確認してください。

Get-SmbMapping                            # network mappings + Status (Connected / Disconnected / Unavailable)
Get-PSDrive -PSProvider FileSystem | Where-Object DisplayRoot   # non-empty DisplayRoot = UNC-backed

どちらかの結果にその文字が表示された場合、それはネットワークマッピングです。ここで処理を止め、net-ops（scripts/windows/smb-audit.ps1）に引き継いでください。 物理ディスクの診断手順は実行しないでください。disk-health.ps1 と drive-dependencies.ps1 が確認できるのはローカルディスクだけなので、実際に故障しているドライブを正常と報告してしまいます。それは何も報告しないよりも悪い結果です。

以下はすべて、ローカルに物理接続されたドライブを前提としています。

1. 包括的な監査を実行する

scripts/health-audit.ps1

診断結果ブロックが出力されます。ハードウェアエラー、ディスクごとのストレージ健全性、最近のクラッシュ、リソース消費量の上位項目、スタートアップ項目を確認してください。[FAIL] マーカーを探し、そこから詳細を調べます。

2. 問題のあるレイヤーを詳しく調べる

症状	スクリプト
ストレージエラーが検出された	scripts/disk-health.ps1 -DiskNumber N（または -DriveLetter X、-Model 'HGST'）— ドライブごとの詳細調査：SMART、すべてのイベント ID、ドライブに起因するコントローラーのリセット、診断結果
最近のクラッシュ	scripts/crash-triage.ps1 -CrashTime <datetime>（または省略すると最新のクラッシュ）— クラッシュ前のタイムラインと、決定的な証拠を検出する BugCheck のデコード
「ドライブ X を取り外しても安全ですか？」	scripts/drive-dependencies.ps1 -DriveLetter X — ドライブを参照するページファイル、検索インデックス、スケジュールされたタスク、サービス、シンボリックリンク、スタートアップショートカット、実行キーの参照を検出
「起動に時間がかかるのはなぜですか？」	scripts/boot-perf.ps1 — Diagnostics-Performance ログ（管理者権限）またはカーネルイベントのフォールバック（非管理者権限）から、起動ごとの所要時間と遅いコンポーネントのフラグを出力

3. 最小限の可逆的な修正を適用する

操作	スクリプト
スタートアップアプリを無効化 — Run キー（HKCU + HKLM + WOW64）	scripts/safe-disable-startup.ps1 -Name <pattern>（管理者権限は不要です。ワイルドカードに対応しています）
スタートアップフォルダーのショートカットを無効化	scripts/safe-disable-startup.ps1 -Name '*.lnk'（同じスクリプトの StartupFolder バリアントで処理します）
現在のすべてのスタートアップ項目の状態を一覧表示	scripts/safe-disable-startup.ps1 -List
以前に無効化した項目を再度有効化	scripts/safe-disable-startup.ps1 -Name <pattern> -Enable
サービスを手動に設定（管理者権限が必要）	Set-Service <name> -StartupType Manual; Stop-Service <name>
スケジュールされたタスクを無効化	Disable-ScheduledTask -TaskName <name>
エラーで停止せずにフォルダーツリーをコピー	scripts/copy-tree.ps1 <src> <dst> — 追加コピー方式。ファイルごとに1回再試行し、失敗したファイルの読みやすいログを出力します。終了コード 10 = 一部のファイルのコピーに失敗しました
読み取りエラーが発生するドライブから安全にクローン	scripts/copy-tree.ps1 <src> <dst> -Mode Rescue — /R:0 /W:0 /MT:1 を指定した robocopy を使用するため、再試行で不良セクターに負荷をかけません
フォルダーをミラーリング（コピー先の余分なファイルは削除されます）	scripts/copy-tree.ps1 <src> <dst> -Mode Mirror — -Force を指定しない場合は確認を求めます
ファイル単位でコピーできないほど損傷したドライブ	scripts/rescue-image.ps1 -ListDevices を実行し、続けて -Device <dev> -Image <path> を指定します — ddrescue を使用し、処理を監視でき、mapfile を使って再開できます
レスキューイメージからファイルを取り出す	scripts/extract-image.ps1 -Image <img> -Plan を実行し、続けて -Extract -Dest <dir> -Include <pat> を指定します — 7-Zip を使用し、読み取り専用で、マウントは不要です

無効化はすべて元に戻せます。StartupApproved レジストリの仕組みでは1バイトを切り替えるだけなので、再度有効化すると逆の操作が行われます。

ストレージの状態と障害の検出

最も効果の高い監査です。ドライブの故障は、起動の遅延（Windows がドライブの確認でタイムアウトするため）、不安定な動作（コントローラーのリセットが連鎖してカーネルのハングを引き起こすため）、クラッシュ（I/O エラーで重要なプロセスが停止するため）の原因になります。相互参照する独立した3つのデータソースがあります。

ディスクイベント 7（不良ブロック）と 154（ハードウェアエラー）は重大度の高い ID です。1か月に10件でも故障の強い兆候であり、数百件に達した場合は直ちに交換してください。storahci イベント 129（コントローラーのリセット）は、正常な場合はゼロで、1か月に5件を超える場合は故障が進行中です。\Device\HarddiskN の N は Get-Disk の番号です。scripts/disk-health.ps1 は3つすべてを実行します。手動クエリ、イベントカタログ、SMART の代替手段については、references/manual-queries.md を参照してください。

起動パフォーマンスとスタートアップの管理

Windows には5つの独立したスタートアップ機構があり、それぞれ異なるツールが必要です。タスクマネージャーに表示されるのは、そのうち2つだけです。完全な一覧は references/startup-mechanisms.md を参照してください。

機構	場所	確認方法	無効化方法
レジストリの Run キー	HKCU/HKLM\...\Run（+ WOW6432）	Get-ItemProperty	StartupApproved のバイナリフラグ
サービス	サービスコントロールマネージャー	Get-Service	Set-Service -StartupType Manual（管理者権限が必要）
ログオン時のスケジュールされたタスク	タスクスケジューラ	Get-ScheduledTask	Disable-ScheduledTask
スタートアップフォルダーのショートカット	%APPDATA%\...\Startup\ + AllUsers	Get-ChildItem	.lnk を削除または名前変更
グループポリシーのスタートアップスクリプト	HKLM\...\Policies\Scripts	グループポリシーエディター / gpresult	（ワークステーションではまれです）

タスクマネージャーで「無効にする」を選ぶと、HKCU の下に12バイトの StartupApproved フラグが書き込まれます（0x02 は有効、0x03 は無効）。そのため、管理者権限がなくても HKLM の項目を自分のユーザーに対して無効化できます。これを行うのが scripts/safe-disable-startup.ps1 です。起動時間は管理者のみがアクセスできる Diagnostics-Performance ログに記録されます（scripts/boot-perf.ps1 はカーネルイベントを代替として使用します）。正常な SSD ではログオンまで15～25秒、ストレージに障害がある場合は60秒以上かかります。詳細は references/manual-queries.md を参照してください。

クラッシュ分析とダンプのトリアージ

イベント 41（Kernel-Power）はクラッシュ記録です。Properties[0] は BugCheck コード（0x0 ＝記録なし。つまり、突然の電源断またはハング）を示し、インデックス 6 がゼロ以外の場合は、電源ボタンが長押しされています。その直前の 10 分間に状況を示す記録が残っています。storahci 129 → ストレージ障害の連鎖、GPU ドライバーの警告 → ドライバーのハング、WHEA → ハードウェア障害、記録なし → 完全なハング（scripts/crash-triage.ps1 -CrashTime …）。クラッシュ後にダンプがない場合は、CrashControl\CrashDumpEnabled とページファイルのサイズを確認してください。構成とデコードの表はreferences/manual-queries.md、停止コードはreferences/bugcheck-codes.mdを参照してください。

暴走プロセスのトリアージ

対象は起動時ではなく、通常稼働中です。何かが 今まさに マシンのリソースを消費しています。 この分野で重要なのは、系譜ではなく、消費率を測ることです。

累積 CPU 使用率から分かるのは、プロセスがこれまでに行ったことです。孤立プロセスのスキャンでは、親プロセスが終了したものを特定できます。しかし、どちらも最も厄介なケースは見つけられません。監督プロセスは正常に動作しているのに、ほぼ 1 コア分の処理を消費して何も生み出さず、停止したプロセスです。

scripts/process-triage.ps1                                 # sample all, flag >=20% of a core
scripts/process-triage.ps1 -Name claude,node -Threshold 50 # hunt agent/editor spinners
scripts/process-triage.ps1 -Json | ConvertFrom-Json        # machine-readable findings
scripts/process-triage.ps1 -Tree 35736                     # what a kill takes, leaves-first

終了コード 10 は検出あり、0 は問題なしです。一定の時間をあけて CPU を 2 回測定し、プライベートコミット、経過時間、孤立状態とともに、1 コアに対する割合を示します。何かを終了させることはありません。-Tree は順序付きリストを出力するため、呼び出し元が意図的に対処できます。

重要な保護機能。 スクリプトは報告の前に、このセッション自体のプロセスの親子関係（シェル → エージェントホスト → アプリケーション）を解決し、各段階にprotected=Trueの印を付けます。これらのいずれかを終了させると、調査中のセッションが終わるため、そのプロセスが候補と見分けられない状態になってはなりません。手作業で行う場合は、何よりも先に自分自身の PID をParentProcessIdに沿ってさかのぼってください。

その後、末端から順に終了させます。監督プロセスがすでに終了した子プロセスを再生成できないよう、最も深い子孫から先に終了させてください。後続の項目に「すでに終了」と表示されるのは、連鎖が機能している証拠であり、エラーではありません。プロセスを終了させてもファイルは削除されないため、そのディレクトリにある未コミットの作業はそのまま残ります。

RAM ではなくコミットを報告してください。 Windows では、物理メモリを使い切る前にコミット（RAM + ページファイルによる保証、Win32_OperatingSystem.FreeVirtualMemory）が枯渇します。そのため、空き RAM があるマシンでも、新しいプロセスを開始できなくなることがあります。プロセス数、プライベートコミット、マシンの空きコミットについて、終了前後の値を示してください。コミットを解放すると、終了したプロセスが消費していた量の合計以上に回復することがよくあります。

3 つの障害クラス、トリアージの手順、Electron／エージェントホストのトポロジー、古いビルドの検出、ワークツリーの解体に関するケースなど、詳しい内容はreferences/process-triage.mdを参照してください。

イベントログのクエリパターン

Get-WinEvent -FilterHashtableでフィルターしてください（Where-Objectよりはるかに高速です）。使用できるキーはreferences/manual-queries.mdを参照してください。

よくある障害パターン

症状	最初に確認すること	よくある原因
マップされたドライブがDisconnectedと表示される／UNC パスに到達できない	ネットワークドライブのマッピングですか？Get-SmbMapping	net-opsに引き継いでください。ローカルストレージの障害ではありません
以前は速かったのに、起動が遅い	boot-perf.ps1、続いてhealth-audit.ps1のスタートアップセクション	不要なものの蓄積（Docker、Adobe CC、Electron アプリ）
起動が遅く、悪化している	disk-health.ps1	ドライブの故障。Windows がプローブのタイムアウトを待っている
ランダムなフリーズと突然の再起動	disk-health.ps1 + crash-triage.ps1	storahci のリセットが連鎖してカーネルハングに至る
スリープ復帰時の BSOD	crash-triage.ps1（BugCheck 0x9F）	ドライバーの電源状態障害（多くは GPU、USB）
WHEA の後に発生する BSOD	crash-triage.ps1（BugCheck 0x124）	ハードウェア障害。RAM、CPU、PCIe レーン
クラッシュはしないが動作が重い	health-audit.ps1のパフォーマンスセクション	バックグラウンドプロセスの蓄積
ログインに数分かかる	boot-perf.ps1（起動後の時間）、続いてsafe-disable-startup.ps1 -List	スタートアップ項目が同期処理でシェルをブロックしている

復旧パターン

故障中のドライブからクローンを作成する

故障中のドライブに対して chkdsk /f を絶対に実行しないでください。修復処理は不良セクターに書き込みを行うため、ドライブにとどめを刺すおそれがあります。まずイメージを作成し、修復はそのイメージに対して行ってください。

# Healthy-side clone with no retries (fast, skips bad sectors)
robocopy "Y:\important" "Z:\backup\important" /MIR /R:0 /W:0 /XJ /NDL /LOG:clone.log

不良セクターが多数あるドライブからビット単位で復旧するには、マップファイルを使って処理を再開できるようにし、WSL またはライブ Linux USB 経由で ddrescue を使用してください。詳細は references/storage-events.md に記載されています。

故障中のドライブを物理的に取り外す

ドライブが起動の停止やクラッシュを引き起こしている場合：

1. disk-health.ps1 でドライブを特定します
2. 重要なものがそのドライブを参照していないことを確認します（scripts/disk-health.ps1 -CheckDependencies <drive-letter>）
3. SATA ケーブルを物理的に外す、BIOS で無効にする、または diskpart でオフラインにします
4. 再起動します。起動時間が大幅に短縮され、コントローラーのリセットも止まるはずです

音声と出力のスタイル

出力は claude-mods の診断規約に従います。

• スキャン結果の各行には [PASS] ／ [FAIL] ／ [WARN] ／ [INFO] のプレフィックスを付けます
• 最下部に、具体的な検出事項と推奨アクションを記載した判定ブロックを配置します
• ドライブの識別情報には、物理ディスク番号、モデル、容量、ドライブ文字を含めます
• クラッシュの参照情報には、UTC タイムスタンプ、BugCheck コード、主要パラメーター、推定原因を含めます
• 宣伝文句は使わず、スクリプトでは絵文字を使いません（有用な場合に SKILL.md の文章で使う場合を除く）

このスキルの対象外

• ネットワーク診断。ストレージのように見えて、実際はネットワーク上にあるものも含みます → net-ops を使用してください。具体的には、マップされたネットワークドライブ、Disconnected ／ Unavailable のままになっているマッピング、開けない UNC パス（\\server\share）、SMB 自体、NAS や Synology の装置、net use の失敗、共有への「アクセスが拒否されました」などです。ドライブ文字が付いていても、ローカルとは限りません。
• アプリケーションのパフォーマンスプロファイリング（フレームグラフ、py-spy/pprof、負荷テスト、低速なクエリ） → perf-ops を使用してください。使い分けは次のとおりです。windows-ops はワークステーションをトリアージし、どのプロセスがマシンに負荷をかけているか、終了しても安全かを調べます。perf-ops は最適化対象のプログラムの内部をプロファイリングします。
• ソースコードレベルのデバッグ → debug-ops を使用してください
• WinDbg によるカーネルダンプファイルの分析 — このスキルの対象としては専門性が高すぎるため、参照ドキュメントへの案内のみを扱います
• グループポリシーの診断 — エンタープライズ環境では関係しますが、ワークステーションではまれです
• WSL ディストリビューションの内部（Linux パッケージ、サービス、Linux アプリ固有の不具合）— Linux 側のスキルを使用してください。WSL 自体（構成、ネットワークモード、ディスク）は対象です：references/wsl.md

相互参照

条件	使用するもの
故障した「ドライブ」がネットワークマッピング／NAS 共有（SMB、UNC、Disconnected）である	net-ops の対象です。マッピングと SMB/LAN の診断手順には scripts/windows/smb-audit.ps1 を使用してください
リモートの Windows マシンをトリアージする必要がある	net-ops のリバースプローブパターンをそのまま応用できます
クラッシュがネットワーク関連である	DNS ／ VPN ドライバーの問題には net-ops を併用してください
複数のマシンで同じパターンが見られる	各マシンで health-audit.ps1 を実行し、出力を比較します
フラグが付いたスピナーに、すでに存在しない git worktree が表示されている	worktree のライフサイクルは fleet-ops の対象です。teardown の順序に関する落とし穴 を参照してください
マシンをトリアージするのではなく、アプリの内部をプロファイリングする必要がある	perf-ops
WSL：.wslconfig が適用されない、NAT とミラーリングネットワークの違い、Hyper-V ファイアウォール、容量だけが増え続けるディストリビューションのディスク	references/wsl.md を参照してください。Docker Desktop のエンジンと WSL データディスクについては docker-ops を使用してください

参考資料

• references/storage-events.md — ディスクおよびコントローラーのイベント ID、障害のしきい値
• references/bugcheck-codes.md — BSOD の停止コードと、考えられる原因
• references/startup-mechanisms.md — 5 つのスタートアップメカニズム、ベンダーの自動起動フック
• references/recovery-patterns.md — データ復旧、chkdsk の判断フロー、BCD と起動不能の修復。破壊的な操作の前に読み込んでください
• references/uac-attribution.md — 管理者権限を要求したものを、その時点と事後に確認する方法
• references/process-triage.md — スピナー、孤立プロセス、リソースを大量に消費するプロセス。安全な終了順序
• references/remote-diagnostics.md — リモートマシンでこのスキルを実行する方法
• references/symptom-guide.md — 問題の内容からシグナルを特定するガイド
• references/manual-queries.md — スクリプトで自動化しているクエリとデコードテーブル
• references/worked-example.md — ドライブ障害事例の最初から最後まで
• references/wsl.md — WSL 2：.wslconfig と wsl.conf、ネットワークモード、Hyper-V ファイアウォール、DNS、/mnt/c の速度、ディストリビューションのディスク（サイズ変更、スパース化、コンパクト化）

各資料をすべて読み込むタイミングについては、references/reference-index.md を参照してください。

実例

health-audit.ps1、disk-health.ps1、drive-dependencies.ps1 の各パネルを使って、起動が遅くクラッシュする PC を調査し、その後修復ループに進みます。すべてのスクリプトは -Json（jq 用）と -Verbose を受け付け、パイプ経由で実行するとパネルの装飾を省略します。パネルとコマンドの全手順については、references/worked-example.md を参照してください。