Analyse und Lösungen für die Ursachen des von IIS7 gemeldeten Fehlers 500.23

Hintergrund: Heute gab es eine Funktionsöffnungsausnahme auf dem Terminal des Unternehmens, die einen 500-Fehler meldete. Ich habe Fiddler verwendet, um den Link zu finden, und ihn dann im IE geöffnet, wobei ein 500.23-Fehler gemeldet wurde: ASP.NET ist im integrierten nicht anwendbar Der Hosting-Pipeline-Modus wurde erkannt. Der Hintergrund ist eine in IIS7 und Tomcat7 integrierte Umgebung, die hier aufgezeichnet wird.

HTTP-Fehler 500.23 – Interner Serverfehler

Eine ASP.NET-Einstellung, die im integrierten verwalteten Pipeline-Modus nicht anwendbar ist, wurde erkannt.

Warum treten die oben genannten Fehler auf?

Der Anwendungspool in IIS7 verfügt über zwei Modi: einen „integrierten Modus“ und einen „klassischen Modus“.

Der klassische Modus ist die IIS 6-Methode, die wir gewohnt sind.

Wenn Sie den integrierten Modus verwenden, müssen Sie die Konfigurationsdatei für benutzerdefinierte httpModules und httpHandler ändern und diese in die Abschnitte übertragen.

Zwei Lösungen:

Die erste Methode besteht darin, den Anwendungspool zu konfigurieren

Konfigurieren Sie den Anwendungspool auf IIS7 und ändern Sie den Modus des Anwendungspools auf „Klassisch“ ” und Danach lief alles gut. Wie im Bild gezeigt:

IIS7, versuchen wir die folgenden Lösungen:

Die zweite Methode besteht darin, die Konfigurationsdatei web.config zu ändern:

Hinweis: web.config-Pfad C:inetpubwwwrootweb.config

Zum Beispiel die ursprünglichen Einstellungen (möglicherweise verfügen Sie nicht über httpModules- und httpHandlers-Knoten in Ihrer Umgebung)

<system.web>
............
<httpModules>
<add name="MyModule"type="MyApp.MyModule" />
</httpModules>
<httpHandlers>
<add path="*.myh"verb="GET"type="MyApp.MyHandler" />
</httpHandlers>
</system.web>

Wann Der IIS7-Anwendungspool befindet sich im „Integrierten Modus“, ändern Sie zu:

<system.web>
...........
</system.web>
<system.webServer>
<modules>
<add name="MyModule"type="MyApp.MyModule" /> 
</modules>
<handlers>
<add name="MyHandler"path="*.myh"verb="GET"type="MyApp.MyHandler"preCondition="integratedMode" />
</handlers>
</system.webServer>

(wenn Ihre web.config keine httpModules- oder httpHandlers-Knoten hat, fügen Sie direkt zum Knoten system.webServer hinzu:

<validation validateIntegratedModeConfiguration="false" />

Überprüfung des integrierten Modus deaktivieren, um Fehler zu vermeiden

Speicherort des IIS-Protokolls
Das Protokoll von IIS 6.0 wird gespeichert in:
c:windowssystem32logfiles

Das Protokoll von IIS 7 wird gespeichert in:
%SystemDrive%inetpublogsLogFiles

Nach meinem Test werden IIS-Protokolle sofort geschrieben und erfordern keinen IIS-Reset.

IIS 6- und 7-Protokolle werden je nach Standort in unterschiedliche Ordner geschrieben. Das Format der Standortordner lautet „w3svc{siteId}“.

In IIS6 kann die Standort-ID wie folgt angezeigt werden Bestimmen Sie die Site-ID anhand des Namens des IIS-Protokollordners.

In IIS7 ist in der IIS-Verwaltung in den erweiterten Einstellungen im Browser die ID im Allgemeinen die Site-ID, die Sie verwenden müssen Mithilfe dieser ID können Sie ermitteln, welcher Ordner im LogFiles-Ordner zu der Site gehört, die Sie anzeigen möchten.

Der Unterschied zwischen integriert und klassisch

Die Anwendungspools von IIS7 verfügen über zwei Modi, einer ist integriert und der andere ist der klassische. Wenn Sie den integrierten Modus verwenden, müssen Sie die Konfigurationsdateien für benutzerdefinierte httpModules und httpHandler ändern. Was ist der Unterschied? zwischen den beiden Modi von IIS7 und IIS6?

IIS7.0 Integrierter Modus: Die Module und Handler von asp.net werden von unter gelesen ; und die vorherigen Konfigurationsabschnitte werden ignoriert.

IIS7.0 Classic-Modus: Im Gegensatz zur obigen Situation werden ignoriert.

Klassisch vs. integriert
Der klassische Modus (der einzige Modus in IIS6 und niedriger) ist ein Modus, in dem IIS nur direkt mit ISAPI-Erweiterungen und ISAPI-Filtern funktioniert. In diesem Modus funktioniert Asp.net tatsächlich nur eine ISAPI-Erweiterung (aspnet_isapi.dll) und einen ISAPI-Filter (aspnet_filter.dll). IIS behandelt Asp.net einfach als ein in ISAPI implementiertes externes Plugin und arbeitet damit wie eine Blackbox (und nur dann, wenn die Anfrage ausgegeben werden muss). In diesem Modus unterscheidet sich Asp.net nicht wesentlich von PHP oder anderen Technologien für IIS.

Der klassische Modus ist der einzige Arbeitsmodus für IIS6.0 und niedriger (funktioniert nur auf ISAPI-ERWEITERUNG, ISAPI-FILTER (unter ERWEITERUNG, ISAPI-FILTER). In diesem Modus ist asp.net nur ein Plug-in (aspnet_isapi.dll, aspnet_filter.dll), das ISAPI EXTENSION bzw. ISAPI FILTER implementiert. Die Aufgabe von IIs besteht lediglich darin, bestimmte Anforderungen an Asp.net weiterzuleiten und mit PHP zu hosten und so weiter in IIS. Die Plugins in .

Der integrierte Modus hingegen ist ein neuer Modus in IIS7, in dem die IIS-Pipeline eng integriert ist (d. h. genau das Gleiche ist), wie die ASP.NET-Anforderungspipeline jede gewünschte Anfrage sehen und Dinge bearbeiten kann Übrigens wird ASP.NET nicht mehr als externes Plugin behandelt. Es ist vollständig in IIS integriert. In diesem Modus verfügen Asp.net-HttpModule im Grunde über fast so viel Leistung wie ein ISAPI-Filter und Asp.net-HttpHandler In diesem Modus ist Asp.net im Grunde ein Teil von IIS.

Im integrierten Modus ist die IIS-Pipeline jedoch eng in Asp.net integriert Anforderungspipeline. .net hat die volle Kontrolle und den Zugriff auf die gesamte Anforderungspipeline. Asp.net ist kein externes Plug-in mehr, sondern vollständig in IIS integriert. In diesem Modus haben Asp.net HttpModules und ISAPI Filter gleiche Kontrollrechte, und Asp.net HttpHandlers und ISAPI Extension haben gleiche Kontrollrechte. Mit anderen Worten, Asp.net ist bereits Teil von IIS.

Wenn Sie sowohl IIS6 als auch IIS7 berücksichtigen möchten, können Sie die gleichen Definitionen in httpHandlers (für IIS6) und Handlern (für IIS7) in web.config beibehalten, denken Sie jedoch daran, , andernfalls verursacht IIS7 einen Fehler aufgrund wiederholter Definitionen.

Weitere verwandte Artikel zur Ursachenanalyse und Lösungen des von IIS7 gemeldeten Fehlers 500.23 finden Sie auf der chinesischen PHP-Website!