blog@netplanet

Ein mittelgroßes Windows-Problem und dessen Lösung. Und weil es vielleicht für den ein oder anderen interessant sein könnte, den Weg zur Lösung, wie wir ihn als Techniker im Kundensupport gehen.

Problemstellung

Windows Vista. Ich starte meinen Rechner grundsätzlich immer “from the bottom”, also kalt. Das funktioniert unter Windows Vista im Gegensatz zu den Vorgängern flott und zügig, in der Regel ist nach spätestens einer Minute der Anmeldebildschirm da. Das funktionierte jahrelang auch so, bis es irgendwann nicht mehr so funktionierte – der Boot-Vorgang hing beim Booten am Fortschrittsbalken fest, der nach dem BIOS-Bildschirm und vor dem Windows-Trara kommt. Und er hing massiv.

Analyse 1 – Wo klemmt es eigentlich?

Zunächst dachte ich, die Kiste hängt final, was mich anfänglich dazu brachte, den Resetknopf zu betätigen. Das führte beim Neustart dazu, dass es schon wieder an der gleichen Stelle hing. Der erste Schritt war deshalb der, beim Neustart unmittelbar nach dem BIOS-Startbildschirm die F8-Taste zu drücken, um den Windows-Start zu verfolgen. Es stellt sich heraus, dass das Problem beim Laden von fundamentalen Systemdateien entsteht, nämlich beim Laden einer Datei mit dem Namen “crcdisk.sys”.

Diese Datei beinhaltet Funktionen zum windows-eigenen “CRC Disk Filter System”, vermutlich eine Art Technik, mit der der Zustand einer Festplatte auf unerfindliche Weise festgestellt werden kann. I dunno. Was verwunderlich war, war der Umstand, dass beim Hängen offensichtlich nichts mehr passierte, auch kein Festplattenzugriff mehr.

Die erste Suche im Internet nach dem Fehlerschema führt zu abenteuerlichen Lösungsansätzen. Beispiel: Festplatte ausbauen, an einen anderen Rechner anschließen, auf der Festplatte die Datei crcdisk.sys suchen und – löschen. Windows findet die Datei beim Booten nicht und überspringt dann das Laden (glücklicherweise).

Diese Vorgehensweise ist inakzeptabel, denn wer sagt mir, dass Windows irgendwann nicht ins Eiern kommt, wenn diese Datei fehlt?

Analyse 2 – Es klemmt gar nicht final!

In der ersten Verzweiflung überlegte ich, Windows neu aufzusetzen. Also ließ ich den vor sich hinhängenden Rechner für einen Moment allein, um am Notebook irgendwas zu recherchieren. Was genau, ist unwichtig, denn als ich wieder zurückkam, sah ich, dass der vor sich hinhängende Rechner plötzlich am Anmeldebildschirm war. Der Rechner hing also nicht final am Laden dieser “crcdisk.sys”, sondern macht tatsächlich irgendwann weiter, schätzungsweise nach ca. 10 Minuten. Und nach dem Anmelden läuft Windows auch völlig problemlos.

Analyse 3 – Liegt es an der Festplatte?

Wenn ein Treiber, der in irgendeiner Form unmittelbar mit der Festplatte interagiert, werde ich hellhörig, denn Festplattenprobleme kündigen sich selten und in diesen seltenen Problemen gern mit nicht nachvollziehbaren Symptomen.

Also, Festplatte testen. Zunächst einmal schauen, ob die Platte “dirty” ist, also irgendwie das Filesystem beschädigt ist oder sonstige Unfälle Windows dazu gebracht haben, das Dirty-Bit für eine Partition zu setzen. Ist eine Festplatte nämlich “dirty”, hat man danach zu schauen.

Also Eingabeaufforderung als Administrator starten und eingeben:

fsutil dirty query <Laufwerksbuchstabe:>

Das Ergebnis aller Partitionen war eindeutig: Alle Volumes sind nicht fehlerhaft. Trotzdem lässt man die Partitionen besser nochmal generalprüfen, das geht mit dem Kommandozeilenwerkzeug “chkdsk” in folgender Syntax:

chkdsk /f /r <Laufwerksbuchstabe:>

Dieser Prüfvorgang geht nur, wenn “chkdsk” exklusiv auf die Festplatte zugreifen darf, geht also nicht im Betrieb von Windows. “chkdsk” bietet deshalb an, dies beim nächsten Neustart zu tun. Bestätigen, für alle Partitionen und den Rechner neu starten. Dieser Prüfvorgang beim nächsten Neustart dauert in der Regel sehr lange, man darf mit einigen Stunden rechnen. Immerhin gibt es Fortschrittsanzeigen.

Das Durchnudeln von “chkdsk” ergab, dass die Partitionen in Ordnung waren.

Analyse 4 – Huch, es geht wieder.

Tatsächlich schien das Problem behoben zu sein, Neustarts nach der chkdsk-Behandlung schienen wieder so schnell zu sein, wie vorher. Gut, aber wir halten mal ein Auge drauf.

Analyse 5 – Problem wieder da.

Genau das gleiche, Rechner hängt beim Boot-Vorgang, im abgesicherten Modus hängt der Startvorgang wieder beim Laden der “crcdisk.sys”. Noch einmal die Punkte von Analyseschritt 3 durchgezogen, nach ein paar Neustarts trat wieder der hängende Boot-Vorgang auf. Also, Nahkontrolle ist angesagt, letzter Schritt vor der Windows-Neuinstallation.

Analyse 6 – Um die Ecke schauen.

Schauen wir mal in den Gerätemanager, was denn die Hardware im Rechner macht. Und siehe da, hier klemmt etwas, nämlich die Firewire-Karte, ein No-Name-Produkt, das aber zumindest einmal funktionierte. Ein gelbes Warnsymbol meldete, dass der Treiber zu der Karte nicht geladen und die Hardware deshalb nicht gestartet werden konnte. Der angegebene Treiber ist ein “OHCI-kompatibler Treiber”, die Hardware wird also mit einem allgemeinen Windows-Treiber zu starten versucht. Interessanterweise hat diese Firewire-Karte so gar nichts mit der Festplatte zu tun, die ist per SATA an den PC angeschlossen, die Firewire-Karte über den PCI-Express-Anschluss und an dieser Firewire-Karte hängt auch nichts, außer ab und an mein Camcorder zum Einspielen von Filmmaterial.

Muss allerdings alles nichts bedeuten, Treiber haben oftmals Abhängigkeiten. Prinzipiell lässt sich per Firewire nämlich auch eine Festplatte anschließen und wenn ggf. die Firewire-Karte muckt, könnte das letztendlich auch Windows auf den Plan bringen, sich darüber zu wundern.

Das windows-eigene Ereignisprotokoll (in der Systemverwaltung zu finden) meldete zu diesem Vorgang, der unmittelbar beim Systemstart protokolliert wird, nichts detailiertes, die Hardware lässt sich nicht starten. Also, Hardware checken.

Das bedeutet: Rechner auf, Karte ausbauen, schauen, was da so montiert ist. Die Karte ist, wie geschrieben, No-Name, aber der dickste Chip auf der Karte trägt Informationen, nämlich dass er vom Chiphersteller VIA stammt und die Kennung “VT6306L” hat. Das ist ein recht weit verbreiteter Firefire-Chip, der allerdings, so die Information auf der Produkt-Website von VIA, keinen eigenen Treiber benötigt, sondern dieser von Windows-eigenen Treibern gestartet wird. Es macht also Sinn, nach Chip-Kennungen oder Nummern, die auf so No-Name-Karten aufgedruckt sind, in einer Suchmaschine zu suchen.

Okay, also mal schauen, was Windows für weitere Treiber zu dieser Karte anbietet. Also Karte wieder einbauen, Windows starten, Gerätemanager, Gerät auswählen, Treiber auswählen und zwar manuell. Und tatsächlich führt Windows noch einen weiteren Treiber für das Gerät auf, nämlich einen Treiber für VIA-Chipsätze. Aha, das sieht doch schon mal rein vom Namen her besser aus. Also dieser Treiber ausgewählt, ausprobieren.

Lösung – Karte beerdigen.

Kurzum: Auch dieser andere Treiber führte nicht zum Erfolg, die Karte ist auch mit dem anderen Treiber nicht ansprechbar. Also verlässt die Karte den Rechner und wird ausgebaut. Treiber müssen keine deinstalliert werden, Windows führt nach einem Neustart das ausgebaute Gerät schlicht nicht mehr auf. Dauertesten.

That’s it: Die Firewire-Karte war es. Hinüber. Und darauf wäre man nicht gekommen. Interessanterweise hätte hier vermutlich noch nicht mal die Windows-Neuinstallation geholfen, denn das offensichtliche Hardware-Problem wäre höchstwahrscheinlich auch in der neuen Windows-Umgebung aufgetreten. Vor dem Dampfhammer hilft es also durchaus, wenn man vorher etwas nachdenkt.

• 

Würde mich jemand fragen (was natürlich niemand tut, sondern selbst ausprobiert), wie man am schnellsten und effektivsten einen SQL-Server so richtig in Schwierigkeiten reinreiten möchte, dann würde ich das so machen:

1. Eine völlig blöde Konfiguration voraussetzen, beispielsweise alles auf einer Festplatte und alles auf einer Partition: Betriebssystem, SQL-Server-Software, Datenbankdateien, Protokolldateien. Das macht so richtig Spaß, denn wenn ein Teil dieser vier Komponenten heftig zu tun hat, dann hält es einfach alle anderen mit auf. Und wenn die Platte stirbt, wechselt dann auch einfach gleich alles das Ufer des Rubikon.
2. Server beschäftigen und zwar in ganz großem Stil. Das macht man auf Datenbankservern gern mit “Optimierungsprogrammen” wie Defragmentieren oder Virenscannern und lässt die dann auf Datenbank- und Protokolldateien los.
   1. Der Virenscanner wird sich redlich bemühen, gigantisch Arbeitsspeicher fressen, die Festplatte polieren und in der Regel nie etwas finden können. Denn selten liegen die Muster, nach denen ein Virenscanner sucht, genau so in einer Datenbankdatei – eine Datenbankdatei ist immer fragmentiert, hat ein eigenes Speicherformat und ist gesperrt. Besonders clevere Virenscanner setzen sich über die Sperrung hinweg und nudeln den Server auf diese Weise sehr effizient in die 386er-Klasse herunter.
   2. Der Defragmentierer wird loslegen und Teile zusammenpuzzeln wollen, die allerdings ständig in Bewegung sind. Datenbankdateien wird jeder vernünftige Defragmentierer nicht anfassen wollen, wenn sie gesperrt sind, aber an den Protokolldateien kann er sich austoben. Dabei sind Protokolldateien noch viel stärker im Fluss, denn in der Regel werden Protokolldateien von einer Datensicherung bis zum Sicherungspunkt eh wieder gelöscht oder es existiert auf einem SQL-Server, der nicht datengesichert wird (brutaler Fehler) eine Umlaufprotokollierung (noch brutalerer Fehler), d.h. ältere Protokolldateien werden gelöscht, wenn neue angelegt werden. Und wenn dann noch Mist passiert und Protokolldateien beschädigt werden, verbaut man sich damit den allerletzten Notnagel, denn Protokolldateien sind eigentlich dazu da, Operationen auf den Datenbankdateien zu protokollieren. Ohne Protokolldatei ist eine defekte Datenbankdatei nicht mehr wiederherstellbar.
   3. Datensicherungen tagsüber laufen lassen, richtig schön bei Spitzenzeiten. Dann hat auch gleich jeder etwas davon.
3. SQL-Server-Dienste abschießen (“Mann, der SQL-Server hängt aber!”) oder auch einfach den Server hart aus- und einschalten (“Mann, ist die Kiste lahm”). Gern mehrfach. Ja, das Herunterfahren eines Servers, auf dem Datenbankdienste laufen, kann manchmal sehr lange dauern. Das liegt vor allem daran, dass eine gut konfigurierte Datenbank Inhalte nicht sofort in ihre Datenbankdateien kratzt, sondern im Arbeitsspeicher vorhält. Will ein Dienst beendet oder ein Server neu gestartet werden, müssen diese Inhalte möglichst logisch auf in die Datenbankdateien und das dauert. Wer hier abschießt, der wird büßen. Im günstigsten Fall rattert beim nächsten Start der SQL-Server eine ganze Weile, weil die Datenbankdateien “dirty” geschlossen wurden, im ungünstigsten Fall erleidet man Datenverlust, weil nicht fertiggeschrieben werden konnte.
4. Keine Datensicherung haben. Mir kann niemand erzählen, ihm wären die Daten in einer Datenbank nicht so wichtig genug, als dass man sie sichern müsste. Wären sie unnötig, hätte man keine Datenbank, fertig. Und hat man eine Datenbank, hat man sie zu sichern. Dabei genügt es nicht, einfach die Dateien zu sichern, denn ein Datenbank-Server läuft in der Regel ständig und hat, wie bereits geschrieben, gerade die Datenbankdateien exklusiv geöffnet, lässt diese also auch nicht einfach “flach” sichern. Es braucht also entweder eine (ziemlich peinliche) Notlösung, während der Sicherung den Datenbankdienst vorübergehend zu stoppen oder es braucht eine intelligentere Datensicherungslösung, die die Datenbank auf Transaktionsebene sichert. In der Regel nicht trivial, allerdings eine Lebensversicherung. Und selbstverständlich sichert man nicht gerade dann, wenn am meisten los ist und die Datenbank auch schon ohne Datensicherung unter Druck steht, sondern verschiebt das auf eher ruhige Tageszeiten. Und ja, man testet auch gelegentlich mal, ob die Datensicherung überhaupt sichert.

• 

Sicherlich uralt, aber ich erkenne meine tägliche Arbeit sofort wieder. Und nein, ich arbeite nicht im Buch-Support.

• 

Wenn man so ein paar Jahre im Internet-Business unterwegs ist, lernt man ein paar Dinge. Dazu gehören zwei sehr wichtige Punkte:

1. Lies dir den Dreck an, mit dem du arbeiten willst.
2. Pöbele bei technischen Problemen nicht einfach andere Leute an, wenn du dir nicht sicher bist, ob der Mist, der da vor sich hingärt, nicht von dir stammt.

Unter echten Sysadmins – die erkennt man vor allem durch ihre schwarze Kleidung, dem Benutzen von mindestens zwei Mobiltelefonen und einem eingängigen RIPE-Handle – ist das ehernes Gesetz. Selbst wenn man in einem Worst-Case-Szenario die größten Netzwerkprobleme ins Internet herausbläst, meinetwegen falsche Routen per BGP4 ins Internet propagiert oder einen guten, alten Spam-Angriff hostet – niemand schnauzt dich grundlos an, bevor er nicht in klarer Sprache mit dir geredet hat. Im Internet-Business kann man mit nur sehr wenigen Handgriffen so viel falsch machen, da geht man mit den Leuten, die versuchen, das tägliche Chaos in den eigenen Netzen zu bewältigen, mit einer gewissen Portion Respekt um.

Nicht echte Sysadmins, ich nenne sie der Einfachheit halber einfach “Blender”, kennen das alles nicht. Sie haben entweder das Internet nicht verstanden, halten sich nicht an die zwei obigen Punkte oder haben aus dem Grabbelsack, aus dem man als junger Mensch den passenden Beruf zieht, den falschen gezogen. Kommt vor, ich habe bis zu einem gewissen Grad sogar Mitleid damit.

Nicht so bei unserem aktuellen Patienten. Der ist wohl so eine Art Systemberater. Da gibt es auch solche und solche, einige machen einen guten Job für ihr Geld, andere nicht. Der da macht keinen guten Job und lässt uns alle daran teilhaben.

Zuerst hat er uns einen Kunden abgeschwatzt. Damit können wir leben, der Grundsatz im Business lautet: “Kunden kommen – Kunden gehen.” Dieser Kunde will gehen. Es wird ordentlich gekündigt, wir versuchen noch die Gründe zu hinterfragen, es kommen keine wirklich tollen, aber ab einem gewissen Grad hat man das eben zu akzeptieren.

Kunde besitzt zwei Domains, von denen der Systemberater allerdings nur eine kennt. Die ihm bekannte Domain wird ordentlich gekündigt und die übernimmt der Systemprovider auch über seinen Provider. Die andere Domain wird vergessen. Kündigungszeitpunkt kommt und wir machen das, was man mit vergessenen DE-Domains zu machen hat: TRANSIT. Wir löschen also so eine Domain nicht, sondern geben sie dem DENIC zurück, das wiederum den Domainbesitzer kontaktieren wird. Wir tun also das, was von uns gefordert wird, wenn der Kunde schläft und dessen EDV-Mensch ebenso.

Nun gibt es ein Problem: Diese vergessene Domain zeigte auf einen Webserver und die übernommene Domain zeigte wiederum auf die vergessene Domain. Die vergessene Domain führt bei einem Aufruf in einem Webbrowser zur TRANSIT-Informationsseite des DENIC und damit jetzt eben auch die übernommene Domain. Das ist natürlich blöd. Allerdings auch nicht unser Problem, denn man müsste einfach mal den Kopf einschalten und seine Nameserver-Konfiguration im Griff haben. Hat er aber nicht. Seit Tagen nicht. Er ist nun der Meinung, dass wir die Domain, die er bei uns abgeholt hat, nicht an seinen Provider gegeben haben, sondern an das DENIC. Was technisch gar nicht geht, denn die Zustimmung zu einer Domainübernahme kann man nur an den Provider geben, von dem auch die Domainübernahme gestartet wurde. Könnte man begreifen, wenn man sich das in Ruhe mal anschaut, was man da so fabriziert.

Der Höhepunkt der Scharmützel dann heute: Ein Anruf. Damit wollte es uns der Systemberater sicherlich mal so richtig zeigen. Er landete bei mir. Hätte er sachlich gefragt, hätte ich ihm auf den richtigen Trichter gebracht. So wurde es allerdings dann doch nichts:

Besim: “Karadeniz. Guten Tag.”

Systemberater: “Was ist denn das jetzt für eine Blutgrätsche, die ihr am <Kundenname> ausübt?”

Besim: “Okay, wenn Sie mir schon mit so Begrifflichkeiten wie ‘Blutgrätsche’ kommen würde ich vorschlagen, dass Sie sich zuerst einmal darüber kundig machen, wie die Technik funktioniert, mit der Sie arbeiten.”

Systemberater: (überzeichnend) “Okay, dann wünsche ich Ihnen noch einen schönen Tag!”

-klick-

Was jetzt passiert, ist jahrelange Erfahrung, die man mit Blendern sammelt. Er wird frohlockend zu seinem Kunden springen, auf uns ach so böse Leute schimpfen und den Kunden aufstacheln. Wir sind sehr gespannt.

• 

Unser HP LaserJet 4650 ist offenkundig in den vergangenen Tagen gestorben, unglücklicherweise im Rahmen eines Firmware-Updates. Zwar nicht unser Hauptdrucker, dennoch ist ein nicht druckender Drucker natürlich auf Dauer eine eher unglückliche Geschichte. Also haben wir beim HP-Support angerufen, der jedoch auch nicht sonderlich weiterhelfen konnte, außer mit einem Angebot für einen Techniker vor Ort, der 300 Euro kosten sollte. An sich kein übertriebener Preis, wenn man weiß, wie schwer ein LaserJet 4650 ist.

Es lohnt sich jedoch, bei der Analyse etwas mitzudenken: Wir haben nämlich beobachtet, dass der Drucker beim Hochzählen des Arbeitsspeichers plötzlich bei ungefähr 30 MB stoppt und dann 0 MB RAM anzeigt. Die Vermutung von uns Teufelsgeigern lag also nahe, dass eventuell etwas mit dem Arbeitsspeicher nicht stimmt, der eigentlich 128 MB beträgt. Also das Gerät mal aufgeschraubt, was angenehm einfach ist, da man hinten nach dem Lösen von ungefähr 16 Millionen Schrauben das Board herausziehen kann. Und da sitzt schlicht und einfach ein kleiner Speicherriegel mit 128 MB DDR-RAM, den man so auch vom Notebook her kennt.

Und da unser altes Werkstattnotebook ebensolche RAM-Riegel hat, haben wir uns von ihm einen 512-MB-Riegel ausgeliehen, in den Drucker eingebaut und schon funktioniert dieser wieder, nun eben vorübergehend mit monströsen 512 MB RAM. Und wer sich für den Flash-Speicher interessiert: Das ist eine relativ normal aussehende CompactFlash-Karte mit 32 MB RAM.

•