知識マップ: 産業用カメラ長期稼働クラッシュ調査 - ハンドルリーク編

記事「産業用カメラ長期稼働クラッシュ調査 - ハンドルリーク編」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

この記事は、産業用カメラ制御アプリが約1か月の連続稼働後に突然落ちた事例をもとに、ハンドルリークの見つけ方とログ設計を整理したものです。ハンドルリークはtimeoutやreconnectのfailure pathでCreateEventのハンドルがCloseHandleされずに漏れることで起き、戻らないHandle Countとして表れ、GUIが同居するアプリではGDIオブジェクトの上限に先に達して二次障害として表面化します。対策はRAII型やfinallyで所有権と解放の責務を近づけ、CloseHandleの呼び忘れそのものを防ぐことです。長時間運転後クラッシュの切り分けでは、月単位の再現を待たずfailure pathを短いループで大量に踏み、Handle Count・Private Bytes・Thread Countと構造化ログを併せて見ることが土台になり、後編のApplication Verifierはその上に乗る手段として位置付けられます。

flowchart LR
    accTitle: 産業用カメラ長期稼働クラッシュ調査(ハンドルリーク編)の知識マップ
    accDescr: 長時間運転後クラッシュの切り分けでHandle CountとPrivate Bytes・Thread Countを併せて見ること、failure pathでの解放漏れがハンドルリークを経て二次障害として表面化すること、RAIIとCloseHandleによる防止、構造化ログとApplication Verifierの位置付けを示す図。
    handle_leak["ハンドルリーク"]
    handle_count["Handle Count"]
    failure_path["failure path(異常系の途中失敗経路)"]
    memory_leak["メモリリーク"]
    private_bytes["Private Bytes"]
    createevent_api["CreateEvent"]
    closehandle["CloseHandle"]
    structured_logging["構造化ログ(structured log)"]
    application_verifier["Application Verifier"]
    raii["RAII(Resource Acquisition Is Initialization)"]
    secondary_failure["二次障害(secondary failure)"]
    gdi_object["GDIオブジェクト"]
    long_run_crash_investigation["長時間運転後クラッシュの切り分け"]
    thread_count["Thread Count"]
    failure_path -->|"原因になり得る"| handle_leak
    handle_leak -->|"で確認できる"| handle_count
    memory_leak -->|"で確認できる"| private_bytes
    createevent_api -->|"前提とする"| closehandle
    structured_logging -->|"推奨される対応"| handle_leak
    structured_logging -->|"より先に行うべき"| application_verifier
    raii -->|"防止する"| handle_leak
    raii -.->|"利用する"| closehandle
    application_verifier -.->|"軽減する"| handle_leak
    handle_leak -->|"原因になり得る"| secondary_failure
    structured_logging -->|"推奨される対応"| secondary_failure
    closehandle -->|"防止する"| handle_leak
    gdi_object -.->|"原因になり得る"| secondary_failure
    handle_count -->|"推奨される対応"| long_run_crash_investigation
    structured_logging -->|"推奨される対応"| long_run_crash_investigation
    failure_path -->|"推奨される対応"| long_run_crash_investigation
    private_bytes -->|"推奨される対応"| long_run_crash_investigation
    thread_count -->|"推奨される対応"| long_run_crash_investigation

概念間の関係(全18件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• failure path(異常系の途中失敗経路)はハンドルリークの原因になることがあります。timeout・reconnect・early returnなどの途中失敗経路でCloseHandleが呼ばれないと、ハンドルリークの原因になることがある。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ハンドルリークはHandle Countで確認できます。ハンドルリークは、reconnectなどの操作後にHandle Countが戻らずじわじわ増え続けることで確認できる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• メモリリークはPrivate Bytesで確認できます。メモリリークはPrivate Bytes(やCommit)がじわじわ増えることで確認できる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• CreateEventはCloseHandleを前提とします。CreateEventが返したイベントハンドルは、使用後にCloseHandleで解放することを前提とする。CloseHandle自体はファイル・プロセス・スレッド・ミューテックスなど多くのカーネルオブジェクトのハンドルを閉じるもので、CreateEventに限らない。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 構造化ログ(structured log)はハンドルリークに対する本記事の推奨です。create/openとclose/disposeの対応が崩れている箇所は、sessionId・resourceId・actionを持つ構造化ログで探すことが本記事の推奨対応である。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 構造化ログ(structured log)はApplication Verifierより先に行うべきです。後編で扱うApplication Verifierを使う前に、自前の構造化ログでlifetimeの崩れを追えるようにしておくのが土台になる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• RAII(Resource Acquisition Is Initialization)はハンドルリークを防ぎます。RAII型でハンドルの生存期間をオブジェクトの生存期間に結び付けると、途中失敗の経路でも自動的にCloseHandleが呼ばれるためハンドルリークを防げる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• RAII(Resource Acquisition Is Initialization)はCloseHandleを利用します。Windowsのハンドルを保持するRAII型では、デストラクタが保持しているハンドルに対してCloseHandleを呼んで解放する。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Application Verifierはハンドルリークを軽減します。Application Verifierは低リソース時のfailure pathを前倒しで踏ませることで、ハンドルリークのような出にくい壊れ方を早期に表面化させる有効な手段とされる。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• ハンドルリークは二次障害(secondary failure)の原因になることがあります。ハンドルリークは、蓄積の結果として新しいevent/file/threadを作るAPIの失敗という形で、数週間後に二次障害として表面化することが多い。クラッシュ地点は漏らした場所ではなく最後の被害者であることが多い。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 構造化ログ(structured log)は二次障害(secondary failure)に対する本記事の推奨です。session/resource lifecycleの構造化ログをたどることで、落ちた場所ではなく漏らした場所という二次障害の本当の原因を特定することが本記事の推奨対応である。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• CloseHandleはハンドルリークを防ぎます。途中失敗の経路も含めてCloseHandleを漏れなく呼ぶことが、ハンドルリークの防止そのものになる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• GDIオブジェクトは二次障害(secondary failure)の原因になることがあります。GDIオブジェクトのハンドルを漏らした場合、プロセスあたりの既定上限(GDIProcessHandleQuotaで256〜65,536)がカーネルオブジェクトの理論上限より低いため、GUIが同居するアプリではこちらに先に達し、新しい描画資源を作れなくなって二次障害として表面化することがある。CreateEventのようなカーネルハンドルの漏れ自体はGDIの枠を消費しない。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Handle Countは長時間運転後クラッシュの切り分けに対する本記事の推奨です。長時間運転後にだけ落ちるアプリの切り分けでは、Private Bytesだけでなく Handle Countも必ず見ることが推奨される。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 構造化ログ(structured log)は長時間運転後クラッシュの切り分けに対する本記事の推奨です。落ちた瞬間の例外だけでなく、operation/session/resource lifecycleの構造化ログを先に整えておくことが、長時間運転後クラッシュの切り分けに効く。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• failure path(異常系の途中失敗経路)は長時間運転後クラッシュの切り分けに対する本記事の推奨です。長時間運転後クラッシュの切り分けでは、月単位の再現を待たず、timeout・reconnect・early returnなどのfailure pathを短いループで大量に踏んで再現を圧縮することを本記事は推奨している。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Private Bytesは長時間運転後クラッシュの切り分けに対する本記事の推奨です。長時間運転後にだけ落ちるアプリの切り分けでは、Handle Countと合わせてPrivate Bytesも継続的に見ることで、主犯がメモリかハンドルかを切り分けられる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Thread Countは長時間運転後クラッシュの切り分けに対する本記事の推奨です。長時間運転の切り分けでは、スレッドリークの可能性を除外するため、Handle Count・Private Bytesと並んでThread Countも一緒に見ることが基本になる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典

主要概念の定義

ハンドルリーク

参照カウントやハンドルカウントの数え違いなどにより、不要になったハンドル(ファイル・イベント・スレッド・GDIオブジェクト・アクセストークンなどカーネルオブジェクトへの参照)が解放されずに積み上がっていく状態。

Handle Count

プロセスが現在開いているハンドルの総数を表す、Windowsプロセスの計測値。

failure path(異常系の途中失敗経路)

timeout・reconnect・early returnなど、正常系ではなく処理が途中で失敗して抜けるコード経路。資源の解放漏れが起きやすい。

メモリリーク

確保したメモリを解放し忘れ、Private BytesやCommitが増え続ける現象。

CreateEvent

イベントオブジェクトを作成し、そのハンドルを返すWin32 API。呼び出し元は使用後にCloseHandleでハンドルを解放する必要がある。

構造化ログ(structured log)

文章ではなくkey=valueのように項目を決めて出力し、あとで機械的に集計できるログの形式。

RAII(Resource Acquisition Is Initialization)

オブジェクトの生成時に資源を確保し、デストラクタでの解放を保証することで、途中失敗時にも資源が漏れないようにするC++の設計パターン。

Application Verifier

Windowsのuser-modeアプリに対するランタイム検証ツールで、OS API利用や資源の扱い方を監視し誤用の検出や意図的な失敗の注入を行う。

CloseHandle

プロセスのハンドルテーブルからエントリを1つ削除するWin32 API。「ファイルを閉じる」ことそのものではない。

GDIオブジェクト

ペン・ブラシ・デバイスコンテキストなどGDIが管理する描画資源で、プロセスあたりの既定上限に達するとそれ以上作成できなくなる。

Private Bytes

プロセスが専有しているコミット済みメモリ量を表す、Windowsプロセスの計測値。

Thread Count

プロセスが持つスレッド数を表す計測値。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。