Błąd nie jest zalogowany z Application_Error

Question

Mam aplikacji Asp.Net 4.0 Web Forms że rzuca następujący błąd pewne razy

„Server Error in«/»Application MySiteDev”.

Ten błąd pojawia się tylko czasami. Ten błąd nie wywołuje zdarzenia Application_Error, które jest obsługiwane w Global.asax.

Ponieważ to nie jest uruchamianie Application_Error, jakie są inne możliwe miejsca, które będą miały dziennik tego zdarzenia błędu? Czy jest coś innego niż przeglądarka zdarzeń?

W jaki sposób można znaleźć wyjątki obsługiwane przez środowisko ASP.Net?

Uwaga: customErrors mode="Off". Również runAllManagedModulesForAllRequests="true"

UPDATE

referencyjny od How to: Handle Application-Level Errors

procedurę obsługi błędu, który jest zdefiniowany w pliku Global.asax złapie tylko błędy występujące podczas przetwarzania żądania przez program ASP.NET . Na przykład złapie błąd, jeśli użytkownik zażąda pliku .aspx, który nie występuje w Twojej aplikacji. Jednak nie przechwytuje błędu, jeśli użytkownik zażąda nieistniejącego pliku .htm. W przypadku błędów innych niż .NET. Można utworzyć niestandardową procedurę obsługi w Internetowych usługach informacyjnych (IIS). Niestandardowy moduł obsługi nie będzie również wywoływany w przypadku błędów na poziomie serwera.

Nie można bezpośrednio wyprowadzać informacji o błędach dla żądań z pliku Global.asax; musisz przenieść kontrolę na inną stronę, zazwyczaj stronę formularzy internetowych. Przenosząc kontrolę na inną stronę, użyj metody Transfer. Zachowuje to bieżący kontekst, dzięki czemu można uzyskać informacje o błędzie z metody GetLastError.

Po usunięciu błędu należy go usunąć, wywołując metodę ClearError obiektu serwera (klasa HttpServerUtility).

KOD

protected void Application_Error(object sender, EventArgs e) 
    { 
     //Get the exception object 
     Exception exception = Server.GetLastError().GetBaseException(); 

     //Get the location of the exception 
     string location = Request.Url.ToString(); 
     if (!String.IsNullOrEmpty(location)) 
     { 
      string[] partsOfLocation = location.Split('/'); 
      if (partsOfLocation != null) 
      { 
       if (partsOfLocation.Length > 0) 
       { 
        location = partsOfLocation[partsOfLocation.Length - 1]; 
       } 
      } 

      //Maximum allowed length for location is 255 
      if (location.Length > 255) 
      { 
       location = location.Substring(0, 254); 
      } 
     } 

     string connectionString = ConfigurationManager.ConnectionStrings[UIConstants.PayrollSQLConnection].ConnectionString; 
     ExceptionBL exceptionBL = new ExceptionBL(connectionString); 

     exceptionBL.SubmitException(exception.Message, location); 
     Log.Logger.Error(exception.Message); 

    } 

KONFIGURACJA

<system.web> 

<compilation debug="true" targetFramework="4.0" /> 
<pages validateRequest="false"></pages> 
<httpRuntime requestValidationMode="2.0" /> 
<customErrors mode="Off"/> 
<authentication mode="Windows"></authentication> 
<identity impersonate="true" userName="domain\xxxx" password="xxxx"/> 

</system.web> 

<system.webServer> 
<modules runAllManagedModulesForAllRequests="true"/> 
<httpErrors errorMode="Detailed" /> 
</system.webServer> 

AKTUALIZACJA ODNOŚNIKI

1. Application_Error not firing
2. Global.asax event Application_Error is not firing
3. Application_Error does not fire?
4. How to: Handle Application-Level Errors

Answer 1

To jest środowisko load balanced z polami A i B.

Zespół, który wdrożył aplikację internetową, potwierdził, że w jednym z pól plik konfiguracyjny nie został poprawnie skopiowany.

Myślę, że aplikacja działała dobrze, gdy uderzała w skrzynkę i nie działała w polu B. Myślę, że ponieważ nie ma tam konfiguracji, nie można było zadzwonić pod numer Application_Error.

Proszę powiedzieć, czy masz inne zdanie.

Uwaga: problemu nie ma po ponownym wdrożeniu

Answer 2

Zbadaj dzienniki w Podglądzie zdarzeń, które powinny się zalogować zarówno na poziomie serwera i na poziomie aplikacji błędów.

Prawdopodobnie program obsługi błędu aplikacji nie przetwarza zdarzenia, ponieważ dzieje się to przed uruchomieniem aplikacji i utworzeniem kontekstu. Tak więc wydaje się, że konfiguracja aplikacji lub konfiguracja serwera przestaje przetwarzać żądanie.

Albo aplikacja napotyka problem wystarczająco wcześnie w cyklu życia żądania, że ​​nawet po uruchomieniu, jest "zawieszony", dopóki serwer nie zdecyduje się zabić procesu (na przykład, może w formie wyjątku StackOverflowException wspomnianego przez @MikeSmithDev).