7
Windows 2003 Terminalserver Bluescreen (rdpwd.sys)
Hallo,
wir haben zur Zeit 12 Terminalserver (Windows 2003 Enterpriseserver (32bit) ohne Citrix). Manche lauf seit 5 Jahren, andere seit 2 Monaten. Hardware ist bei allen HP Proliant DL360 (von G3 - G6). Die Server laufen in einem NLB-Cluster. Alle haben seit Jahren das Problem, dass sie hin und wieder abstürzen. In letzter Zeit häuft sich das. Es fällt auf, dass wochenlang kein einziger abstürzt und dann gleich mehrere innerhalb weniger Tage.
Memory.dmp wird keine erstellt (zu wenig Platz auf C), aber die Minidumps sehen alle gleich aus
Caused by Driver rdpwd.sys, also der Terminal Stack Driver. Das ist ja die zentrale Komponente eines Terminalservers und für Windows 2003 gibt´s da keine neuere Version.
Leider finde ich im Internet (google, bin, technet, knowledge base, msdn) nichts, was so richtig passt.
Treibermässig sind alle aktuell. Dafür gibt´s ja von HP Firmware- und SupportPack-CD´s, die automatisch den geeignetsten Treiber installieren.
Windows-Update sind ebenfalls aktuell.
Hat vielleicht jemand eine Idee?
Könnte das durch einen "fehlerhaften" Client verursacht werden? Wir haben richtige ThinClients (Liscon, VXL), minimal installierte NT4.0-Clients, die sofort in eine RDP-Session starten und FAT-Clients (Windows XP) von denen auch auf die Terminalserver zugegriffen wird.
Danke und Gruß
Martin
wir haben zur Zeit 12 Terminalserver (Windows 2003 Enterpriseserver (32bit) ohne Citrix). Manche lauf seit 5 Jahren, andere seit 2 Monaten. Hardware ist bei allen HP Proliant DL360 (von G3 - G6). Die Server laufen in einem NLB-Cluster. Alle haben seit Jahren das Problem, dass sie hin und wieder abstürzen. In letzter Zeit häuft sich das. Es fällt auf, dass wochenlang kein einziger abstürzt und dann gleich mehrere innerhalb weniger Tage.
Memory.dmp wird keine erstellt (zu wenig Platz auf C), aber die Minidumps sehen alle gleich aus
Caused by Driver rdpwd.sys, also der Terminal Stack Driver. Das ist ja die zentrale Komponente eines Terminalservers und für Windows 2003 gibt´s da keine neuere Version.
Leider finde ich im Internet (google, bin, technet, knowledge base, msdn) nichts, was so richtig passt.
Treibermässig sind alle aktuell. Dafür gibt´s ja von HP Firmware- und SupportPack-CD´s, die automatisch den geeignetsten Treiber installieren.
Windows-Update sind ebenfalls aktuell.
Hat vielleicht jemand eine Idee?
Könnte das durch einen "fehlerhaften" Client verursacht werden? Wir haben richtige ThinClients (Liscon, VXL), minimal installierte NT4.0-Clients, die sofort in eine RDP-Session starten und FAT-Clients (Windows XP) von denen auch auf die Terminalserver zugegriffen wird.
Danke und Gruß
Martin
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: 165988
Url: https://administrator.de/contentid/165988
Printed on: April 26, 2024 at 16:04 o'clock
7 Comments
Latest comment
Moin.
Wird das Dumpfile auf dem Server ausgewertet?
...für Windows 2003 gibt´s da keine neuere Version.
Ja? Ich hab hier eine Version 5.2.3790.3959 - sollte jeder haben, der Servicepack 2 installiert hat, Du sicherlich auch.Wird das Dumpfile auf dem Server ausgewertet?
Zitat von @DerWoWusste:
Moin.
> ...für Windows 2003 gibt´s da keine neuere Version.
Ja? Ich hab hier eine Version 5.2.3790.3959 - sollte jeder haben, der Servicepack 2 installiert hat, Du sicherlich auch.
Moin.
> ...für Windows 2003 gibt´s da keine neuere Version.
Ja? Ich hab hier eine Version 5.2.3790.3959 - sollte jeder haben, der Servicepack 2 installiert hat, Du sicherlich auch.
Ich weiss nicht, wo die Version in dem Minidumpfile herkommt. Wenn ich mir auf den Servern, auf denen natürlich SP2 installiert ist, die Datei C:\windows\system32\drivers\rdpwd.sys anschaue, dann hat die genau die Version, die du auch hast.
[Edit]
Hoppla. Bisher hab ich das Minidumpfile vom Server auf meinen XP-PC kopiert und dort das Auslesetool (BlueScreenView) gestartet. Mach ich das direkt am Server, wird auch die richtige Version angezeigt.
Wird das Dumpfile auf dem Server ausgewertet?
Was meinst du damit? [Edit] Jetzt versteh ich. Genau das hast du gemeint, das BlueScreenView am Server gestartet wird, oder?
Das hab ich gemeint, ja.
Versuch mal einen zeitlichen Zusammenhang herzustellen, der aufzeigt, welcher Client sich vor dem Absturz verbinden wollte.
Versuch mal einen zeitlichen Zusammenhang herzustellen, der aufzeigt, welcher Client sich vor dem Absturz verbinden wollte.
Zitat von @DerWoWusste:
Das hab ich gemeint, ja.
Versuch mal einen zeitlichen Zusammenhang herzustellen, der aufzeigt, welcher Client sich vor dem Absturz verbinden wollte.
Das hab ich gemeint, ja.
Versuch mal einen zeitlichen Zusammenhang herzustellen, der aufzeigt, welcher Client sich vor dem Absturz verbinden wollte.
Das wird schwierig bei 400 Clients. Ich wüsste nicht, wie ich das machen soll. Das einzige, was evtl. machbar ist, wäre ein regelmässiges Logging (alle 5 Minuten), welche Clients verbunden sind. Das hilft mir aber gar nichts, wenn alleine schon der Versuch einer Verbindungsaufnahme den Server zum Absturz bringt.
Dann musst Du das wohl labormässig am Wochenende mit Skripten nachstellen, die mstsc auf den Clients wieder und wieder starten.
Zitat von @DerWoWusste:
Dann musst Du das wohl labormässig am Wochenende mit Skripten nachstellen, die mstsc auf den Clients wieder und wieder
starten.
Geht leider auch nicht. Wir sind ein rund-um-die-Uhr-BetriebDann musst Du das wohl labormässig am Wochenende mit Skripten nachstellen, die mstsc auf den Clients wieder und wieder
starten.
Mittlerweile ist es (höchstwahrscheinlich) geklärt. Zumindest kann ich jetzt die Terminalserver gezielt zum Absturz bringen mit genau diesem rdpwd.sys-Fehler.
Und zwar, wenn unsere ThinClients, sowohl Linux als auch VXL, nicht richtig konfiguriert sind, dann funktioniert SessionsDirectory nicht. Sieht dann so aus, dass zuerst die Anmeldemaske eines beliebigen/zufälligen Terminalserver erscheint (NLB halt) und wenn man sich dann mit einem Benutzer anmeldet, der auf einem anderen Terminalserver eine getrennte Sitzung hat, wird man zwar zu diesem weitergeleitet (sieht man im Logfile des SessionDirectory Dienstes) aber die Sitzung wird nicht aufgenommen. Man hat dann einfach einen leeren blauen Bildschirm. Nach ca. 30 Sekunden kommt eine Fehlermeldung, man kann sich erneut anmelden und das Spiel beginnt von vorne. Die Wiederaufnahme der getrennten Sitzung gelingt nur, wenn man zufällig sofort auf dem Server landet, der die getrennte Sitzung hätt.
Und wenn man dieses Nicht-Wiederaufnehmen-können jetzt so zwischen 20 und 60 mal versucht, dann stürzt der Server ab, der die getrennte Sitzung hat. Ist reproduzierbar. Jetzt wird das ein einzelner User wahrscheinlich keine 20 bis 60 mal hintereinander versuchen, aber ich geh davon aus, das Problem tritt auch auf, wenn das von mehreren ThinClients aus versucht wird.
Und zwar, wenn unsere ThinClients, sowohl Linux als auch VXL, nicht richtig konfiguriert sind, dann funktioniert SessionsDirectory nicht. Sieht dann so aus, dass zuerst die Anmeldemaske eines beliebigen/zufälligen Terminalserver erscheint (NLB halt) und wenn man sich dann mit einem Benutzer anmeldet, der auf einem anderen Terminalserver eine getrennte Sitzung hat, wird man zwar zu diesem weitergeleitet (sieht man im Logfile des SessionDirectory Dienstes) aber die Sitzung wird nicht aufgenommen. Man hat dann einfach einen leeren blauen Bildschirm. Nach ca. 30 Sekunden kommt eine Fehlermeldung, man kann sich erneut anmelden und das Spiel beginnt von vorne. Die Wiederaufnahme der getrennten Sitzung gelingt nur, wenn man zufällig sofort auf dem Server landet, der die getrennte Sitzung hätt.
Und wenn man dieses Nicht-Wiederaufnehmen-können jetzt so zwischen 20 und 60 mal versucht, dann stürzt der Server ab, der die getrennte Sitzung hat. Ist reproduzierbar. Jetzt wird das ein einzelner User wahrscheinlich keine 20 bis 60 mal hintereinander versuchen, aber ich geh davon aus, das Problem tritt auch auf, wenn das von mehreren ThinClients aus versucht wird.