Thread.Abort dans l’application ASP.NET provoque le blocage de w3wp.exe

Ne définissez pas d’indicateur de doublon sur cette question – il ne s’agit pas de “pourquoi ThreadAbortException se produit”, il s’agit de “pourquoi le processus w3wp.exe se termine après ThreadAbortException”.

Disons que nous avons une application Web simple avec l’exemple de code suivant:

protected void Page_Load(object sender, EventArgs e) { Response.Redirect("http://google.com"); } 

Qui signifie en réalité quelque chose comme (voir Response.End () est-il considéré comme dangereux? ):

 protected void Page_Load(object sender, EventArgs e) { ...response write some data... System.Threading.Thread.CurrentThread.Abort(); } 

Sur mon ordinateur (Windows 10 Pro + IIS), ce code entraîne la terminaison du processus de pool IIS avec le code d’erreur 0x0 (la redirection n’est pas effectuée). Sur d’autres machines (ce qui n’est pas Windows 10), ce code ne génère qu’une exception ThreadAborted, mais le processus continue de fonctionner (la redirection est exécutée).

Quelqu’un peut-il vérifier cet échantillon et expliquer ce qui se passe?

UPDATE Voici quelques journaux d’événements Windows liés à ce problème.

log n ° 1

Une exception non gérée s’est produite et le processus a été arrêté.

ID de l’application: / LM / W3SVC / 1 / ROOT / AS

ID de processus: 6700

Exception: System.Threading.ThreadAbortException

Message: le fil était en cours d’abandon.

StackTrace: chez System.Web.HttpRemorest (IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32)

log n ° 2

 Faulting application name: w3wp.exe, version: 10.0.10240.16384, time stamp: 0x559f3dad Faulting module name: KERNELBASE.dll, version: 10.0.10240.16384, time stamp: 0x559f3b2a Exception code: 0xe0434352 Fault offset: 0x000b3e28 Faulting process id: 0x1a2c Faulting application start time: 0x01d0e4b1b3ed01cb Faulting application path: C:\WINDOWS\SysWOW64\inetsrv\w3wp.exe Faulting module path: C:\WINDOWS\SYSTEM32\KERNELBASE.dll Report Id: 23b5298d-3b36-49c7-a294-de9c864b703f Faulting package full name: Faulting package-relative application ID: 

J’ai pu reproduire le problème sur Server 2008r2 avec .NET 4.6 installé.

Je soupçonne que c’est le même problème que le rest d’entre vous rencontrez; ThreadAbortExceptions détruisant le pool d’applications dans le journal des événements (bien que toute exception non gérée causerait le problème dans mon cas; mais il peut s’agir simplement d’un gestionnaire d’exception global l’attrapant et se terminant par un Response.End ou une redirection). La stack de vidage correspond également à celle de la réponse de Ian.

Un ticket MS Connect a été ouvert pour le problème et un correctif récent de la base de connaissances résout le problème pour moi.

Article Connect: https://connect.microsoft.com/VisualStudio/feedback/details/1605438/disabling-ryujit-breaks-asp-net

Correctif KB: https://support.microsoft.com/en-us/kb/3098786

Jusqu’à présent, j’ai la seule solution:

  static class WebExtensions { public static void EndSafe(this HttpResponse response) { response.Flush(); response.SuppressContent = true; HttpContext.Current.ApplicationInstance.CompleteRequest(); } public static void RedirectSafe(this HttpResponse response, ssortingng url) { response.Redirect(url, false); HttpContext.Current.ApplicationInstance.CompleteRequest(); } } 

Ceci me force cependant à m’assurer qu’il n’y aura pas de code exécuté après:

 ...some code response.RedirectSafe(url); return; //<-- important ...some more code 

Faites attention, dans certains cas, seul le "retour" ne suffit pas (par exemple, avec des appels récursifs) et dans certains cas, vous devrez peut-être éviter d'utiliser le "retour" (avec des constructions try-finally).

J’ai rencontré ce même problème exactement sur Windows 8.1 aujourd’hui, après avoir redémarré pour installer Windows Updates.

Le problème était que j’avais manuellement désactivé RyuJIT dans le registre en raison de l’ useLegacyJit DWORD useLegacyJit et en le réglant sur 1 (voir Méthode n ° 3 ). Mais l’une des mises à jour a créé la clé UseRyuJIT au même emplacement et l’a également définie sur 1, ce qui a apparemment confondu ASP.NET de manière horrible.

La solution consistait à définir useLegacyJit sur 0 et à émettre un iisreset . Après cela, tout va bien dans le monde.

WinDbg !clrstack montré les frameworks suivants lorsque j’ai débogué le dump w3wp.exe . Cela aidera peut-être d’autres personnes avec la même erreur qui cherchent une solution sur Google:

 000000ef9892be98 00007ffa0e2d1fea [HelperMethodFrame: 000000ef9892be98] 000000ef9892bf80 00007ff99d776588 System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32) 000000ef9892df90 00007ff9fc172345 [FaultingExceptionFrame: 000000ef9892df90] 000000ef9892e490 00007ff99d7796c0 System.Web.HttpRuntime.ProcessRequestNotificationPrivate(System.Web.Hosting.IIS7WorkerRequest, System.Web.HttpContext) 000000ef9892e520 00007ff99d777377 System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr, IntPtr, IntPtr, Int32) 000000ef9892e700 00007ff99d77655a System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32) 000000ef9892e740 00007ff99d775c11 DomainNeutralILStubClass.IL_STUB_ReversePInvoke(Int64, Int64, Int64, Int32) 000000ef9892ef58 00007ff9fc100b4e [InlinedCallFrame: 000000ef9892ef58] System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr, System.Web.RequestNotificationStatus ByRef) 000000ef9892ef58 00007ff99d78cc1b [InlinedCallFrame: 000000ef9892ef58] System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr, System.Web.RequestNotificationStatus ByRef) 000000ef9892ef30 00007ff99d78cc1b DomainNeutralILStubClass.IL_STUB_PInvoke 000000ef9892f000 00007ff99d77756c System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr, IntPtr, IntPtr, Int32) 000000ef9892f1e0 00007ff99d77655a System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32) 000000ef9892f220 00007ff99d775c11 DomainNeutralILStubClass.IL_STUB_ReversePInvoke(Int64, Int64, Int64, Int32) 000000ef9892f418 00007ff9fc100da3 [ContextTransitionFrame: 000000ef9892f418] 

J’ai rencontré le même problème sur Win7 SP1. Application Web compilée ciblant .net 4.5.2 et s’exécutant sur .net 4.6. Et je ne me suis pas amusé avec les drapeaux de registre useLegacyJit ou useRyuJIT.

“Activer les applications 32 bits” s’est avéré inutilement activé sur mon domaine d’application. Le désactiver a résolu le problème.