Wie diagnostiziere ich einen 500 Internal Server Error unter IIS 7.5, wenn nichts in das Ereignisprotokoll geschrieben wird?

43

Ich habe gerade ein Update für eine vorhandene ASP.NET MVC3-Site bereitgestellt (diese wurde bereits konfiguriert) und erhalte den IIS-Bluescreen mit der Todesanzeige

HTTP-Fehler 500.0 - Interner Serverfehler
Die Seite kann nicht angezeigt werden, da ein interner Serverfehler aufgetreten ist.

Jedoch; Im Anwendungsereignisprotokoll wird nichts angezeigt, von dem ich eine (detailliertere) Beschreibung des Eintrags erwarte.

Wie kann ich dieses Problem diagnostizieren?

— Greg B
quelle

Ich hatte genau das gleiche Problem hier. Wenn das Ereignisprotokoll leer ist, wurde die Anforderung meines Erachtens nicht ordnungsgemäß an den Arbeitsprozess weitergeleitet. In einer unserer letzten Bereitstellungen hat die App zeitweise funktioniert, wobei etwa 50% der Anforderungen mit dem 500-Fehler zufällig fehlgeschlagen sind und nichts in den Protokollen enthalten ist. Ich vermute, dass beim Entladen von AppDomain nach der Bereitstellung etwas schief läuft. Führen Sie aus Neugier Antivirus in Ihrer Produktionsumgebung aus? Behebt ein IIS-Reset das Problem (bis zur nächsten Bereitstellung)?

— ShadowChaser

41

Werfen Sie einen Blick auf die Funktion zur Verfolgung fehlgeschlagener Anforderungen in IIS7:

Problembehandlung bei fehlgeschlagenen Anforderungen mithilfe der Ablaufverfolgung in IIS 7
Problembehandlung bei fehlgeschlagenen Anforderungen

Die andere Sache, die ich tun würde, ist, Ihre <httpErrors>Einstellung zu ändern , weil IIS möglicherweise eine Fehlermeldung von weiter oben in der Pipeline verschluckt:

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

Wenn die Site in klassischem ASP geschrieben ist, müssen Sie die Einstellung Fehler an Browser senden in der ASP-Konfigurationsfunktion aktivieren:

Bildbeschreibung hier eingeben

Wenn Sie den Internet Explorer verwenden, stellen Sie sicher, dass die Option "Anzeigen von HTTP-Fehlermeldungen" in den erweiterten Einstellungen deaktiviert ist (obwohl ich vermute, dass Sie dies bereits getan haben oder einen anderen Browser verwenden).

— Kev
quelle

2

existingResponse wurde auf Replace gesetzt. Danke für den Tipp.

— Greg B

Dies ist eine sehr gute Antwort, die jedoch verbessert werden könnte, wenn darin enthalten wäre, wie das ASP-Konfigurationsfenster gestartet wird.

— Michael Potter

13

In meinem Fall:

Das Ereignisprotokoll war leer.
web.config war nicht beschädigt - überprüft durch Verwendung derselben auf dem lokalen Computer / using inetmgr

Endlich...

Beim Überprüfen der IIS-Protokolle wurde eine solche Anforderung angezeigt

...Chrome/57.0.2987.133+Safari/537.36 500 19 5 312

Der Schlüssel ist:

sc-status sc-substatus sc-win32-status 500 19 5

was mich mit einigem googeln darauf hinwies, dass ich IIS_USRSkeine leserechte für den wwwordner hatte

— fiat
quelle

2

Ich habe die Liste der Statuscodes hier gefunden: support.microsoft.com/en-us/help/943891/…

— sirdank

4

Das offensichtlichste Problem sind falsche oder keine NTFS-Rechte für den Webanwendungsordner. Stellen Sie also sicher, dass das Konto, das die Site bedient, über die richtigen Berechtigungen verfügt. Ohne die richtigen NTFS-Rechte für das Webverzeichnis spielt es keine Rolle, was Sie in der web.config ablegen, da es niemals gelesen wird.

Eine schnelle Überprüfung kann darin bestehen, jedem die vollständigen Rechte zu erteilen. Wenn die Site zu funktionieren beginnt, wissen Sie, dass es sich um ein Rechteproblem handelt, und können dann festlegen, ob einem geeigneteren Konto die entsprechenden Rechte zugewiesen werden sollen.

— Risma
quelle

1

Wenn Sie ein Upgrade von IIS6 durchführen, funktioniert möglicherweise eine der web.config-Dateien in 6, jedoch nicht in IIS 7.5. Doppelklicken Sie auf alle Symbole in IIS für die Website, und möglicherweise wird eine Fehlermeldung zum Format (Abschnitt 6) angezeigt muss unter anderem Abschnitt sein ...)

— M Hall
quelle

0

Ich hatte das gleiche Problem mit einer Azure Web App. Beim lokalen Debuggen wurden Fehlermeldungen (JSON), die von Ajax-Aufrufen zurückgegeben wurden, vollständig an den Browser zurückgegeben. Nach der Bereitstellung in der Webanwendung wurden die Nachrichten jedoch verschluckt, und es wurde eine Standardfehlermeldung von 500 zurückgegeben. Also musste ich den existingResponseWert PassThroughim httpErrorsTag web.config explizit auf setzen .

— Loul G.
quelle