Bei der Installation der Backup-Software wird der fehlende Treiber des Bandgerätes bemängelt:
-> NICHT dem Dialog folgen (stammt aus 3.51), sondern Systemsteuerung-Bandgeräte-Erkennen oder Treiber-Hinzufügen.
Auf meine alten NT4-Tage entdecke ich doch tatsächlich einen Tipp, der besagt, daß ein Windows NT4-System beim Herunterfahren ein Power-Off bei einem ATX Mainboard hinbekommt.
Im Registry-Schlüssel HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon muß die Zeichenfolge PowerDownAfterShutdown den Wert 1 besitzen.
Falls sich das System nach dem Herunterfahren wie bei einem Neustart verhält, soll im SP4 die Datei "hal.dll.softex" nach system32 kopiert und in "HAL.DLL" umbenannt werden.
Bei meinem NT4-Server wollte das ungewollte Neustartverhalten auch durch die hal.dll-Umbenennerei nicht zu einem Power-Off mutieren, sondern erweiterte den Neustart nur um einen vorangegangenen BlueScreenOfDeath, schade.
* * * *
Und in genervten Augenblicken, wenn das an sich sehr stabile NT4 doch nach einem Neustart verlangt, kann das ab Service Pack 3 mit [Strg+Alt+Del+Shift] erreicht werden.
Für dieses Feature ist ein Registry-Eintrag nötig:
In HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon muß eine Zeichenfolge EnableQuickReboot mit dem Wert 1 existieren.
Infos zu TCP/IP, DNS, IP, IP-Adresse, OSI, PPP, RAS, SLIP, Subnetz-Maske und TCP s258
Abgesehen davon, daß ServicePacks nach der Installation diverser Software wieder neu aufgespielt werden müssen, kann es auch zum richtigen GAU kommen, wenn ein ServiceBePacktes System einmal im Reparaturmodus starten mußte. In manchen Fällen bleibt das Booten ganz am Anfang stehen, da ein erster Reparaturversuch Daten von der Orginal-CD aufspielt, die sich mit manchen übriggebliebenen Dateien der ServicePacks nicht vertragen.
Wenn alles zu spät ist:
- Eine zweite Installation in einem anderen Verzeichnis anlegen. - ServicePacks draufspielen. - Den DeInstallationsordner auf einem nicht NTFS-System sichern. Hier stehen die Dateien, die durch das ServicePack ersetzt wurden. - Diese Dateien in das System32-Verzeichnis kopieren. (geht das nicht auch mit den Daten des originalen DeInst-Verzeichnisses?) (wohl nicht, wenn man nicht an die NTFS-Partition herankommt) - jetzt klappts auch mit der Nachbarin.
Eines kalten Tages im November 2004 konfrontierte mich mein ultrastabiler NT4-Server mit einem unerwartet häßlichen Problem.
Die Windows-NT4-Server-Installation betreibe ich Stand 2008 seit mehr als 10 Jahren, um den PC z.B. als Workstation zur Entwicklung von Webseiten mit z.B. php- und MySql-Unterstützung zu benutzen.
Auf "Knopfdruck" bietet er mir eine eigene http-Welt, in der alle erforderlichen Webdienste (bis hin zum MS-SQL-Server) laufen. Entsprechend schnell kann ich die Maschine auf echten Internet-Betrieb umschalten, um per ftp, http, smtp etc. mit dem wirklichen Rest der Welt zu kommunizieren.
Nach jahrelangem und 100% virenfreien Umgang mit einer uralten Outlook-Version und einem entsprechend alten Internet Explorer 4.01 wechselte ich zu den OpenSource-Anwendungen Firefox und Thunderbird, eigentlich mehr den Kunden zuliebe, deren brandgefährliche Installationen von Windows 2000, XP usw. mit neueren, jeden dahergeschissenen Virus willkommen heißenden Version von Outlook, Outlook Express und dem Internet Explorer durch ungefährliche Software entschärft werden sollten.
Das NT-Problem äußerte sich, nachdem ich bereits ein halbes Jahr erfolgreich mit Firefox & Co. arbeitete, darin, daß nachdem ich eine Weile browsender Weise unterwegs war, z.B. die Zwischenablage nicht mehr tat. Auch die sog. common-dialogs wie "Datei öffnen", "Datei speichern unter" etc. ließen sich nicht mehr regulär öffnen. Es schien, als ob der Firefox-Browser abgestürzt wäre. Auch die Installation neuerer Versionen hatte keinen Einfluß auf das Auftreten des Problemes. Selbst im Explorer (früher Dateimanager) konnten Zwischenablage-Funktionalitäten nicht mehr benutzt werden.
Wenn ich den Nerv hatte, kam z.B. der "Datei speichern unter"-Dialog nach ca. 1 Minute (!) zum Vorschein, und ich konnte speichern, was ich speichern wollte.
Wenn ich die Maschine neu bootete, war der Spuk jedesmal vorbei.
Nur woran es lag, war um's Verrecken nicht rauszukriegen.
Irgendwann stellte ich fest, daß es auch auftrat, wenn ich nur eMails abholte, ohne den Browser benutzt zu haben.
Und daß es auch auftrat, wenn ich mich nur eingewählt hatte (damals ISDN-Einwählverbindung), ohne überhaupt nur eine einzige Applikation geöffnet zu haben.
Mmh, ich war ratloser denn je.
Auf der Suche nach verbleibenden Möglichkeiten installierte ich eine Software namens ActivePorts für Windows (läuft unter NT4). Die zeigt zwar lediglich geöffnete Ports sowie dazugehörende Informationen an, war mir aber dennoch eine Hilfe bei der beinahe chancenlosen Suche nach meinem ständigen "NT - Server - ich bin online - die Zwischenablage kackt ab - Datei speichern unter braucht 60 s - Dreck etc. p.p."-Problem.
Ich konnte, nachdem ich mich eingewählt hatte und ein paar Sekunden online war, dem rpcss-Dienst dabei zuzusehen, wie er einfach als Prozess verschwand und prompt darauf traten dann auch alle Probleme wieder auf.
Das ist in sofern bemerkenswert, da sich der Dienst rpcss.exe mit den Bordmitteln von Windows NT gar nicht abschalten läßt.
Ein Neustart des rpcss-Dienstes setzte die meisten der abgekackten Funktionalitäten wieder in Kraft, Kopieren und Einfügen innerhalb der Explorer-Bereiche liefen aber erst wieder nach einer Benutzer-Neuanmeldung.
Nachdem der rpcss-Dienst zumindest als Betroffener, wenn auch nicht direkt als Schuldiger ausgemacht werden konnte, brachte eine entsprechende Internet-Recherche auch bessere Ergebnisse für mein Problem.
Einige brauchbare Seiten ließen sich über die Unnötigkeit eines Prozesses namens rpcss.exe aus, der unter Windows 98 & Co. sogar besser abgeschaltet werden sollte. Öfters wurde rpcss.exe sogar im Zusammenhang mit virulenten Dingen genannt.
ABER: Für Windows-NT-Systeme ist rpcss.exe ein (leider) UNBEDINGT notwendiger Dienst, der Microsoft-typisch beschissen tiefst in's System eingreift und ohne den Windows NT schlicht nicht betrieben werden kann.
Eine informative Webseite bezüglich des NT-rpcss-Problemes fand ich ausgerechnet bei Microsoft selbst:
Microsoft Support: Malformed Request to RPC Endpoint Mapper Can Cause RPC Service to Fail
Die erzählten mir was von "malformed requests" (mißgestaltete Anfragen, gemeint sind Zeichenketten, die zwischen per Netzwerk verbundener Computer ausgetauscht werden), an denen sich der rpcss-Server verschluckt und als Prozess dann gemütlich abraucht. Als Lösung schlagen die Typen mir den Austausch einer Datei vor, die aber allen Ernstes die Installation eines Service Pack 6a voraussetzt. Entweder ich mache den ganzen Microsoft-Dreck mit, oder ich bastele ein kleines Tool, das den Dienste-Status abfragt und bei Bedarf eben diesen wieder startet und eine Benutzer-Neuanmeldung durchzieht bzw. wenigstens den Desktop-Explorer reloaded oder irgendwas in der Art. Mal sehen, zu welcher Lösung sich meine strapazierten Nerven durchringen ... Doch die Strapazen nahmen kein Ende, siehe den Beitrag zum Thema Service Pack 6 weiter unten. Nachtrag Mai 2005: Man mag es nicht glauben, aber seit Anfang Mai 2005 (das Service Pack 6 ließ sich erfolgreich installieren und hat danach per Extrem-Virenbefall innerhalb 10s meinen heiligen NT4-Server in's AUS befördert, so daß ich ihn per Backup wiederherstellen mußte) ist eine Art "Wunder" geschehen. Das per Sicherung auf den Stand der Service Pack 4 - Installation zurückgebrachte und wieder Viren-sichere System, das aber natürlich wieder den rpcss.exe-Fehler enthielt, verhält sich online einwandfrei. Der rpcss-Dienst muckt nicht, auch längere online-sessions verlaufen stabil. Was mag da geschehen sein ? Ich vermute, daß die "malformed requests" bei der Kommunikation zwischen meinem Rechner und dem Internet-Zugangssystem meines damaligen Providers freenet übertragen wurden, und daß nach ein paar Monaten etwas geändert wurde. Was soll's, ich beklage mich nicht weiter, arbeite gerne mit meinem zuverlässigem System und warte mit Spannung auf die Installation eines Internet-Breitband-Zugangs und die damit verbundene Kündigung meines Telekom-Festnetzanschlusses, dessen hohe ISDN-Grundgebühr und lausige Übertragungsrate ein teures Vergnügen war. Nachtrag Juli 2005: In der Zwischenzeit trat der Fehler vereinzelt nochmals auf, aber einfach nicht oft genug, um deswegen ein eigenes Tool zu programmieren. Mittlerweile benutze ich einen Internet-Breitband-Zugang der Kabel-BW-Gesellschaft (lokaler Anbieter von Kabelfernsehen und Internet-Zugängen in Baden-Württemberg) und bin (mit einer Flatrate gesegnet) öfter und länger online, als es früher der Fall war. Der rpcss.exe-Fehler trat seit Benutzung des Kabel-BW-Internetzuganges nie wieder auf. Das erhöht die Wahrscheinlichkeit, daß "malformed requests" im Zusammenspiel meines Rechners mit dem früheren Provider freenet zu suchen waren. Auf jeden Fall toll, daß sich die Sache offensichtlich erledigt hat. Und wenn demnächst mein neuer Rennsemmel-PC fertig wird (fast völlig lautlos und schnell), dann wird mein Arbeitszeug auf einem abgespeckten Windows 98 eingerichtet. Dann klappt's auch mit USB und ich brauche den ganzen Microsoftschen Scheißdreck mit Hotfixes, Service Patches, Online Update Services etc. nicht und kann mich ungehindert meinen Webserver-Programmierarbeiten widmen - schöne neue Welt :) Nachtrag Oktober 2005: Im Rahmen eines Umzuges in das schwäbische Walheim stellte ich den auch dort verfügbaren Internet-Tarif zugunsten einer höheren Geschwindigkeit um - und der rpcss-Fehler trat wieder auf. Bevor ich jedoch dazu kam, die Hotline zu nerven, traf der zu dem neuen Tarif gehörende Router/Switch ein, dessen Inbetriebnahme mittels dessen Standard-Einstellungen alleine einen halben Tag kostete. Nach der erfolgreichen Installation des Routers trat der rpcss-Fehler NIE wieder auf - was für ein Segen.
Ja, da ist er wieder, dieser rüpelhafte Ton, dieser Hang zum Gossenslang, dieser starke Drang, einen der Schuldigen ausfindig zu machen, ihm reinen Wein "einzuschenken", sprich, jemanden aus dem Hause Microsoft von der Unbeschreiblichkeit des Versagens durch persönlichen Einsatz zu befreien.
Was ist passiert:
Nachdem mein mit Stand von 2005 seit ca. 7 Jahren fehler- und virenfrei laufendes, "heiliges" Windows-NT4-Server-System immer beim "online"-Sein Probleme bereitete (ein Dienst kackte wegen "schlecht geformter" Anfragen ab, siehe auch weiter oben zum Thema rpcss.exe), schien Rettung in Gestalt eines Hotfixes zu nahen, der allerdings die Installation des Windows NT4-SP6a voraussetzte.
Das SP6 war im Kollegenkreis (Menschen, die Trost in den Gigabytes der MSDN-Kompendien suchen) schnell aufgetrieben und eine vollständige Sicherung der NT-Server-Partition flugs auf CD gebrannt.
Die Installation verlief reibungslos, der folgende Neustart erfolgte ohne erkennbare Probleme.
