Das war ein hartes Stück Arbeit. Ich hatte eine Anwendung mit ASP .NET WebForms, .NET Framework 4.8 im IIS, die auf bestimmten Seiten nach kürzerer oder auch längerer Zeit nach Absenden eines Formulars, schlicht dem Anwender im Browser angezeigt hatte:
Die Website ist nicht erreichbar
Verbindung wurde zurückgesetzt.
ERR_CONNECTION_RESET
Im eigenen Log4Net-Protokoll im Server stand nichts Sinnvolles drin. In der Ereignisanzeige stand nur etwas Generisches wie:
Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7a5f8
Faulting module name: clr.dll, version: 4.0.30319.18063, time stamp: 0x526767c6
Exception code: 0xc00000fd
Fault offset: 0x0007717d
Faulting process id: 0x1728
Faulting application start time: 0x01cf972772f04132
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: b4d0c430-031a-11e4-a40f-0050569e40da
Bzw. auch das hier stand im Ereignisprotokoll:
A process serving application pool ‚%1‘ suffered a fatal communication error with the Windows Process Activation Service. The process id was ‚%2‘. The data field contains the error number.
Ich war wirklich planlos.
Nicht-Lösungen
Vieles habe ich ausprobiert, leider immer erfolglos:
- Timeout der Anwendung hochgesetzt.
- ProcDump als Just-In-Time-Debugger registrieren.
- Failed Request Tracing aktivieren.
Lösung
Was dann der Schlüssel war, war diese Stack-Overflow-Antwort:
(Auch hilfreich war diese Einführung zu DebugDiag)
Dort wird empfohlen, mit DebugDiag auf Stack-Overflow-Fehler zu lauschen. Im Dialog dazu in DebugDiag stand dann ganz klein „C00000FD“ daneben. Und das habe ich dann in obigem „0xc00000fd“ wieder erkannt.
Anders als in der Stack-Overflow-Antwort habe ich nur einen Stack-Trace schreiben lassen, kein ganzes Dump/Minidump. die ASP.NET-Anwendung habe ich in den Debug-Modus geschaltet (via Web.config und <system.web><compilation debug="true" ..., in der Hoffnung, schönere Stack-Traces zu bekommen.
Das hat dann tatsächlich auch funktioniert, der Stack-Trace wurde von DebugDiag in eine Textdatei geschrieben. Ich habe dann noch zusätzlich in meiner Anwendung rund um die vielen Stack-Aufrufe Protokollierung eingebaut und bin mir jetzt recht sicher, dass ich damit die Ursache gefunden habe.
Weitere Ressourcen
Über folgende Links, die teilweise recht hilfreich waren, bin ich auch gestolpert:
- windows - Dump Diagnostics - Stack Overflow
- https://segmentfault.com/a/1190000040064824/en
- asp.net - IIS7: A process serving application pool 'YYYYY' suffered a fatal communication error with the Windows Process Activation Service - Stack Overflow
- ASP.NET Error Handling | Microsoft Learn
- https://www.wintellect.com/procdump-post-mortem-switches-order-matters/
- asp.net - Random w3wp.exe crashes in .net 4 - Stack Overflow
- Steps to Catch a Simple “Crash Dump” of a Crashing Process – Share Poignant
- iis - Faulting application name: w3wp.exe Faulting module name: nlssorting.dll Exception code: 0xc00000fd - Stack Overflow