20260215-0002-DLLエントリポイントエラーの真因調査報告

現象

極小構成（Tauriのデフォルトテンプレートのみ）でビルドした telos-db.exe においても、起動時に STATUS_ENTRYPOINT_NOT_FOUND (0xc0000139) が発生し続ける。

調査結果：なぜ「明示的な依存関係」が外部パスに影響されたのか？

ユーザーの「依存範囲は明示的なはず」という指摘は、ソースコードレベル（Cargo/npm）では正しいですが、Windows OS の実行時（Runtime）レベルでは以下の「暗黙の優先順位」が優先されるため、エラーが発生しました。

1. Windows DLL 探索プロトコル (Search Order)

Windows が DLL を探す順序は以下の通りです：

アプリケーションの実行ディレクトリ（.exe がある場所）
システムディレクトリ (C:\Windows\System32)
環境変数 PATH に設定されたディレクトリ（先頭から順に）

2. ABI (Application Binary Interface) の不整合

今回のエラー 0xc0000139 は、「DLL ファイルは見つかったが、その中にあるはずの関数が見つからない」ことを意味します。これは以下の理由で起こります：

MSVC ビルド: Microsoft 形式で関数を命名（マングリング）。
MinGW ビルド: GNU 形式で関数を命名。

アプリケーションが MSVC でビルドされている場合、MSVC 形式の関数を DLL から探します。しかし、PATH のどこかに MinGW でビルドされた同名の DLL（例: WebView2Loader.dll）が存在し、OS がそれを先にロードしてしまうと、「名前は同じだが、中身の形式（呼び出し規約）が違う」ため、エントリポイントが見つからずクラッシュします。

3. 今回の具体的な「汚染源」

スキャンの結果、以下のパスに MinGW 系の DLL が多数存在することが判明しました：

D:\LLM\text-generation-webui\installer_files\env\Library\mingw64\bin
C:\msys64\... (以前の調査で確認)

これらのディレクトリが PATH に含まれていると、Cargo がどれだけ厳密に依存関係を管理していても、OS が実行時に「あ、近くの PATH に WebView2Loader.dll があったから、これをロードしよう」と勝手に誤認してしまいます。

解決策

PATH 環境変数から、MinGW, MSYS2, その他 LLM インストーラが追加したパスを一時的に除外する。
もしくは、必要な MSVC 版の DLL を .exe と同じディレクトリに明示的に配置する。

今後の作業

src/backend/src/lib.rs を元の正常なロジックに復元する。
Cargo.toml の libsqlite3-sys の指定を元に戻す（環境がクリーンなら不要）。
ユーザーに PATH の確認と修正を依頼する。

graph TD
    A[Cargo ビルド] -->|MSVCツールチェーン| B[telos-db.exe 生成]
    B -->|実行開始| C{DLL 探索開始}
    C -->|1. 実行ディレクトリ| D[なし]
    C -->|2. PATH 環境変数| E[D:\LLM\... を発見]
    E -->|MinGW版 DLL をロード| F[ABI 不整合発生]
    F -->|クラッシュ| G[0xc0000139 Error]