Letztes Jahr im April hatte ich euch von den Problemen mit meinem Matrix-RAID berichtet. Nach einem Tip von Christof Windeck hatte ich es dann noch einmal versucht und ab da lief das RAID auch ziemlich problemlos. Vor zwei Wochen fing es aber wieder an herumzuzicken. Völlig überraschend verabschiedete sich Vista mit einem BSOD und der Meldung

***STOP: 0×00008086 (0×00000000, 0×00000000, 0×00000000, 0×00000000)

Die Ursache war mir völlig unklar. Keine neue Hardware, kein BIOS-Update, keine neuen Treiber. Nach einem Neustart überprüfte der Intel Storage Manager das RAID-1 auf Beschädigungen. Das läuft zwar unter Windows im Hintergrund, allerdings ist aufgrund der hohen Festplattenbelastung kein normales Arbeiten möglich. Lässt man den Rechner in dieser Zeit in Ruhe, ist die Aktion in einer reichlichen Stunde vorbei.

Sicherheitshalber spielte ich das letzte Image von Ende November zurück, welches ja von da bis eben auch fehlerfrei gearbeitet hat. Geholfen hat das aber nicht, zwei weitere BSOD folgten in unterschiedlichen Abständen. Zudem fror der Rechner nun auch das eine oder andere Mal kurz ein und die Festplattenleuchte zeigte sich dabei im Dauerbetrieb. Mal erholte sich der Rechner wieder, mal half nur noch der Reset-Schalter. Im letzteren Fall folgte wieder eine Überprüfung durch den Intel Storage Manager. Und bei jedem Zwischenfall tauchte in der Ereignisanzeige teilweise mehrfach die Meldung

Das Gerät \Device\Ide\iaStor0 hat innerhalb der Fehlerwartezeit nicht geantwortet.

auf. Keine Ahnung, woher das plötzlich kam.

Normalerweise lasse ich mir Entscheidungen ja nicht vom Rechner aufdrängen, aber in diesem Fall hat er jetzt endgültig gewonnen. Eine neue Platte hat die zwei RAID-Platten verdrängt. Nach dem Kopieren der Daten und dem Zurückspielen der letzten Images läuft nun alles wieder (auch ohne Neuinstallation). Für den ersten Start musste ich noch den RAID-Modus aktiviert lassen, wobei die neue Platte wie auch zuvor meine zweite Datenplatte als Non-RAID angeschlossen war. Für die Umstellung auf AHCI brauchte ich nur die von Media Addicted zur Verfügung gestellte REG-Datei doppelklicken (IaStor.sys war ja bereits installiert) und den IDE-Modus im BIOS von RAID auf ACHI stellen. Vista war auch großzügig gestimmt und verzichtete auf eine neue Zwangsaktivierung.

Mag sein, dass die RAID-Probleme auch auf das Board zurückzuführen sind. Mal schauen, ob es ohne RAID jetzt ruhiger zugeht.

MSDN-Abonnenten können ab sofort das Service Pack 1 für Vista herunterladen. Im Angebot sind

• Windows Vista Service Pack 1 (x86, x64) – DVD (English, French, German, Japanese, Spanish)
• Windows Vista Service Pack 1 (x86) – EXE (English, French, German, Japanese, Spanish)
• Windows Vista Service Pack 1 (x64) – EXE (English, French, German, Japanese, Spanish)

Die Links findet ihr in der Liste mit den Top Subscriber Downloads.

Während des internen Betatests von SpeedCommander 11.6 ist Alex aufgefallen, dass beim Kopieren von Dateien von einem gemappten Netzlaufwerk in ein UAC-geschütztes Verzeichnis eine Fehlermeldung angezeigt wird:

Wir vermuteten zuerst Schwierigkeiten mit den UAC-Funktionen in SpeedCommander, allerdings zeigte der Explorer ein ähnliches Verhalten. Schließlich fanden wir den Grund. Die Verbindung zum Netzlaufwerk wird bei der Anmeldung nur mit dem Token für eingeschränkte Rechte durchgeführt. Das Token für die angehobenen Rechte, welches beim Kopieren mit UAC verwendet wird, kennt die Verbindung zum Netzlaufwerk aber nicht. Damit kann die Quelldatei nicht gefunden werden und dies führt dann zur Fehlermeldung. Wenn dagegen für das angehobene Token zufällig ein anderes Netzlaufwerk gemappt ist, auf dem sich unter dem gleichen Pfad eine andere gleichnamige Datei befindet, dann wird diese anstelle der gewünschten kopiert.

In Martin’s Blog habe ich nun eine Lösung für das Problem gefunden. Mit dem Setzen von EnableLinkedConnections unter [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] auf 1 synchronisiert Vista die Netzwerkverbindungen für das eingeschränkte und angehobene Token und das Kopieren erfolgt fehlerfrei. Das ganze wird auch im KB937624-Eintrag beschrieben.

Hier noch einmal der ganze Eintrag als fertige .reg-Datei:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLinkedConnections"=dword:00000001

Seit ein paar Wochen arbeite ich fast nur noch unter Vista x64. Mit dem Beta-Treiber für meinen HP LaserJet 1022 funktioniert der Drucker nun genauso gut wie unter einem 32-bit Betriebsystem und dank dem Vista Codec Pack (x64 Components) zeigt auch die 64-bit Version von SpeedCommander endlich alle wichtigen Mediendateien in der Schnellansicht an. Die einzige Einschränkung ist immer noch meine DOS-Fakturierung, die dank Virtual PC aber problemlos in einer VM läuft.

Für die Entwicklung hat das nun den Vorteil, dass ich die 64-bit und 32-bit Versionen von SpeedCommander bequem auf einem System entwickeln und testen kann, ohne ständig booten zu müssen. Zudem lässt sich die 64-bit Version nun auch intensiv im Praxistest begutachten, bisher ist aber noch nichts böses aufgefallen.

Die ganze Sache hat mir keine Ruhe gelassen, daher habe ich gestern noch weitere Tests durchgeführt. Bisher hatte ich immer nur auf meinen Dateiserver kopiert, wenn auch von zwei verschiedenen Rechnern. Um auszuschließen, dass das Problem mit dem Dateiserver zusammenhängt, habe ich die Testdaten nun über Kreuz kopiert, d.h. vom Vista des einen Rechners auf ein XP des anderen sowie vom Vista des anderen auf das XP des einen Rechners. Erstaunlicherweise wurden die Daten hierbei ohne Fehler kopiert. Auch die Kopien auf mein Notebook waren fehlerfrei.

Damit scheint festzustehen, dass der Datenverlust beim Kopieren kein allgemeines Problem von Vista ist, sondern mit der Konfiguration meines Dateiservers zu tun haben muss. Auf dem Server läuft ein RAID-1, welches an einem zusätzlichen SIL3112-Controller (Silicon Image) angeschlossen ist. Probleme gab es damit bisher nicht, auch das RAID-Statusprogram und die Ereignisanzeige zeigen keine Fehler an. Trotzdem habe ich das RAID aufgelöst, die beiden Festplatten wieder an den Onboard-RAID-Controller (VIA VT8237) angeschlossen und erneut ein RAID-1 erstellt.

Erneute Tests mit dem nun neuen RAID-1 funktionierten wiederum fehlerfrei. Das heißt also, dass die Kopierfehler irgendetwas mit der alten RAID-Konfiguration zu tun haben müssen. Warum sie dann aber bei gesetztem “CopyFileBufferedSynchronousIo” nicht auftraten, dafür habe ich keine Erklärung. Den Eintrag “CopyFileBufferedSynchronousIo” werde ich aber trotzdem aktiviert lassen, da damit die Datentransferrate beim Kopieren über das Netzwerk spürbar angehoben wird.

Es ist der Alptraum jedes Dateimanager-Entwicklers, wenn beim Kopieren oder Verschieben von Dateien ein Datenverlust auftritt. Im Anwenderforum hatte Hornen über Probleme beim Kopieren von Dateien berichtet und festgestellt, dass beim Kopieren über das Netzwerk auch Dateien beschädigt werden. Am Wochenende ereilte mich das gleiche Schicksal. Nach dem Herunterladen von größeren signierten Installationsdateien (z.B. Office 2003 SP3) und dem Kopieren dieser auf meinen Dateiserver war ersichtlich, dass die Signatur nach dem Kopieren nicht mehr gültig war und die Datei somit verändert wurde.

Aber wie kann so etwas passieren? SpeedCommander verwendet zum Kopieren von Dateien grundsätzlich die Funktion API-Funktion CopyFileEx, die gesamte Kopieraktion (Quelldatei öffnen, Zieldatei erstellen, Dateiinhalt kopieren, Dateien schließen) wird von Windows erledigt. Zum Test habe ich mir das aktuelle Backup von SpeedCommander 12 (1120 Ordner, 15818 Dateien, 459 MiB) geschnappt und auf meinen Dateiserver kopiert. Anschließend habe ich Quell- und Zielverzeichnis mit Araxis Merge verglichen. Auf beiden Vista-Testsystemen (32- und 64-bit) sind alle derzeit über Windows-Update erhältlichen Updates installiert (inkl. Zuverlässigkeits- und Stabilitätsupdate).

Das Ergebnis war erschreckend. Araxis Merge fand ca. 30 Dateien, bei denen es Unterschiede zwischen Quelle und Ziel gab. Alle betroffenen Dateien waren größer als 1 MiB, aber nicht alle Dateien, die größer als 1 MiB sind, waren fehlerhaft. Den gleichen Test habe ich mit dem Explorer und dem Total Commander (bei aktiviertem Kompatibilitätsmodus für alle Laufwerke) wiederholt, aber Araxis Merge fand jedesmal Unterschiede zwischen Quelle und Ziel. Das Problem liegt also definitiv in CopyFileEx, da SpeedCommander, Explorer und Total Commander (bei aktiviertem Kompatibilitätsmodus) diese Funktion zum Kopieren von Dateien verwenden.

Google führte mich zu KB941673, wo zu lesen war, dass das Verhalten von CopyFileEx in Vista geändert wurde:

In Windows Vista, the CopyFile function creates a non-cached I/O request to perform a write operation. Therefore, the speed of the file copy operation is affected by the disk speed and by other resources on the older operating system.

The CopyFileBufferedSynchronousIo registry entry reverts the CopyFile function in Windows Vista to its earlier behavior. After you add the registry entry, you expect the CopyFile function to work as it would in an earlier Windows operating system. However, because Windows Explorer does not check for this registry entry, this problem occurs.

Wenn man Google mit “CopyFileBufferedSynchronousIo” füttert, dann findet man eine Menge Treffer. Die meisten Seiten empfehlen den Eintrag als Tweak für Vista, andere berichten darüber, dass damit ein Problem in Windows Backup gelöst werden kann.

Mit dem Setzen des Eintrags zwingt man CopyFileEx das “alte” XP-Verhalten wieder auf. Damit dies auch im Explorer funktioniert, muss man bei Microsoft den oben angegebenen Hotfix anfordern. SpeedCommander und Total Commander ist der Hotfix egal, sie verwenden den Eintrag automatisch nach einem Neustart des jeweiligen Programms. Beide Anwendungen kopieren anschließend das Backup-Verzeichnis wieder gewohnt zuverlässig ohne Fehler.

Ich kann also jedem, der mit Vista Dateien über das Netzwerk kopiert bzw. verschiebt, nur dringlichst empfehlen, diesen Eintrag zu setzen. Ein Nebeneffekt ist (zumindestens bei mir) eine deutlich erhöhte Datentransferrate sowie eine flüssigere und nicht mehr so abgehackte Anzeige des Fortschrittsbalkens. Wer mit der Registrationsdatenbank nicht so firm ist, der lädt sich einfach die folgende .reg-Datei

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]
"CopyFileBufferedSynchronousIo"=dword:00000001

herunter und doppelklickt diese anschließend im Explorer oder im Dateimanager seines Vertrauens.

Jetzt wissen wir endlich, warum für Anfang des Jahres angekündigte Produkte meistens erst im Herbst erscheinen:

heise online berichtet über WGA-Funktionsstörungen und Phil Liu, seines Zeichens WGA-Program Manager bei Microsoft, will nicht eher schlafen gehen, als bis die Störungen behoben sind. Selbst wenn es bis Dienstag dauert.

Wem sein Aero lieb und teuer ist, der sollte im Moment keine Downloads von Microsoft durchführen, die eine Validierung erfordern. Ansonsten gibt es bei der folgenden Windows-Anmeldung die nette Meldung, dass man möglicherweise Opfer einer Softwarefälschung geworden ist:

Die gleiche Meldung gibt es auch, wenn man anschließend eine Windows-Updatesuche anstoßen möchte.

Ein nicht aktiviertes Vista lässt sich aber problemlos aktivieren und wird als Originalsoftware gekennzeichnet, die Suche nach Updates funktioniert ebenso. Also im Moment Finger weg von validierungspflichtigen Downloads, es sei denn, man hat ein aktuelles Image in der Hinterhand.

Nachtrag um 21:30

Jetzt klappt wieder alles.

Wer meinen Anfang des Jahres erschienenen Artikel zur Benutzerkontensteuerung in Vista verpasst hat, der hat jetzt noch einmal die Möglichkeit zur Nachlese. Im aktuellen c’t spezial Security ist der Artikel “Fensterwächter” erneut abgedruckt. Dazu gibt es natürlich auch noch weitere sehr interessante Artikel. Also schnell zugreifen, solange das Heft noch nicht ausverkauft ist.