CustomErrors-Modus = "Aus"

Ich erhalte jedes Mal eine Fehlermeldung, wenn ich meine Webanwendung zum Anbieter hochlade. Aufgrund des customErrors-Modus wird nur die Standardmeldung "Laufzeitfehler" angezeigt, in der ich angewiesen werde, customErrors zu deaktivieren, um mehr über den Fehler anzuzeigen.

Verärgert habe ich meine web.config so eingestellt, dass sie so aussieht:

<?xml version="1.0"?>
<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>

Und trotzdem bekomme ich nur die dumme Remote-Fehlerseite ohne nützliche Informationen. Was kann ich noch tun, um customErrors auszuschalten ?!

Das hat mich in den letzten Tagen wahnsinnig gemacht und konnte es nicht umgehen, habe es aber endlich herausgefunden:

In meiner Datei machine.config hatte ich einen Eintrag unter <system.web>:

<deployment retail="true" />

Dies scheint alle anderen customError-Einstellungen zu überschreiben, die Sie in einer web.config-Datei angegeben haben. Setzen Sie den obigen Eintrag daher auf:

<deployment retail="false" />

Jetzt kann ich wieder die detaillierten Fehlermeldungen sehen, die ich brauche.

Das machine.configbefindet sich bei

32-Bit

%windir%\Microsoft.NET\Framework\[version]\config\machine.config

64-Bit

%windir%\Microsoft.NET\Framework64\[version]\config\machine.config 

Hoffe, das hilft jemandem da draußen und spart ein paar Stunden Haarziehen.

Bei "Aus" wird zwischen Groß- und Kleinschreibung unterschieden.

Überprüfen Sie, ob das "O" in Ihrer web.config-Datei in Großbuchstaben steht. Ich habe das einige Male erlitten (so einfach es klingt).

Um dieser Frage weitere Situationen hinzuzufügen (weil ich hier gesucht habe, weil ich genau das gleiche Problem hatte), ist hier meine Antwort:

In meinem Fall habe ich den Text aus dem generischen Fehler ausgeschnitten / eingefügt, der besagt, wenn Sie sehen möchten, was falsch ist

<system.web>
   <customErrors mode="Off"/>
</system.web>

Das hätte es also beheben sollen, aber natürlich nicht! Mein Problem war, dass sich mehrere Zeilen darüber (vor einem Kompilierungs- und Authentifizierungsknoten) ein <system.web> -Knoten und einige Zeilen darunter ein schließendes Tag </system.web> befand. Sobald ich dies korrigiert habe, OK, Problem gelöst. Was ich hätte tun sollen, ist nur diese Zeile zu kopieren / einzufügen:

<customErrors mode="Off"/>

Dies ist aus den Annalen von dummen Dingen, die ich immer und immer wieder mache, im Kapitel "Kopiere und füge deinen Weg zur Zerstörung ein".

Für Sharepoint 2010-Anwendungen sollten Sie auch bearbeiten C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\web.configund definieren<customErrors mode="Off" />

Ich habe die meisten der hier beschriebenen Dinge ausprobiert. Ich habe VWD verwendet und die Standarddatei web.config enthielt:

    <customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
        <error statusCode="403" redirect="NoAccess.htm" />
        <error statusCode="404" redirect="FileNotFound.htm" />
    </customErrors>

Ich habe mode = "RemoteOnly" in mode = "Off" geändert. Immer noch keine Freude. Ich habe dann IIS-Manager, Eigenschaften, Registerkarte ASP.Net, Konfiguration bearbeiten und dann die Registerkarte CustomeErrors ausgewählt. Dies zeigte immer noch RemoteOnly. Ich habe dies auf Aus geändert und endlich konnte ich die detaillierten Fehlermeldungen sehen.

Als ich die web.config inspizierte, stellte ich fest, dass sich im system.web zwei CustomErrors-Knoten befanden. und ich habe gerade bemerkt, dass der zweite Eintrag (der, den ich geändert habe, in einem Kommentar enthalten war). Versuchen Sie daher, den Editor nicht zum Überprüfen von web.config auf einem Remote-Server zu verwenden.

Wenn Sie jedoch das IIS-Bearbeitungskonfigurationsmaterial verwenden, werden Fehler in der web.config beanstandet. Dann können Sie alle Antworten ausschließen, die besagen, dass in Ihrer web.config ein XML-Syntaxfehler vorliegt.

Die einzige Antwort, die tatsächlich zur Behebung dieses Problems beigetragen hat, fand ich hier: https://stackoverflow.com/a/18938991/550975

Fügen Sie dies einfach zu Ihrem hinzu web.config:

<configuration>  
  <system.webServer>  
    <httpErrors existingResponse="PassThrough"/>  
  </system.webServer>  
<configuration>

Weitere Informationen zum Fehler finden Sie in der Regel in der Ereignisanzeige, wenn Sie Zugriff darauf haben. Möglicherweise hat Ihr Provider auch verhindert, dass benutzerdefinierte Fehler überhaupt angezeigt werden, indem er sie entweder in der Datei machine.config überschreibt oder das Retail-Attribut auf true setzt ( http://msdn.microsoft.com/en-us/library/ms228298 (). VS.80) .aspx ).

Ich hatte auch dieses Problem, aber bei Verwendung von Apache und mod_mono. Für alle anderen in dieser Situation müssen Sie Apache nach dem Ändern von web.config neu starten, um das Lesen der neuen Version zu erzwingen.

Wenn Sie diese Seite immer noch erhalten, ist es wahrscheinlich, dass sie explodiert, bevor Sie an Web.Config vorbeikommen

Stellen Sie sicher, dass ASP.Net über die erforderlichen Berechtigungen für die .NET Framework-Ordner, die IIS-Metabasis usw. verfügt. Können Sie überprüfen, ob ASP.Net korrekt installiert und in IIS korrekt zugeordnet ist?

Bearbeiten: Nach Gregs Kommentar ist mir aufgefallen, dass ich angenommen habe, dass das, was Sie gepostet haben, Ihre gesamte sehr minimale web.config ist. Gibt es mehr dahinter? Wenn ja, können Sie die gesamte web.config posten?

Mein Problem war, dass ich dies in meiner web.config definiert hatte

<httpErrors errorMode="Custom" existingResponse="Replace">
  <remove statusCode="404" />
  <remove statusCode="500" />
  <error statusCode="404" responseMode="ExecuteURL" path="/Error/NotFound" />
  <error statusCode="500" responseMode="ExecuteURL" path="/Error/Internal" />
</httpErrors>

Beim Hosting meiner Web-App habe ich herausgefunden, dass der Code, den Sie auf Ihrem lokalen Computer entwickelt haben, eine höhere Version hat, als das Hosting-Unternehmen Ihnen anbietet. Wenn Sie über Administratorrechte verfügen, können Sie möglicherweise die Unterstützung der Microsoft ASP.NET-Version unter den Webhosting-Einstellungen ändern

Wir hatten dieses Problem und es lag daran, dass der IIS-Benutzer keinen Zugriff auf die Computerkonfiguration auf dem Webserver hatte.

Wir sind auch auf diesen Fehler gestoßen, und in unserem Fall lag dies daran, dass der Benutzer des Anwendungspools keine Berechtigungen mehr für die Datei web.config hatte. Der Grund, warum es seine Berechtigungen verloren hat (vorher war alles in Ordnung), war, dass wir eine Sicherungskopie der Site in einer rar-Datei hatten und ich eine Sicherungsversion der web.config von der rar in die Site gezogen habe. Dies scheint alle Berechtigungen für die Datei web.config außer mir, dem angemeldeten Benutzer, entfernt zu haben.

Wir haben eine Weile gebraucht, um dies herauszufinden, da ich die Berechtigungen auf Ordnerebene wiederholt überprüft habe, jedoch nie auf Dateiebene.

Ich hatte das gleiche Problem, fand aber eine andere Lösung.

- -

Ich habe die erweiterten Einstellungen für den Anwendungspool in IIS Manager geöffnet .

Dort habe ich 32-Bit-Anwendungen aktivieren auf True gesetzt .

Starten Sie die Anwendung neu (das Erstellen einer app_offline.htm reicht dann aus, wenn Sie sie löschen). Wenn immer noch dieselbe Fehlermeldung angezeigt wird, stellen Sie sicher, dass Sie customErrors nur einmal in der web.config deklariert haben. Fehler in der web.config können seltsame Auswirkungen auf die Anwendung haben.

Haben Sie einen besonderen Charakter wie æøå in Ihrer web.config? Wenn ja, stellen Sie sicher, dass die Codierung auf utf-8 eingestellt ist.

Ist diese Web-App unter anderen Apps im Verzeichnisbaum einer Website festgelegt? Überprüfen Sie alle übergeordneten web.config-Dateien auf andere Einstellungen, falls vorhanden. Stellen Sie außerdem sicher, dass Ihr Verzeichnis in IIS als Anwendungsverzeichnis festgelegt ist.

Wenn Sie die MVC-Vorschau 4 verwenden, tritt dies möglicherweise auf, weil Sie das HandleErrorAttribute verwenden. Das Verhalten wurde in 5 geändert, sodass keine Ausnahmen behandelt werden, wenn Sie benutzerdefinierte Fehler deaktivieren.

Sie können auch versuchen, die Website in einem Browser auf dem Server aufzurufen. Ich mache nicht viel ASP.NET-Entwicklung, aber ich erinnere mich, dass die Sache mit benutzerdefinierten Fehlern aus Sicherheitsgründen nur den vollständigen Fehlertext auf dem Server anzeigt.

Ich habe mich gerade mit einem ähnlichen Thema befasst. In meinem Fall war die Standardversion von asp.net 1.1, als ich versuchte, eine 2.0-Web-App zu starten. Der Fehler war ziemlich trivial, aber es war nicht sofort klar, warum die benutzerdefinierten Fehler nicht verschwinden würden, und die Laufzeit schrieb nie in das Ereignisprotokoll. Offensichtliche Korrektur bestand darin, mit der Version auf der Registerkarte Asp.Net von IIS übereinzustimmen.

Stellen Sie außerdem sicher, dass Sie web.config und nicht website.config bearbeiten, wie ich es getan habe.

Ich hatte das gleiche Problem und die Ursache war, dass auf IIS ASP.NET 1.1 ausgeführt wurde und für die Site .NET 2.0 erforderlich war.

Die Fehlermeldung hat mich nur für einige Stunden aus der Bahn geworfen.

Stellen Sie sicher, dass Sie direkt nach dem system.web hinzufügen

Ich habe es gegen Ende des Knotens platziert und nicht funktioniert.

Wenn Sie eine Konfigurationstransformation durchführen, müssen Sie möglicherweise auch die folgende Zeile aus der entsprechenden Datei web.config entfernen.

<compilation xdt:Transform="RemoveAttributes(debug)" />

Nachdem ich alle Antworten hier ausprobiert hatte, stellte sich heraus, dass meine Application_ErrorMethode Folgendes hatte:

Server.ClearError();
Response.Redirect("/Home/Error");

Durch Entfernen dieser Zeilen und Einstellen wurde das Problem behoben. (Der Client wurde immer noch mit auf die Fehlerseite umgeleitet customErrors="On").

Ich hatte das gleiche Problem und habe das Anwendungsprotokoll der Ereignisanzeige durchgesehen, in dem klar angegeben ist, aufgrund welcher Ausnahme dies passiert ist. In meinem Fall war die Ausnahme wie folgt ...

Ausnahmeinformationen:

Exception type: HttpException 
Exception message: The target principal name is incorrect.  Cannot generate SSPI context.
at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app)
at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)

The target principal name is incorrect.  Cannot generate SSPI context.

Ich habe gerade mein Passwort im Anwendungspool aktualisiert und es funktioniert für mich.

In einigen Fällen ist es auch möglich, dass web.config nicht richtig formatiert ist. In diesem Fall müssen Sie es Zeile für Zeile durchgehen, bevor es funktioniert. Oft sind hier Umschreiberegeln der Schuldige.

Das ist wirklich seltsam. Ich habe diesen Fehler erhalten und nach dem Neustart meines Servers ist er verschwunden.

Für mich war es ein Fehler weiter oben in der web.config über dem system.web.

Die Datei blah war nicht vorhanden, daher wurde zu diesem Zeitpunkt ein Fehler ausgegeben. Da es noch nicht im Abschnitt System.Web angekommen war, wurde die Server-Standardeinstellung für CUstomErrors (Ein) verwendet.