私は、VB6 で記述されたいくつかの古い COM コンポーネントを使用するクラシック ASP Web アプリケーションに取り組んでいます。すべての VB6 コンポーネントは、独自の dllhost プロセスで実行される COM+ アプリケーションに登録されます。アプリケーションの大部分は .Net に変換されましたが、多くのレガシー ページとコンポーネントがまだ残っています。COM Interop は双方向で使用され、ASP.Net から VB6 コンポーネントを呼び出すだけでなく、従来の ASP と VB6 からいくつかの .Net アセンブリを呼び出します。アプリケーションは、Windows Server 2008 R2 (IIS 7.5) でクラシック パイプライン モードで実行されています。
ほとんどの場合、アプリケーションは正常に動作します。.Net への移行は最終的に断念され、代わりに新しい製品が開発されました。その間、古い製品は異種混合状態で維持する必要があります。
Web アプリケーションがハングする断続的な問題を追跡するのに苦労しています。ブラウザが待機している間、ユーザーには空白の画面が表示されるだけで、サーバーは応答しません。VB6 コンポーネントをホストしている dllhost プロセスを手動で強制終了するまでハングが続くため、問題はそこに埋もれていると思います。おそらく、メモリ リークまたは循環ループの暴走です。
システムには毎日何千人ものユーザーがいますが、問題は週に 1、2 回しか発生しません。幸いなことに、サーバーが応答しなくなったときにサーバーを自動的に引き抜く Web ファームがあるため、顧客への影響はゼロです。それでも、何が起こっているのかを理解したいと思います。
すべての VB6 コンポーネントを再コンパイルしてデバッグ シンボルを含め、本番環境に再デプロイしました。問題が発生した場合、32 ビット タスク マネージャー (c:\windows\syswow64\taskmgr.exe) を使用して、dllhost プロセスのクラッシュ ダンプを取得します。最終的に dllhost.dmp ファイルが作成され、これを開発ワークステーションに落として VS2010 で開きます。VB6 がシンボル パスに作成した .pdb シンボル ファイルがあります。VS2010 でデバッグ セッションを開始すると、[モジュール] 画面に移動して、実際にコンポーネントのすべてのシンボルが読み込まれていることを確認できます。
ここからどこへ行く？コール スタックには、独自のコンポーネントは表示されません。次のようになります。
コール スタックの上部の逆アセンブリは次のようになります。
他に何ができるかわかりません。コールスタックのすべてのフレームですべてのローカルを調べましたが、意味不明です。自分のコンポーネントへの参照が見当たりません。
おそらく、WinDbg でより多くの情報が得られるでしょうか? どこから始めればよいかわかりません。
ハングが発生したときに呼び出されていた VB6 クラス/メソッドを見つけることができれば、その原因を突き止めることができると確信しています。ログを追加しようとしましたが、結果に一貫性がありません。
私の VB6 コンポーネントには何も問題がないのかもしれませんが、Windows または IIS 内で何らかのバグが発生しているのですか?
アドバイスをいただければ幸いですが、現時点で VB6 を捨てるという選択肢はありません。ありがとう。