ASP.NET MVC アプリケーションがあります。これはドメインで実行され、 を呼び出してユーザーを決定しますUserPrincipal.Current。ほとんどの場合、これは美しく機能します。ときどき (おそらく 5 回に 1 回)、アプリを IIS に発行した直後に、AppDomainUnloadedException がスローされます。
例外を引き起こしているコードの特定の行は次のとおりです。
if (UserPrincipal.Current.SamAccountName != null &&
_currentUserId != UserPrincipal.Current.SamAccountName) ...
コール スタックの残りの部分は次のとおりです。
mscorlib.dll!System.StubHelpers.StubHelpers.GetCOMHRExceptionObject(int hr, System.IntPtr pCPCMD, object pThis) + 0xe bytes
System.DirectoryServices.AccountManagement.dll!System.DirectoryServices.AccountManagement.ADStoreCtx.LoadDomainInfo() + 0x358 bytes
System.DirectoryServices.AccountManagement.dll!System.DirectoryServices.AccountManagement.ADStoreCtx.DnsDomainName.get() + 0x5e bytes
System.DirectoryServices.AccountManagement.dll!System.DirectoryServices.AccountManagement.ADStoreCtx.GetAsPrincipal(object storeObject, object discriminant = {Name = "UserPrincipal" FullName = "System.DirectoryServices.AccountManagement.UserPrincipal"}) + 0x17a bytes
System.DirectoryServices.AccountManagement.dll!System.DirectoryServices.AccountManagement.ADStoreCtx.FindPrincipalByIdentRefHelper(System.Type principalType, string urnScheme, string urnValue, System.DateTime referenceDate, bool useSidHistory) + 0x576 bytes
System.DirectoryServices.AccountManagement.dll!System.DirectoryServices.AccountManagement.ADStoreCtx.FindPrincipalByIdentRef(System.Type principalType, string urnScheme, string urnValue, System.DateTime referenceDate) + 0x35 bytes
System.DirectoryServices.AccountManagement.dll!System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper(System.DirectoryServices.AccountManagement.PrincipalContext context, System.Type principalType, System.DirectoryServices.AccountManagement.IdentityType? identityType, string identityValue, System.DateTime refDate) + 0x9e bytes
System.DirectoryServices.AccountManagement.dll!System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithType(System.DirectoryServices.AccountManagement.PrincipalContext context, System.Type principalType, System.DirectoryServices.AccountManagement.IdentityType identityType, string identityValue) + 0x5b bytes
System.DirectoryServices.AccountManagement.dll!System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(System.DirectoryServices.AccountManagement.PrincipalContext context, System.DirectoryServices.AccountManagement.IdentityType identityType, string identityValue) + 0x1e bytes
System.DirectoryServices.AccountManagement.dll!System.DirectoryServices.AccountManagement.UserPrincipal.Current.get() + 0xc1 bytes
かなり掘り下げた後、例外のランダムな性質のために、問題はおそらくこれに関連していると結論付けました：
http://support.microsoft.com/kb/2683913
そのため、修正プログラムをインストールしたところ、予想どおり、問題は解消されました。それは火曜日でした。今朝、再び例外が発生しました。hotifx が実際にインストールされていることを確認しました。モジュールの読み込みメッセージをオンにすると、次のようになりました。
'w3wp.exe': Loaded 'C:\Windows\SysWOW64\activeds.dll', Cannot find or open the PDB file.
そのため、その .dll が実際にはホットフィックスのものであり、(サイズとバージョン番号が一致する) であることを確認しました。
この例外が発生すると同時に、イベント ログに次のイベントが記録されます。
A process serving application pool 'WebSitePool' suffered a fatal communication error with the Windows Process Activation Service. The process id was '7404'. The data field contains the error number.
エラーの唯一のデータは次のとおりです: 0x8007006D は、エラーが既に述べた致命的な通信エラーがあったことを単に意味すると信じています...
面白いことに、例外ダイアログがポップアップすると、「この例外のハンドラがある場合、プログラムは安全に続行される可能性があります」と表示されます。あなたのアプリが UserPrincipal.Current を必要としない場合、これは真実ですが、この例外の後に再度呼び出すと例外が再スローされるため、そこで「安全に継続された」という主張に疑問を投げかけます。
これで、アプリを再実行しても問題は発生しません。公開直後以外は、まだこれが発生したことはありません。私たちのセットアップと他のプロジェクトとの関係により、このアプリは IIS でデバッグする必要があります。つまり、コードを変更するたびに公開する必要があります。つまり、通常は 1 日を通してこれを確認します (火曜日の午後と昨日は例外)。 .
調べてみると、このバグは ASP.NET MVC に関連していることが多いようですが、WinForms や ASP.NET に関連しているのを見たことはないと思います... わかりませんそれがどのように問題になるかですが、そこに関係があるかもしれません。
これはMSのバグだと思います。UserPrincipal.Current が AppDomainUnloadedException を引き起こす正当な条件があるとは想像できませんが、ここで Stackoverflow を試してみようと思いました...