5
IIS 7.5 - EventID 5012 - Source WAS
Hallo,
seit gut 3 Wochen sind 1 bis 2 Reboots die Woche nötig, da der IIS nur noch teilweise funktioniert und kein RDS-Zugriff mehr möglich ist. Diagnose bislang: null Ahnung 
- Dell-Server mit W2K8 R2 Standard DE, Patchlevel aktuell
- IIS 7.5, ca. 50 Domains
- vorrangig ASP-Sites, wenige .NET, 1 Forum auf PHP5, TS3-Server
Problembeschreibung:
- Es setzen, ohne dass sich in den Logs und Ereignisprotokollen etwas Aussagekräftige finden ließe, Warnung Event-ID 5012 / Quelle WAS ein, jedesmal in anderen Webs mit und ohne ASP (auch in HTML-Pur-Webs)
- Anschließend erscheint die Meldung im 30-Sekunden-Taktn dann steigen weitere App-Pools aus, aber nie alle!
- Die Webs mit den betroffenen App-Pools sind ohne Fehlermeldung nicht mehr zu erreichen (Browser-Timeout)
- Es sind jedes Mal unterschiedliche Webs betroffen, andere laufen weiter, schnell und fehlerfrei
- das PHP-Forum ist jedesmal betroffen
- TS3-Server läuft immer weiter und ist erreichbar
- Remote-Desktop-Zugriff ist nicht mehr möglich, keine Fehlermeldung, nur Timeout
Ich weiß langsam nicht mehr weiter, die Maschine ist gerade ein gutes Jahr alt. Tante Google findet so gut wie nix Hilfreiches.
Hat jemand eine Idee dazu oder ähnliche Erfahrungen machen dürfen?
Greetz, Haimo
- IIS 7.5, ca. 50 Domains
- vorrangig ASP-Sites, wenige .NET, 1 Forum auf PHP5, TS3-Server
Problembeschreibung:
- Es setzen, ohne dass sich in den Logs und Ereignisprotokollen etwas Aussagekräftige finden ließe, Warnung Event-ID 5012 / Quelle WAS ein, jedesmal in anderen Webs mit und ohne ASP (auch in HTML-Pur-Webs)
- Anschließend erscheint die Meldung im 30-Sekunden-Taktn dann steigen weitere App-Pools aus, aber nie alle!
- Die Webs mit den betroffenen App-Pools sind ohne Fehlermeldung nicht mehr zu erreichen (Browser-Timeout)
- Es sind jedes Mal unterschiedliche Webs betroffen, andere laufen weiter, schnell und fehlerfrei
- das PHP-Forum ist jedesmal betroffen
- TS3-Server läuft immer weiter und ist erreichbar
- Remote-Desktop-Zugriff ist nicht mehr möglich, keine Fehlermeldung, nur Timeout
Ich weiß langsam nicht mehr weiter, die Maschine ist gerade ein gutes Jahr alt. Tante Google findet so gut wie nix Hilfreiches.
Hat jemand eine Idee dazu oder ähnliche Erfahrungen machen dürfen?
Greetz, Haimo
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 163303
Url: https://administrator.de/contentid/163303
Printed on: April 16, 2024 at 22:04 o'clock
5 Comments
Latest comment
Ja, habe seit dem letzten Update das gleiche Problem. Nach dem vorletzten Update startete der MySQL-Service nicht mehr ,bzw. gab keine Erfolgsmeldung mehr zum aufrufenden Prozess zurück. Im Dienste-Panel wurde er mit "starting" angezeigt und liess sich weder beenden noch neu starten. Ich habe im Netz noch jemanden mit dem gleichen Problem gefunden - ohne Lösung natürlich.
Nach dem letzten Update dann funktioniert ein App-Pool (läuft mit php und fastcgi) nicht mehr. Die Seiten laden ewig um dann irgendwann doch noch ausgeliefert zu werden. Ich habe den kompletten App-Pool gelöscht und neu eingerichtet. Kein Erfolg, das Ergebniss bleibt das gleiche. Das ist umso seltsamer, weil andere Pools mit der gleichen Konfiguration auf der gleichen Maschine klaglos weiter laufen. Ich weiss nicht mehr, was ich da noch machen soll. Google bringt da leider auch keine Hilfe. Es hängt für mich klar an den Updates und mehrere Leute sind betroffen. Für Microsoft scheint das aber kein Thema zu sein, sind ja nicht die eigenen Anwendungen.
Nach dem letzten Update dann funktioniert ein App-Pool (läuft mit php und fastcgi) nicht mehr. Die Seiten laden ewig um dann irgendwann doch noch ausgeliefert zu werden. Ich habe den kompletten App-Pool gelöscht und neu eingerichtet. Kein Erfolg, das Ergebniss bleibt das gleiche. Das ist umso seltsamer, weil andere Pools mit der gleichen Konfiguration auf der gleichen Maschine klaglos weiter laufen. Ich weiss nicht mehr, was ich da noch machen soll. Google bringt da leider auch keine Hilfe. Es hängt für mich klar an den Updates und mehrere Leute sind betroffen. Für Microsoft scheint das aber kein Thema zu sein, sind ja nicht die eigenen Anwendungen.
Naja, immerhin einer 
Ich habe mittlerweile aufgegeben. Neuer Server ist bestellt und wird als Hyper-V-Host ausgestattet und eingerichtet. Bis das durch ist muss halt rebootet werden. Immerhin scheint es weniger oft vorzukommen, seit dem 24.03. lief jetzt alles durch, allerdings mache ich vorsichtshalber auch jede Nacht um 4:30 einen automatischen Reboot
Ich habe mittlerweile aufgegeben. Neuer Server ist bestellt und wird als Hyper-V-Host ausgestattet und eingerichtet. Bis das durch ist muss halt rebootet werden. Immerhin scheint es weniger oft vorzukommen, seit dem 24.03. lief jetzt alles durch, allerdings mache ich vorsichtshalber auch jede Nacht um 4:30 einen automatischen Reboot
Reboot hat mir leider nicht geholfen. Mein Problem ist, dass ich keinen Schimmer habe, in welchen Logs ich Hinweise auf das Problem finden könnte. Mir fehlt ein bisschen die Übersicht, wie ich das Problem eingrenzen kann. Ich bin da für jede Hilfe dankbar. Liegt es an VM-Ware? Liegt es an Windows? Liegt es am IIS? Liegt es an PHP? Liegt es an MySQL?
Ich fürchte, einfach einen neuen Server anzuklemmen löst das Problem nicht, denn das nächste Update kommt bestimmt.
Ich fürchte, einfach einen neuen Server anzuklemmen löst das Problem nicht, denn das nächste Update kommt bestimmt.
Ich bin einen kleinen Schritt weiter: CREATOR OWNER hat keine Rechte und alle Verzeichnisse stehen auf ReadOnly - auf dem ganzen Laufwerk. Ist das normal?
Ich will jetzt auch nicht schnell was ändern und die Sache noch schlimmer machen...
Nachtrag: Es ist auch tatsächlich so, dass php-Prozesse keine Dateien erstellen können, obwohl der IISUser noch über die entsprechenden Rechte verfügt.
Ich will jetzt auch nicht schnell was ändern und die Sache noch schlimmer machen...
Nachtrag: Es ist auch tatsächlich so, dass php-Prozesse keine Dateien erstellen können, obwohl der IISUser noch über die entsprechenden Rechte verfügt.
Oh, oh, oh. Mein Problem ist gelöst. So ab und zu sollte man doch die alten Session-Dateien aus dem temporären Ordner löschen. 6 Monate mit einer Session pro Besucher ist nicht gut. Aufgefallen ist es mir beim debuggen: Session-Dateien konten nicht mehr erstellt werden und der Zugriff dauerte ewig. Als ich dann noch versuchte, den Temp-Ordner im Explorer zu öffnen, war der Fall klar: Sang- und klanglos abgeschmiert. Per Command-Prompt löscht er jetzt schon eine Stunde und noch kein Ende abzusehen 
.
Ich vermute, Du hast als session_handler auch "file". Check mal Deinen Temp-Ordner.
Rechteproblem ist auch behoben.
Nachtrag: Just for the records: 2,145,092 Files, 270 MB (283,289,345 bytes) . OMG! Da darf er auch schon mal etwas langsamer werden.
NTFS ist schon ein leistungsfähiges Dateisystem...
.Ich vermute, Du hast als session_handler auch "file". Check mal Deinen Temp-Ordner.
Rechteproblem ist auch behoben.
Nachtrag: Just for the records: 2,145,092 Files, 270 MB (283,289,345 bytes) . OMG! Da darf er auch schon mal etwas langsamer werden
.NTFS ist schon ein leistungsfähiges Dateisystem...
