2016-06-30 8 views
2

haben wir mit Asynchron/erwarten in asp.net Anwendung gestartet, jetzt sind wir die berühmte Ausnahme in unserer Produktion beendetAsync/erwarten wirft NullReferenceException Wie können wir diagnostizieren, wo wir es vermasselt haben?

Eine nicht behandelte Ausnahme aufgetreten ist, und der Prozess wurde immer.

Anwendungs-ID:/LM/W3SVC/376/ROOT

Prozess-ID: 3796

Ausnahme: System.NullReferenceException

Nachricht: Der Objektverweis auf eine Instanz eines Objekts nicht gesetzt.

Stacktrace: at System.Web.ThreadContext.AssociateWithCurrentThread (Boolean setImpersonationContext) bei System.Web.HttpApplication.OnThreadEnterPrivate (Boolean setImpersonationContext) bei System.Web.LegacyAspNetSynchronizationContext.CallCallbackPossiblyUnderLock (SendOrPostCallback Rückruf, Objektzustand at) System.Web.LegacyAspNetSynchronizationContext.CallCallback (SendOrPostCallback Rückruf, Objektzustand) bei System.Threading.Tasks.AwaitTaskContinuation.RunCallback (Context Rückruf, Objektzustand, Aufgabe & currentTa sk) --- Ende der Stack-Trace aus früheren Stelle, wo Ausnahme ausgelöst wurde --- bei System.Threading.Tasks.AwaitTaskContinuation.b__1 (Object s) bei System.Threading.ExecutionContext.RunInternal (ExecutionContext ExecutionContext, Contextcallback, Objektzustand, Boolean preserveSyncCtx) bei System.Threading.ExecutionContext.Run (ExecutionContext ExecutionContext, Contextcallback, Objektzustand, Boolean preserveSyncCtx) bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () bei System.Threading.ThreadPoolWorkQueue.Dispatch()

Gibt es eine Möglichkeit, mehr Informationen über den Code/die Aufgabe zu erhalten, die das Problem verursacht?

Zweite Frage: wir haben versucht, die Ausnahme vor Ort in einer einfachen Test webform Anwendung

 protected void Page_Load(object sender, EventArgs e) 
    { 
     LogMessageToFile("before_task"); 
     var t = Test(); 

     tasks.Add(t); 
    } 
    async Task Test() 
    { 
     await Task.Run(() => 
     { 
      LogMessageToFile("inside_task"); 
      Thread.Sleep(1000); 
     } 
      ); 
     this.Title = "test"; 
     LogMessageToFile("after_task"); 

     // throw new Exception(""); 
    } 

zu reproduzieren, aber wir nie die Ausnahme in unserer Testseite bekommen scheint, dass der Code nach dem in Testfunktion erwartet nie aufgerufen und Der Aufgabenstatus lautet WaitingForActivation. Warum erhalten wir in diesem Code keine Ausnahme?

+0

versuchen catch block araound warten? – Legends

+0

'this.Title =" test ";' kann null sein, wenn die Seite verschwunden ist und Sie nicht darauf achten, ... bevor die Seite gelöscht wird. – Aristos

Antwort

4

Der Legacy-Typ (LegacyAspNetSynchronizationContext) in Ihrer Aufrufliste zeigt an, dass Ihre web.config settings nicht korrekt ist. Stellen Sie auf 4.5 oder höher ein.

async/await verursachen undefiniertes Verhalten in früheren Versionen von ASP.NET.

Warum erhalten wir keine Ausnahme in diesem Code?

Da Sie wahrscheinlich zu 4.5+ die unterbrochene Anwendung aktualisiert (die auf „Quirks-Modus“ gedreht, await unbrauchbar macht), sondern erstellt eine neue Testanwendung für 4.5+ (die „Quirks-Modus schaltet sich aus ", so dass await funktioniert).

+1

danke Stephan, das wirklich geholfen hat, ich habe die web.config doppelt überprüft, wir hatten in der Produktion, aber nicht Mojtaba

+0

In Bezug auf den Beispielcode In der Frage können wir sagen, wenn wir alte config verwenden, um den Code nach warten auszuführen (this.Title = "test"; LogMessageToFile ("after_task");) task will sich wieder mit dem Hauptkontext verbinden und Exception auslösen (bcz it existiert nicht) aber mit der neuen Konfiguration wird die Aufgabe aufgegeben, ohne zu beenden und wieder zu verbinden und Code wird nie nie aufgerufen werden? was bedeutet, dass wir vielleicht noch einen Fehler in unserem Code haben, dass wir nicht darauf gewartet haben, dass eine Aufgabe beendet wird, damit der Code nie aufgerufen wird. Mit der alten Konfiguration erhalten wir einen Fehler, aber mit der neuen Konfiguration erhalten wir keinen Fehler. – Mojtaba

+1

@Mojtaba: Ich sehe zwei Probleme mit dem Beispielcode. 1) Aufgaben sollten schließlich "erwartet" werden, und 2) "Task.Run" ist nicht für ASP.NET-Anwendungen geeignet. –

Verwandte Themen