続 IISとASP.NETとApplicationPoolをいじっていたらよくわからない現象に悩まされたこと
前回のブログ
の続き
前回の設定でちゃんと動くようになったと思っていたんですが、やっぱり駄目でした
そこそこ効果がありそうなおまじないを唱えることができたので、前回のものに追記しつつその対策までを（おまじないなので解決策になっていないですし、原因も大外れかもしれないです）
やったこと
追加 →
IISのApplication Initialization（だったっけ？）を有効にしてOS起動したら即Web APIをアクセスするようにした （これでサーバー起動してからお茶していれば使えるようになっている・・・）
現象
OSを起動してWeb APIにアクセスすると30分以上応答がかえって来ない
追加 →
イベントログをみたらアプリケーションプールの再起動が多発
アプリケーションプールのPingタイムアウトで強制終了 → 起動でWeb APIアクセスを繰り返していた
何かのタイミングでWeb APIが応答を返すと使えるようになる
Web APIと同じこと（Web API内ではサードパーティー製の64bit DLL (Cで使うやつ)をラップしたDLLをP/Invokeで使用）をするデスクトップアプリ（WPF製）を実行すると似たような現象が発生
アプリ起動 → 固まる（かなり待っても応答なし） → 強制終了 → 起動 → 動く
リソースモニタでアクセスするファイルを見ているとサードパーティ製DLLのインストールフォルダにあるファイル（DLLとかいろいろ）のアクセスで止まっている感じ（正常起動時はその後に別のデータの読み込みまで確認できる）
サードパーティ製DLLに付属しているアプリ（多分ネイティブアプリ）はすんなり動く
上記アプリを起動するとなぜか.Net製もいきなり動く
よく外れる予想
サードパーティ製DLLのOS起動後初回P/Invokeで、OS（または.Net）が何らかのセキュリティチェックを行っているのでは？
そのチェックがデッドロックしているので再起動でのみ復帰するのでは？
チェック結果はある程度保持されていて2回目以降のチェックは省略されるのでは？
という仮説を立てた
ちなみに私は仮説を立てて文章にするとよく外れる
おまじない1
プリロード専用のWeb APIを作成
上記APIではまずサードパーティ製DLL付属のアプリを起動（即殺す）
その後いつもの処理を実行
効果は微妙
おまじない2
サービスを一つ作成
サービスでサードパーティ製DLL付属のアプリを起動（即殺す）
効果はそこそこ
ということで現在はこの二つのおまじないでだましだまし使ってもらっている状態です
原因わかって解決する日は来るのだろうか・・・
