Welche IIS-Fehlermeldung bedeutet was? HTTP-Statuscodes, Windows-Ereignisse und Abhängigkeiten korrekt zuordnen

IIS-Architektur und Request-Verarbeitung: HTTP.sys, WAS, w3wp, Module/Handler und die Bedeutung von Status-, Substatus- und Win32-Codes

Fehlerbilder im IIS lassen sich erst dann eindeutig deuten, wenn die Request-Verarbeitung entlang der beteiligten Komponenten auseinandergezogen wird. Ein HTTP-Statuscode allein beschreibt lediglich die Sicht des HTTP-Protokolls auf das Ergebnis; in IIS-Umgebungen entsteht derselbe Code aus sehr unterschiedlichen Pfaden: Kernelmodus versus Usermode, Authentifizierung in HTTP.sys versus Modul-Pipeline, oder ein Abbruch bereits vor der Ausführung des eigentlichen Handlers. Genau dafür existieren in IIS die Ergänzungen aus Substatus und Win32-Status (häufig als „Status/Substatus/Win32“ dokumentiert), die den Ursprung des Fehlers an eine Komponente und deren Abhängigkeiten binden.

Request-Pfad im Überblick: Kernelmodus (HTTP.sys) und Usermode (WAS/w3wp)

Am Anfang steht der Kernelmodus-Listener HTTP.sys. Er terminiert TCP, verarbeitet HTTP(S), verwaltet URL-Reservierungen und liefert bereits vor dem Start eines Worker-Prozesses Antworten, wenn Bindings, Zertifikate oder Reservierungen nicht passen. Für jede Website/Binding-Kombination werden Requests einem URL- und Application-Pool-Kontext zugeordnet. Erst wenn ein Application Pool aktiv ist, übergibt HTTP.sys den Request über eine Kernel-Queue an den zuständigen Worker-Prozess w3wp.exe.

Der Windows Process Activation Service (WAS) steuert Lebenszyklus und Konfiguration der Application Pools. Er startet w3wp.exe, überwacht Rapid-Fail-Protection und orchestriert Recycling. Ist WAS gestoppt oder können Worker-Prozesse nicht starten, bleibt die Anfrage häufig im Kernel hängen; der Client sieht dann keine „Anwendungsfehlermeldung“, sondern typischerweise ein generisches Gateway-/Service-Fehlerbild, obwohl die Ursache ein Prozess-, Identitäts- oder Konfigurationsproblem ist.

Im Worker-Prozess läuft die IIS-Requestpipeline, die aus nativen Modulen (z. B. Authentifizierung, URL-Rewrite, StaticFile) und optionalen Managed-Komponenten (ASP.NET/ASP.NET Core Hosting) besteht. Der konkrete Handler (z. B. StaticFile, aspNetCore, ExtensionlessUrlHandler-Integrated-4.0) entscheidet, wie der Request in Inhalt umgesetzt wird. Ein identischer HTTP-Code wie 404 kann daher bedeuten: Ressource existiert nicht (Handler), ist aus Sicherheitsgründen verborgen (Authorization), wird von einem Filter abgewiesen (Request Filtering) oder kann wegen fehlender Zuordnung nicht gemappt werden (Handler Mapping).

Module, Handler und Pipeline-Phasen: Wo Fehler „entstehen“

In der integrierten Pipeline greifen Module in definierter Reihenfolge ein, etwa bei BeginRequest, AuthenticateRequest, AuthorizeRequest, ResolveRequestCache und MapRequestHandler. In jeder Phase können Statuscodes gesetzt oder Requests abgebrochen werden. Deshalb ist die Zuordnung „Statuscode → Ursache“ ohne Substatus und Logfelder unzuverlässig: Ein 401 kann aus Kernel-Authentifizierung, aus einem IIS-Modul oder aus der Anwendung stammen; ein 500 kann eine Managed-Exception sein, ein nativer Modulfehler oder ein Prozessabbruch.

Wichtig ist die Trennlinie zwischen „IIS hat den Request abgelehnt“ und „die Anwendung ist fehlgeschlagen“. Wird der Request bereits durch ein Modul wie Request Filtering blockiert, existiert oft keine Anwendungskontext-Ausführung. Scheitert dagegen der Handler (z. B. beim Laden einer Runtime oder beim Zugriff auf Dateien), tauchen Win32-Codes und detailliertere Substatus auf, die Abhängigkeiten wie Dateirechte, DLL-Ladevorgänge oder Identitätsprobleme widerspiegeln.

Statuscode, Substatus, Win32-Status: Dreifache Fehlersemantik im IIS

IIS protokolliert in W3C-Logs standardmäßig den HTTP-Status (sc-status), den Substatus (sc-substatus) und den Win32-Status (sc-win32-status). Der Status ist die sichtbare HTTP-Antwort. Der Substatus ist eine IIS-spezifische Detaillierung (insbesondere bei 401, 403, 404, 500). Der Win32-Status ist der aus Windows-APIs stammende Fehlercode (z. B. Zugriff verweigert, Datei nicht gefunden) und verankert die Ursache in der Windows-Fehlerdomäne. In Kombination lassen sich Fehler auf Komponentengrenzen abbilden: URL-Registrierung/SSL-Binding (HTTP.sys), Prozessstart (WAS), Pipeline/Module (IIS Core) oder Ressourcen-/Abhängigkeitszugriffe (Win32/.NET).

Ein praktischer Effekt: 404 ohne Substatus kann aus sehr unterschiedlichen Gründen auftauchen. Erst 404.2 lenkt den Blick auf eine gesperrte ISAPI/CGI-Ausführung, 404.3 auf fehlende MIME-Zuordnungen, 404.7 auf Request Filtering (z. B. verbotene Dateiendungen). Ergänzend kann sc-win32-status etwa 2 (Datei nicht gefunden) oder 5 (Zugriff verweigert) liefern und damit zwischen „nicht vorhanden“ und „nicht lesbar“ unterscheiden, obwohl der Client beides als 404 oder 403 wahrnehmen kann.

Typische Zuordnungen im Log: schnelle Komponentendiagnose über Felder und Werkzeuge

Für die Einordnung zählt, ob der Fehler bereits im Kernel entsteht oder erst im Worker-Prozess. Kernelnahe Fehler zeigen sich oft durch fehlende oder ungewöhnliche Einträge in den IIS-Site-Logs, während HTTP.sys und Schannel Ereignisse im System-Log ablegen. Usermode-Fehler erscheinen als reguläre Logzeilen mit Substatus und Win32-Status und lassen sich mit Failed Request Tracing (FREB) bis auf Modul- und Handler-Ebene aufdröseln. Zusätzlich liefert der IIS-Status im Eventlog Hinweise auf Prozessstarts, Abstürze und Konfigurationsprobleme.

• IIS-W3C-Logfelder prüfen: %SystemDrive%\inetpub\logs\LogFiles\W3SVC* (Fokus auf sc-status, sc-substatus, sc-win32-status, cs-uri-stem, cs-username, s-siteid, s-sitename)
• FREB pro Site aktivieren (Request-Pipeline sichtbar machen): %SystemRoot%\System32\inetsrv\appcmd set site /site.name:"Default Web Site" /traceFailedRequestsLogging.enabled:true
%SystemRoot%\System32\inetsrv\appcmd set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /+"[path='*',statusCodes='400-999']"
• Application-Pool- und Prozesszustand verifizieren: %SystemRoot%\System32\inetsrv\appcmd list wp
%SystemRoot%\System32\inetsrv\appcmd list apppool /text:name,state,processModel.identityType,processModel.userName
• HTTP.sys-URL-Reservierungen und SSL-Bindings prüfen: netsh http show servicestate
netsh http show urlacl
netsh http show sslcert
• Windows-Events für Prozess- und Konfigurationsfehler korrelieren: Event Viewer in Windows Logs\Application (Quelle WAS, W3SVC, IIS-W3SVC-WP) und Windows Logs\System (Quelle HTTP, Schannel)

Die Kombination aus Pipeline-Ort (Kernel/Usermode), Substatus und Win32-Code verhindert Fehldeutungen. Ein 401.2 verweist typischerweise auf ein Authentifizierungsproblem in der Aushandlung (z. B. NTLM/Kerberos) und nicht auf fehlende Anwendungsberechtigungen. Ein 403.14 signalisiert fehlendes Default-Dokument beziehungsweise nicht aktiviertes Directory Browsing und hat nichts mit Dateirechten zu tun. Ein 500 mit Win32-Code 193 deutet auf ein ungültiges Executable-Format in einer nativen Komponente hin, während 500 ohne Win32-Signal eher eine Anwendungsausnahme sein kann, die erst durch detaillierte Fehlerseiten oder FREB greifbar wird.

Architektonisch ist entscheidend, dass IIS keine isolierte Webserver-Komponente ist: HTTP.sys hängt an TCP/IP und TLS (Schannel), WAS an Dienststeuerung und Identitäten, w3wp an Token, Dateirechte, Loader und Runtime-Abhängigkeiten. Status-, Substatus- und Win32-Codes sind die präziseste Schnittstelle zwischen diesen Ebenen. Sie machen sichtbar, ob ein Fehler aus Netzwerk/Bindings, aus Aktivierung und Prozessmanagement oder aus Modul-/Handler-Ausführung stammt, und verhindern damit, dass identische HTTP-Statuscodes pauschal einer einzigen Ursache zugeschrieben werden.

HTTP-Statuscodes und IIS-spezifische Fehlerbilder: 4xx/5xx mit Substatus, RequestFiltering, AuthN/AuthZ, Handler-Mappings, Konfiguration und Protokollierung in IIS-Logs, Failed Request Tracing und Eventlog

Warum 4xx/5xx in IIS ohne Substatus diagnostisch unvollständig bleiben

IIS liefert HTTP-Statuscodes stets im Kontext der Request-Verarbeitungspipeline aus (HTTP.sys im Kernel, danach der Worker Process w3wp.exe mit integrierter Pipeline und Modulen). Derselbe Hauptstatus (z. B. 401 oder 500) kann aus völlig unterschiedlichen Stellen stammen: aus HTTP.sys vor Übergabe an den Worker, aus einem nativen IIS-Modul (z. B. RequestFilteringModule, WindowsAuthenticationModule), aus einem Handler (z. B. StaticFile), aus einer verwalteten Runtime (ASP.NET) oder aus der Anwendung selbst. IIS ergänzt daher viele Hauptstatuscodes um Substatus (Format sc-status / sc-substatus) sowie einen Win32-Status (sc-win32-status), der häufig die eigentliche Ursache auf Windows-Ebene benennt (z. B. Zugriff verweigert, Datei nicht gefunden, Zertifikatskette unvollständig).

Der Ort der Fehlerentstehung entscheidet, wo die Ursache sichtbar wird: HTTP.sys-Fehler erscheinen oft ohne detaillierten IIS-Substatus in den Website-Logs, dafür im HTTP.sys-Kontext (z. B. Bindings, TLS, URL-Reservation). Fehler innerhalb w3wp.exe zeigen dagegen häufig aussagekräftige Substatuscodes, Failed-Request-Tracing-Ereignisse und passende Einträge im Windows-Ereignisprotokoll. Deshalb gehört zur Interpretation stets die Korrelation aus sc-status, sc-substatus, sc-win32-status, Request-URL, Authentifizierungsdaten (cs-username) und dem betroffenen Site-/AppPool-Kontext.

Typische 4xx-Fehlerbilder: AuthN/AuthZ, RequestFiltering und Handler-Mappings

Viele 4xx-Codes in IIS sind keine reinen „Clientfehler“, sondern bewusst erzwungene Sicherheits- oder Routing-Entscheidungen. Besonders trügerisch ist 404: IIS nutzt ihn in mehreren Modulen als „Absichtscamouflage“, etwa um nicht zu verraten, dass eine Ressource existiert, aber verboten ist, oder dass ein Handler nicht verfügbar ist. Ebenso kann 403 aus unterschiedlichen Komponenten stammen: Directory Listing deaktiviert, MIME-Typ blockiert, IP-/Domain-Restrictions, SSL-Zwang, unzureichende NTFS-/ACL-Rechte oder URL-Authorization-Regeln.

401 ist in IIS fast immer eine Authentifizierungs-Challenge und damit ein mehrstufiges Aushandeln: zunächst Auswahl des Providers (Negotiate/Kerberos, NTLM, Basic), dann Token-Erzeugung, dann Autorisierung (NTFS, authorization-Regeln, Kernel-/User-Mode-Checks). Identische 401-Hauptcodes unterscheiden sich daher drastisch: fehlende SPNs/Kerberos-Delegation wirken anders als deaktivierte Windows-Authentifizierung auf Verzeichnisebene oder ein Konflikt zwischen anonymousAuthentication und windowsAuthentication in der Vererbung.

• 401.1 (Logon failed): Authentifizierung scheitert beim Provider; oft falsche Anmeldeinformationen, fehlende Berechtigungen zum Anmelden als Batch/Service in Sonderfällen oder Provider-Mismatch; Korrelation über sc-status=401, sc-substatus=1 und sc-win32-status (häufig 1326).
• 401.2 (Logon failed due to server configuration): Authentifizierungsmodus passt nicht zur Ressource oder Pipeline; häufig deaktivierte Authentifizierung im Scope, ungeeignete Negotiate-Einstellungen, oder Konflikte in applicationHost.config/web.config.
• 401.3 (Unauthorized due to ACL): Token wurde erstellt, aber Zugriff wird auf Dateisystem/UNC verweigert; typisch bei fehlenden NTFS-Rechten für die AppPool-Identität oder bei Zugriff auf \\server\share ohne korrektes Delegations-/Credential-Setup; häufig sc-win32-status=5.
• 403.14 (Directory listing denied): Kein Default-Dokument und Directory Browsing deaktiviert; häufig bei Deployment ohne defaultDocument-Eintrag oder falschem physischem Pfad.
• 403.4 / 403.7 (SSL required / Client certificate required): SSL-Policy greift; Ursache liegt meist in sslFlags der Site/Virtual Directory sowie Zertifikatsbindung, nicht in der Anwendung.
• 404.2 (ISAPI/CGI restriction): ISAPI/CGI-Handler ist auf Serverebene nicht erlaubt oder Feature fehlt; relevant bei klassischen Erweiterungen oder falsch eingeschätzten Handlern; Prüfung über IIS-Featurezustand und Handler-Liste.
• 404.3 (MIME type not configured): Datei existiert, aber staticContent blockiert den Typ oder fehlt; zeigt sich häufig nach Hardenings oder bei neuen Dateiendungen; Abgleich über MIME-Map und sc-win32-status=0 vs. 2.
• 404.7 / 404.8 / 404.18 (RequestFiltering): Request wird durch RequestFilteringModule verworfen (Dateiendung, Hidden Segments, URL-/Query-Limits, Double Escaping); Diagnose über Failed Request Tracing mit Area RequestFiltering.

5xx in IIS: Konfiguration, Pipeline-Module, Handler und Upstream-Abhängigkeiten auseinanderhalten

5xx-Fehler entstehen entweder, weil IIS den Request nicht regelkonform verarbeiten kann (Konfiguration/Module/Handler), oder weil eine abhängige Komponente fehlschlägt (Runtime, Backend, Netzwerk). 500 ist dabei der Sammelstatus, dessen Substatus in IIS entscheidend ist. Besonders prägnant ist 500.19: Der Worker erreicht die Ausführung nicht, weil Konfigurationsdaten ungültig, gesperrt oder nicht lesbar sind. Das reicht von Syntaxfehlern in web.config bis zu Delegationssperren (locked sections) oder fehlenden Berechtigungen auf %windir%\System32\inetsrv\config bzw. dem Inhaltsverzeichnis.

500.0 (ohne Substatus) oder 500 mit sc-win32-status ungleich null deutet häufig auf einen nativen Fehlerpfad hin (Modulabsturz, Zugriff auf Ressourcen, API-Fehler). Dagegen spricht 500 mit sc-win32-status=0 bei ASP.NET-Anwendungen oft für eine bewusst gesetzte Antwort durch die Anwendung oder die managed Pipeline. Ergänzend grenzt 502.3 (Bad Gateway) bei ARR/Reverse Proxy klar einen Upstream-Timeout/Failure ab, während 503 auf Service-Unavailability in IIS selbst hindeutet (AppPool gestoppt, Rapid-Fail-Protection, Überlastschutz, deaktivierte Site).

Protokollierung präzise nutzen: IIS-Logs, Failed Request Tracing und Ereignisprotokoll

IIS-Website-Logs liefern die belastbare Basis für Korrelation: Zeit, Client, Methode, URI, sowie sc-status, sc-substatus und sc-win32-status. Der Win32-Status kodiert häufig den „echten“ Fehler (z. B. 2 für Datei nicht gefunden, 5 für Zugriff verweigert, 64 Netzwerkname nicht mehr verfügbar), während Substatus die IIS-interne Einordnung sichtbar macht. Für komplexe Fälle reicht das nicht aus, weil Module Entscheidungen treffen, bevor die Antwort im Log „fertig“ ist.

Failed Request Tracing (FREB) zeigt den Pipeline-Verlauf inklusive Modulen, Notifications, Zeitanteilen und Regelentscheidungen. Damit lassen sich RequestFiltering-Blocks (z. B. URL-Sequenzen, Query-Limits), AuthN/AuthZ-Entscheidungen (Challenge/Token/ACL), Handler-Auswahl (Mapping, Script Map, StaticFile) und Konfigurationsvererbung nachvollziehen. Ergänzend liefert das Windows-Ereignisprotokoll die Komponentensicht: Application und System enthalten Einträge von WAS, W3SVC, IIS-W3SVC-WP und ggf. Schannel, die Fehler in Prozessstart, Identität, TLS-Handshakes oder Modulinitialisierung belegen.

• IIS-Logfelder für Ursachenfindung: sc-status, sc-substatus, sc-win32-status, cs-uri-stem, cs-uri-query, cs-username, cs(User-Agent), time-taken.
• FREB aktivieren und auswerten: %SystemDrive%\inetpub\logs\FailedReqLogFiles als Ablage; Filter typischerweise auf 400-999 und Zielpfad/Verb; Analyse über die XML/HTM-Ausgabe mit Modulnamen wie RequestFilteringModule, WindowsAuthenticationModule, AnonymousAuthenticationModule, StaticFileModule.
• Relevante Eventlog-Provider: IIS-W3SVC-WP (Worker Process), WAS (AppPool-Lifecycle), Microsoft-Windows-HttpEvent bzw. HTTP.sys-nahe Meldungen, Schannel (TLS/Handshake/Zertifikat), jeweils in Event Viewer unter Applications and Services Logs bzw. Windows Logs.
• Komponentenabgrenzung über Fehlerort: Fehler vor w3wp.exe sprechen für Bindings/TLS/HTTP.sys; Fehler mit Substatus und Modulbezug sprechen für IIS-Pipeline; Fehler ohne Substatus, aber mit Anwendungsstack sprechen für Applikations-/Runtime-Ebene.

Abhängigkeits- und Plattformfehler als Webserverprobleme: Application-Pool-Start/Crash, .NET/ASP.NET/ANCM, Dienst- und Identitätsrechte, Bindungen/TLS-Zertifikate, Netzwerk/DNS sowie typische Originalmeldungen und ihre Zuordnung zu Windows-Komponenten

Viele IIS-Störungen entstehen nicht im Webserverkern, sondern in Abhängigkeiten, die der Request zwingend benötigt: Prozessaktivierung, Identität und Rechte, Runtime-Komponenten, TLS/HTTP.SYS sowie Netzwerkauflösung. Charakteristisch ist, dass ein äußerlich gleicher HTTP-Statuscode je nach Pipeline-Stufe eine völlig andere Ursache hat. Ein 503 Service Unavailable kann beispielsweise von WAS (Application Pool kann nicht starten), vom Load-Balancer (Upstream nicht erreichbar) oder vom Kernelmodus (HTTP.sys kann keinen Listener binden) herrühren. Präzise Zuordnung gelingt nur, wenn Statuscode, Substatus, Win32-Fehler und die auslösende Windows-Komponente gemeinsam betrachtet werden.

Application Pool: Startfehler, Rapid-Fail, Prozessabstürze und ihre Windows-Ursachen

Der Application Pool ist die Prozessgrenze zwischen IIS und Anwendung. Sein Lebenszyklus wird durch WAS (Windows Process Activation Service) gesteuert, der den Workerprozess w3wp.exe über W3SVC startet und überwacht. Scheitert bereits die Aktivierung, entsteht häufig HTTP 503.2 (Service Unavailable, Concurrent request limit) oder HTTP 503 ohne aussagekräftigen Substatus; bei wiederholten Crashes greift Rapid-Fail-Protection und der Pool wird deaktiviert. In Logs erscheinen dann Hinweise wie „Application pool is being automatically disabled due to a series of failures in the process(es) serving that application pool.“ (IIS-Warnungen) und im Systemprotokoll Ereignisse, die auf WAS, W3SVC oder Windows Error Reporting verweisen.

Typische Ursachen liegen außerhalb des IIS: fehlende Anmelderechte der Pool-Identität, nicht zugreifbare Pfade (Inhalt, Temp-Verzeichnisse, Konfigurationsdateien), defekte Runtime-Binaries oder ein nicht ladbares natives Modul. Auch „stille“ Umgebungsprobleme wie ein blockiertes Laden von DLLs (z. B. durch Applocker/WDAC), beschädigte Side-by-Side-Assemblies oder fehlende Visual-C++-Runtimes manifestieren sich in 500.0, 503 oder in einem sofort beendeten w3wp.exe ohne verwertbaren HTTP-Output.

.NET, ASP.NET und Hosting-Modelle: CLR, ASP.NET Core und ANCM als Fehlerquelle

Für klassisches ASP.NET (.NET Framework) läuft die CLR im Workerprozess; Fehler zeigen sich oft als HTTP 500 mit Substatus aus dem Modulkontext (z. B. 500.19 bei Konfigurationsproblemen oder 500.0 bei unbehandelten Ausnahmen). Bei ASP.NET Core ist die Kette länger: IIS nimmt den Request an, das Modul AspNetCoreModuleV2 (ANCM) startet oder verbindet sich mit dem .NET-Prozess (in-process via w3wp.exe oder out-of-process via dotnet.exe/<app>.exe). Fehlt das passende Hosting Bundle oder ist die App auf eine nicht installierte Runtime/Architektur (x86/x64) gebaut, schlägt der Start vor dem ersten Response fehl und erscheint häufig als HTTP Error 500.31 - ANCM Failed to Find Native Dependencies, HTTP Error 500.30 - ANCM In-Process Start Failure oder HTTP Error 502.5 - ANCM Out-Of-Process Startup Failure. Diese Meldungen gehören nicht zum Kern von HTTP.sys, sondern zur IIS-Integration des ASP.NET-Core-Hostings; sie verweisen inhaltlich auf .NET-Runtime, Anwendungsstart, Umgebungsvariablen und Prozessrechte.

Auch HTTP 500.32 - ANCM Failed to Load dll oder HTTP 500.33 - ANCM Request Handler Load Failure deuten auf Probleme beim Laden nativer Komponenten hin (fehlende VC++ Redistributables, beschädigte Module, falsche Bitness). Der gleiche numerische Statuscode 500 beschreibt damit nicht „IIS ist kaputt“, sondern ist lediglich die Hülle für eine Abhängigkeit, die in der jeweiligen Hosting-Pipeline nicht erfüllt wurde.

• ANCM In-Process Startfehler: HTTP Error 500.30 - ANCM In-Process Start Failure (Start der App innerhalb w3wp.exe scheitert; Ursache häufig in .NET-Hosting-Bundle, fehlenden Runtime-Assemblies, fehlerhaften appsettings oder Zugriff auf Secrets/Dateipfade unter der Pool-Identität)
• ANCM Out-of-Process startet nicht: HTTP Error 502.5 - ANCM Out-Of-Process Startup Failure (Kestrel/Child-Prozess startet nicht oder antwortet nicht; häufig Port-Konflikt, fehlende Rechte, falscher processPath in web.config oder blockierte Exe durch Richtlinien)
• Native Abhängigkeiten fehlen: HTTP Error 500.31 - ANCM Failed to Find Native Dependencies (fehlende .NET-Runtime/Hosting-Bundle oder falsche Architektur; Zuordnung primär zu .NET-Installation und ANCM-Modul, nicht zum eigentlichen IIS-Request-Routing)
• Klassisches ASP.NET/CLR-Initialisierung: Event ID 1026 (Quelle .NET Runtime) oder Event ID 1309 (ASP.NET) (unbehandelte Ausnahmen/Assembly-Load-Probleme innerhalb der CLR; resultiert oft in HTTP 500 ohne ANCM-spezifische Meldung)

Dienst- und Identitätsrechte: Logon-Rechte, Dateisystem, Zertifikatsschlüssel und DCOM

Die Application-Pool-Identität (z. B. ApplicationPoolIdentity, ein dediziertes Konto oder gMSA) ist ein Windows-Sicherheitsprinzipal. Scheitert die Anmeldung, protokolliert Windows häufig Logon failure: the user has not been granted the requested logon type at this computer oder Statuscodes aus der Sicherheitsrichtlinie; im IIS äußert sich das als Pool-Startfehler und in der Folge als 503. Zugriffsprobleme auf Inhalte oder Konfiguration erzeugen dagegen eher 401/403 oder 500.19, je nachdem, ob die Blockade in Authentifizierung/Autorisierung oder beim Laden der Konfiguration entsteht.

Besonders häufig sind Berechtigungen auf den privaten TLS-Schlüssel eines Zertifikats: Die Site kann gebunden sein, doch der Handshake scheitert, wenn HTTP.sys oder der Prozess keinen Zugriff auf den Key im Maschinenstore besitzt. Das Problem wirkt wie „Webserver down“, ist aber eine Kombination aus Zertifikatsspeicher, Crypto-Provider (CAPI/CNG) und ACLs auf dem Schlüsselmaterial.

Bindungen, HTTP.sys und TLS: Wenn Listener, SNI oder Zertifikate den Request verhindern

Listener und TLS-Termination liegen im Kernelmodus bei HTTP.sys. Fehler in Bindungen treten deshalb oft auf, bevor IIS-Module einen HTTP-Status erzeugen. Typische Symptome sind nicht HTTP-Fehlerseiten, sondern Verbindungsabbrüche, ERR_CONNECTION_RESET, fehlgeschlagene TLS-Handshakes oder Ereignisse aus Schannel. Ein Konflikt entsteht, wenn ein anderer Prozess eine URL-Reservation belegt oder ein Port bereits genutzt wird; dann kann die Site nicht lauschen, obwohl der Application Pool läuft. Bei HTTPS kommen SNI- und Zertifikatszuordnungen hinzu: falsches Zertifikat, nicht passende EKU, abgelaufen, fehlende Zwischenzertifikate oder gesperrte Protokoll-/Cipher-Policies werden als TLS-Fehler sichtbar, nicht als sauberes 4xx/5xx.

• Port/URL-Reservation prüfen: netsh http show urlacl
netsh http show servicestate
netstat -ano | findstr :443
• TLS-Bindung und Zertifikat in HTTP.sys verifizieren: netsh http show sslcert (Zuordnung von IP:Port bzw. SNI-Hostname zu Zertifikat-Thumbprint; Fehler liegen in HTTP.sys, Zertifikatsspeicher und Schlüsselberechtigungen)
• Schannel-/Handshake-Hinweise aus Eventlog: Get-WinEvent -LogName System | where ProviderName -eq "Schannel" (Handshake-Scheitern; Ursache häufig Protokoll/Cipher-Policy, Zertifikatskette oder Key-Zugriff)

Netzwerk, DNS und Upstream-Abhängigkeiten: Wenn 502/504 nicht vom IIS „kommt“

Gateway- und Timeout-Fehler entstehen oft durch Abhängigkeiten hinter dem IIS: Reverse-Proxy-Szenarien (ARR), out-of-process-Worker (ANCM) oder Backends in anderen Netzen. HTTP 502 Bad Gateway deutet auf ungültige oder ausbleibende Antworten eines Upstreams, während HTTP 504 Gateway Timeout typischerweise auf Timeouts zwischen Proxy und Backend hindeutet. Die Ursache liegt dann in DNS-Auflösung, Routing, Firewall, MTU/Fragmentierung oder in der Erreichbarkeit des Zielports, nicht in der klassischen IIS-Modulpipeline. Auch lokale Namensauflösung kann scheitern, wenn der Server über falsche DNS-Server konfiguriert ist oder der Zielname auf IPv6 zeigt, aber der Pfad nur IPv4 zulässt. Ohne korrekte Netzwerkbasis bleibt der Webserver funktional, aber die Anwendung erscheint „down“.