System.UnauthorizedAccessException dans mscorwks.dll provoquant des plantages d'applications

Question

Mes pools d'applications se bloquent de manière aléatoire dans IIS 6.0 MS Debug Diag pointe sur kernel32.dll à chaque fois.

Le point d'entrée est toujours mscorwks! CreateApplicationContext + bbef et le résultat est toujours une exception System.UnauthorizedAccessException.

Stack Trace:

Function          Arg 1  Arg 2  Arg 3 
kernel32!RaiseException+3c      e0434f4d  00000001  00000001  
mscorwks!GetMetaDataInternalInterface+84a9  18316b3c  00000000  00000000  
mscorwks!GetAddrOfContractShutoffFlag+ac01  18316b3c  00000000  023cfbd8  
mscorwks!GetAddrOfContractShutoffFlag+ac73  00000000  000e8c88  8038b2d0  
mscorwks!GetAddrOfContractShutoffFlag+aca4  18316b3c  00000000  023cfbe4  
mscorwks!GetAddrOfContractShutoffFlag+acb2  18316b3c  acc05c33  7a399bf0  
mscorwks!CoUninitializeCor+67be    00000000  023cfc1c  023cfc8c  
mscorwks!CoUninitializeCor+87a1    001056e8  79fd87f6  023cfeb0  
mscorwks!CorExitProcess+4ad3     023cfeb0  023cfd20  79f40574  
mscorwks!CorExitProcess+4abf     001056e8  79f405a6  023cfd04  
mscorwks!CorExitProcess+4b3e     000e8c88  00000000  023cfda7  
mscorwks!StrongNameErrorInfo+1ddab    00000000  00000000  023cfeb0  
mscorwks!StrongNameErrorInfo+1e07c    023cfeb0  00000000  00000000  
mscorwks!CoUninitializeEE+4e0b     023cfeb0  023cfe5c  79f7762b  
mscorwks!CoUninitializeEE+4da7     023cfeb0  acc05973  00000000  
mscorwks!CoUninitializeEE+4ccd     023cfeb0  00000000  001056e8  
mscorwks!GetPrivateContextsPerfCounters+f1cd 79fc24f9  00000008  023cff14  
mscorwks!GetPrivateContextsPerfCounters+f1de 79fc24f9  acc058c3  00000000  
mscorwks!CorExeMain+1374      00000000  00000003  00000002  
mscorwks!CreateApplicationContext+bc35   000e9458  00000000  00000000  
kernel32!GetModuleHandleA+df     79f9205f  000e9458  00000000 

Quelqu'un sait-il ce que cela signifie et comment y remédier?

Editer: La trace de pile ci-dessus s'est révélée être un symptôme et non la cause. La trace de pile ci-dessus affiche uniquement la pile non gérée mais le problème s'est produit dans le code managé. J'ai utilisé les étapes dans ma réponse ci-dessous pour creuser dans le vidage sur incident et extraire l'exception gérée.

Answer 1

La référence à mscorwks.dll était seulement un symptôme du problème. mscorwks.dll est la DLL contenant le Common Language Runtime.

Pour diagnostiquer la cause du problème, j'ai suivi les étapes suivantes:

1. Utilisez DebugDiag pour capturer un vidage sur incident lorsque IIS recycle le pool d'application.
2. Ouvrez le vidage sur incident dans windbg.
3. type « .loadby sos mscorwks » (sans guillemets) à la ligne de commande windbg pour charger les outils de débogage CLR
4. Utilisez la commande PrintException! Pour imprimer la dernière exception enregistrée dans la décharge de l'accident. Ceci est probablement celui qui a causé l'application IIS piscine recyclage
5. Utilisez la commande! Clrstack pour voir la pile sur le fil courant qui a jeté l'exception
6. autres références de commande pour windbg se trouvent here et here. Enfin, this MSDN blog a d'excellents tutoriels sur l'utilisation de windbg.

Bonne chance pour votre aventure de débogage!

Answer 2

Ryan, Je sais que le comportement de l'exception non gérée a changé. à partir de NET Framework 1.0 ou 1.1, les exceptions non gérées ont été ignorées. 2.x et versions ultérieures, les exceptions non gérées planteront le processus de travail (pool d'applications). Ajouter ce qui suit à votre web.config de l'avoir ignoré (mais vous devriez savoir pourquoi son plantage!)

<configuration> 
<runtime> 
<legacyUnhandledExceptionPolicy enabled="true" /> 
</runtime> 
</configuration> 

Cela pourrait faire l'affaire. . .

Answer 3

Vos symboles sont brisés - réparez-les et vous obtiendrez probablement une pile d'appels plus significative