Seltsames auf dem Webserver.

Eigentlich sind wir von einem Webserver und der darauf stationierten Website eines Kunden folgende Besucherdimensionen gewohnt. Ein wunderbar gezeichnetes, EKG-artiges Diagramm – zumindest bis auf die letzten beiden Tage:

Eine fast verdreifachte Besucherzahl ist selbst für einen Montag eine höchst seltsame Geschichte. Es wurde bei näherer Analyse aber noch viel merkwürdiger. Denn rund 600 Besuche (und damit ziemlich genau das, was an diesem Montag zusätzlich als Besucher kam) waren nahezu identisch: Sie kamen von einem MacOS-Rechner und einem dort installierten Firefox 3.6 und jeder Aufruf bestand aus dem Abruf einer einzigen Seite. Und das dann auch ziemlich genau im 30-Sekunden-Takt, den halben Tag lang. Gut, denke ich, das wird wohl ein Rechner sein, auf dem ein Firefox etwas Amok läuft, beispielsweise mit einem Addon zum automatischen Refresh einer aufgerufenen Seite.

Was allerdings merkwürdig war, war der Absender: Es war nämlich nicht eine einzige IP-Adresse, sondern tatsächlich genau so viele IP-Adressen, wie zusätzliche Aufrufe, also über 600 verschiedene IP-Adressen. Und, damit nicht genug: Alle diese IP-Adressen stammen aus dem IP-Adresspool von Alice/Telefonica.

Kurzum: Wir haben das Rätsels Lösung nicht gefunden. Ich vermute jedoch, dass da eine Firefox-Installation Und/oder der MacOS-Rechner und/oder der DSL-Anschluss Amok läuft und der Rechner ziemlich genau alle 30 Sekunden einen Seitenabruf über eine PPPoE-Verbindung initiiert, die jedes Mal neu verbunden wird.

Was kann man dagegen tun? Sehr gute Frage – eigentlich nichts sinnvolles. Einzelne IP-Adressen sperren, macht keinen Sinn, dazu sind es schlicht zu viele und dazu gibt es auch noch keine Systematik, schließlich kommen die IP-Adressen aus einem riesigen IP-Adresspool. Übrig bliebe nur auf dem Webserver die Sperrung des gesamten, betroffenen IP-Adressblocks, das wäre jedoch unverhältnismäßig gewesen. Einzig eine Beschwerde an den ISP wäre naheliegend, wenn auch sehr aufwendig. Bis der ISP das Problem gelöst bekommt …

Wir hatten Glück, das Problem verschwand Dienstagmittag genauso schnell, wie es gekommen war. Dienstagvormittag fing es zwar wieder an, irgendwann hörte es dann aber von allein wieder auf.

Entstörung in Sachen Bluetooth-Maus.

Dass ich jemals außerhalb der Telefonwelt mal den Begriff „Entstörung“ verwende… 🙂

Anyway… ich habe mir vor einer Weile eine Bluetooth-Maus für mein Notebook gekauft. Anforderung dabei war, dass die Maus ohne Bluetooth-Dongle zu kommen hat, immerhin hat mein HP Elitebook einen eingebauten Bluetooth-Empfänger und wegen eigenwilliger Produktpolitik eines Mausherstellers baue ich hier keine zusätzlichen Bluetooth-Netzwerke auf. Die Wahl fiel daher auf eine Microsoft-Maus, nämlich eine „Microsoft Bluetooth Notebook Mouse 5000 v1.0“, die ich stolz für schlappe 5 Euro bei eBay ersteigert habe. Dort verkauft mit dem Hinweis, dass sie Spirenzien machen würde und deshalb als kaputt verkauft wird.

Die Maus selbst war dann tatsächlich nagelneu und unbenutzt und funktioniert seitdem auch einwandfrei. Das Problem war auch sehr einfach einzugrenzen und dürfte so vermutlich häufig auftreten. Es hat nämlich etwas mit Stand-By, Hibernation und der Energieverwaltung zu tun, also dem Wiederauferstehen einer schlafengelegten Windows-Sitzung.

Das Problem macht sich folgendermaßen bemerkbar: Hat man eine Windows-Sitzung frisch gestartet, funktioniert die Maus ohne Probleme. Die Probleme tauchen erst auf, wenn eine Windows-Sitzung mit Stand-By oder Hibernation eingefroren und wieder gestartet wurde. Da funktionieren Mäuse ohne Dongles nicht mehr so zuverlässig und verlieren gern einmal die Verbindung. Das kann man dann akut nur noch dadurch beheben, in dem man die Bluetooth-Schnittstelle in der Windows-Sitzung hardware-seitig und dann auch noch die Bluetooth-Maus neu startet. Und selbst dann dauert es meist nicht lange, bis die Maus schon wieder nicht funktioniert.

Das Rätsels Lösung ist ein rein notebook-technisches, nämlich das Energiesparen. Standardmäßig sind auch die Netzwerkschnittstellen in die Energiesparpläne von Windows eingebunden und werden beispielsweise bei Nichtnutzung – je nach Energiesparplan – vorübergehend deaktiviert. Das mag mitunter nicht jede Bluetooth-Maus, weshalb übrigens einige Maushersteller gern eigene Dongles liefern, um genau hier nicht in solche Schwierigkeiten zu tappen.

Dabei ist die Lösung eigentlich sehr, sehr einfach. Im Geräte-Manager lässt sich für jedes Peripheriegerät die Berechtigung für Windows in Sachen Energieverwaltung separat konfigurieren. Und erfahrungsgemäß ist die Bluetooth-Schnittstelle kein wirklicher Energiefresser, zumal sich bei allen gängigen Notebooks die Funkschnittstelle nochmal gesondert deaktivieren lässt und das auch für die Bluetooth-Schnittstelle gilt, unabhängig davon, ob sie aus der windowsschen Energieverwaltung genommen wurde oder nicht.

Aber nun eine Kurzanleitung für Windows Vista und 7, wie man die Bluetooth-Schnittstelle aus der Windows-Energieverwaltung nimmt:

  1. Klick auf den Start-Button.
  2. Im Startmenü rechte Maustaste auf „Computer“.
  3. Dort „Eigenschaften“ auswählen, es öffnet sich das „Basisinformationsfenster“.
  4. In diesem Fenster dann links auf „Geräte-Manager“, es öffnet sich derselbige.
  5. Im Geräte-Manager gibt es dann eine Gruppe namens „Bluetooth-Funkgerät, die mit einem Klick auf das vorangehende Pluszeichen aufklappen.
  6. Das Bluetooth-Gerät des Notebooks mit der rechten Maustaste anklicken, „Eigenschaften“ auswählen.
  7. Im Eigenschaftsfenster ganz rechts den Reiter „Energieverwaltung“ auswählen.
  8. Dort gib es dann den Punkt „Computer kann das Gerät ausschalten, um Energie zu sparen“. Hier den Haken raus, alles mit OK bestätigen, Geräte-Manager wieder schließen.
  9. Glücklich sein.

 

WordPress aus dem Maintenance-Mode holen.

Das automatische Aktualisieren von Plugins, Themes und des WordPress-Kernes ist seit der Version 3.0 hübsch und einfach. Es lädt quasi dazu ein, seine WordPress-Installation aktuell zu halten und genau das ist auch das Ziel der ganzen Aktion. Auch wenn das alles nun so einfach geworden ist, gebietet es nach wie vor eine gewisse Sorgfalt, dieses Updaten.

Denn auch wenn man auf die „Aktualisieren“-Seite im WordPress-Dashboard springt und aktualisiert, sollte man tunlichst das Ergebnis dieser Aktion abwarten. Tut man dies nicht und springt während dem Update auf eine andere Seite, wird das jeweilige Update zwar fertiggestellt (im besten Falle), allerdings kann es passieren, dass der Hinweis auf den Maintenance-Mode, der immer dann eingeblendet wird, wenn ein Update vorgenommen wird, fälschlicherweise bestehen bleibt. Das zeigt sich dann an der Meldung: „Briefly Unavailable for Scheduled Maintenance.“

Dummerweise erscheint diese Meldung nach jeder WordPress-Aktion, also selbst beim Versuch, wieder zurück auf das Dashboard zu kommen. Maintenance ist Maintenance.

Die Lösung ist einfach, wenn man sie kennt: Per FTP ins Root-Verzeichnis der WordPress-Installation und dort die Datei „.maintenance“ löschen. Diese Datei wird immer dann angelegt, wenn eben der Maintenance-Modus aktiviert wird und dann danach auch wieder gelöscht. Bricht man auf der „Aktualisieren“-Seite den Vorgang ab, in dem man beispielsweise auf eine andere Seite springt, wird diese „.maintenance“-Datei nicht mehr gelöscht.

Boot-Probleme unter Windows Vista wegen einer “crcdisk.sys”.

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 Firewire-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.