Vorsicht bei „Debug.Assert“-Aufrufen in ASP.NET (2.0)-Webanwendungen!

Über vier Manntage hat mich insgesamt das folgende (in meinen Augen falsche) Verhalten von ASP.NET gekostet.

Beschreibung

  • Eine ASP.NET 2.0-Webanwendung läuft in der Testumgebung ganz normal und auch im Echtbetrieb.
  • Zu nicht-vorhersehbaren Zeiten „hängt“ die Anwendung auf einmal. D.h. die Anwendung reagiert für den Benutzer einfach nicht und der Browser lädt ewig.
  • Wenn ich dann den entsprechenden „w3wp.exe“ kille (ich habe extra einen AppPool nur für die eine Webanwendung gemacht), dann wird sofort automatisch ein neuer w3wp.exe gestartet und die Anwendung läuft wieder normal.

Ursache

Ein Aufruf von Debug.Assert in einer von der Webanwendung verwendeten DLL hat den Prozess zum Hängen gebracht.

  • Debug.Assert direkt in einer
    Webanwendung ausgeführt hält den „w3wp.exe“ nicht an, sondern wird
    schlicht ignoriert.
  • Debug.Assert indirekt
    in einer DLL, die von der Webanwendung verwendet wird, hält den
    w3wp.exe an und kann nur durch killen des „w3wp.exe“ beendet werden.

Lösung

Als schnellen Workaround habe ich jetzt alle Debug.Assert-Aufrufe in der DLL auskommentiert. Natürlich könnt Ihr auch schlicht alles im Release-Modus kompilieren, das ist aber in meinem Fall nicht nötig gewesen (keine Performance-Verbesserungen).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.