ASP.NET アプリで悪いことをしています。それは、私が使用している CTP ライブラリの任意の数である可能性があります。または、何かを適切に破棄していないだけです。しかし、ASP.NET を Vista IIS7 インストールまたはサーバーの IIS6 インストールに再展開すると、IIS ワーカー プロセスがクラッシュします。
問題を HTTP クローラーに絞り込みました。HTTP クローラーは、必要に応じて有用な情報を求めてサイトをクロールするマルチスレッドの野獣です。appDomain を正常にアンロードしてリロードするのではなく、クローラーを開始してアプリを再デプロイすると、IIS ワーカー プロセスがクラッシュし (クラッシュ メッセージがポップアップ表示され)、アプリ ドメインのリロードが続行されます。
このクラッシュが発生した場合、分析用のクラッシュ ダンプはどこにありますか?
Windows 用のデバッグ ツールをダウンロード: http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
Debugging Tools for Windows には、プロセスがクラッシュしたときにダンプを作成できるスクリプト (ADPLUS) があります: http://support.microsoft.com/kb/286350
コマンドは次のようになります (IIS6 を使用している場合)。
cscript adplus.vbs -crash -pn w3wp.exe
このコマンドは、デバッガーをワーカー プロセスにアタッチします。クラッシュが発生すると、ダンプ (*.DMP ファイル) が生成されます。
これは WinDBG で開くことができます (Windows 用のデバッグ ツールにも含まれています)。ファイル>クラッシュダンプを開く...
デフォルトでは、WinDBG は (コマンド ラインの横に) プロセスがクラッシュしたスレッドを表示します。
WinDBG で最初に行う必要があるのは、.NET Framework 拡張機能を読み込むことです。
.loadby sos mscorwks
次に、マネージド コールスタックを表示します。
!clrstack
スレッドがマネージ コードを実行していない場合は、ネイティブ スタックを確認する必要があります。
kpn 200
これにより、いくつかのアイデアが得られるはずです。トラブルシューティングを続けるには、次の記事を読むことをお勧めします。
A quick search found IISState - it relies on the Windows debugging tools and needs to be running when a crash occurs, but given the circumstances you've described, this shouldn't be a problem,