Windows ConfidentialDie Kraft des Fehlers

Raymond Chens

Bei Windows 95 könnten Sie beispielsweise auf der Seite „Problembehandlung“ die Option „Synchrone Pufferzuweisungen deaktivieren“ auswählen. Aber wissen Sie, was dieses Kontrollkästchen bewirkte? Oder warum es überhaupt vorhanden war?

Die Funktion „Commit“ in MS-DOS® leerte normalerweise alle Datenpuffer mit nicht geschriebenen Daten für eine bestimmte Datei, schrieb diese Daten auf den Datenträger und wartete dann eine Bestätigung ab, dass alle Daten geschrieben waren. Erst dann kehrte die Funktion zurück. Wenn Sie die Option „Synchrone Pufferzuweisungen deaktivieren“ auswählen, würde der Aufruf sofort zurückkehren, anstatt das Schreiben der Daten abzuwarten. Dies verstieß natürlich gegen die Funktionsbeschreibung, nach der der Aufruf erst dann zurückkehren sollte, wenn die Daten geschrieben wurden. Damit stieg das Risiko so genannter „Dateiintegritätsprobleme“, wie diese Probleme leicht beschönigend im Knowledge Base-Artikel 139669 bezeichnet wurden: Das Programm, das das Leeren der Datenpuffer veranlasste, erhielt die Rückmeldung, dass die Daten sicher auf den Datenträger geschrieben waren, obwohl dies nicht der Fall war.

Ein Datenbankprogramm kann mit der Funktion „Commit“ bestimmte Punkte festlegen, an denen der Status der Datei auf dem Datenträger mit den erwarteten Daten auf dem Datenträger übereinstimmt. Bei einem Stromausfall des Computers während einer Aktualisierung ist das Datenbankprogramm anhand der am letzten Commit-Punkt aufgezeichneten Informationen in der Lage, die Integrität der Datenbank wiederherzustellen. Wenn die Funktion „Commit“ sofort zurückgekehrt wäre, ohne dass die Zuweisung abgeschlossen war, wäre dieser Integritätsprüfpunkt verloren gegangen. Und damit war die Datenbank beschädigt.

Warum stand diese Option überhaupt zur Verfügung, wenn so schlimme Folgen zu erwarten waren? Der Grund: ein Fehler in Windows® 3.11.

Abbildung 1** Ursache für fehlerhaftes Verhalten in Windows Server 2003 **(Klicken Sie zum Vergrößern auf das Bild)

Mit Windows 3.11 wurde der „32-Bit-Dateizugriff“eingeführt, eine 32-Bit-Implementierung der detaillierten Datei-E/A-Schnittstelle. Die Implementierung der Funktion „Commit“ enthielt jedoch einen Fehler, mit dem Anforderungen zum Leeren der Dateipuffer schlichtweg ignoriert wurden. Wenn Sie ein Programm unter Windows 3.11 ausführten, bei dem die Dateipuffer geleert wurden, blieb dieser Aufruf zum Leeren wirkungslos. Und wenn der besagte Stromausfall genau zu einem ungünstigen Zeitpunkt auftrat, war die Datenbank stark beschädigt.

Bei der Programmierung des Dateisystems in Windows 95 wurde dieser Fehler behoben, aber es gingen trotzdem immer neue Fehlerberichte ein. Das Buchhaltungsprogramm eines Benutzers beispielsweise arbeitete plötzlich extrem langsam. Das Datenbankprogramm eines anderen Benutzers verhielt sich dann genauso. Was ging da vor?

Es stellte sich heraus, dass diese Programme ständig Aufrufe zum Leeren der Puffer ausgaben. Die Programmierer bemerkten, dass die Aufrufe zum Leeren unter Windows 3.11 sehr schnell erledigt wurden, und verteilten diese Aufrufe darum großzügig im gesamten Betriebssystem. Ein Byte schreiben, Puffer leeren. Eine Zeichenfolge schreiben, Puffer leeren. Die Leervorgänge liefen so schnell ab, dass die Anwendung die Daten nach jedem Vorgang auf den Datenträger übertragen konnte, ohne dass nennenswerte Leistungseinbußen zu verzeichnen waren. Mit der Behebung des Fehlers in Windows 95 wurden diese Programme jedoch sehr langsam, weil diese Aufrufe plötzlich richtig arbeiten mussten.

Hätten die Programmierer des Dateisystems nicht eingegriffen, dann wären diese Programme weiter langsam ausgeführt worden, und die Benutzer wären zum Schluss gekommen, dass Windows 95 das Problem war. „Windows 95 läuft im Schneckentempo“, hätte es geheißen. Wenn dagegen das bisherige Verhalten aus Windows 3.11 wiederhergestellt würde, würde der Fehler wieder eingeführt, der zu diesen lästigen „Dateiintegritätsproblemen“ führen kann.

Das Team kam zum Schluss, dass der Fehler nicht wieder aufleben sollte. Stattdessen wurde ein Kontrollkästchen eingeführt (wenn auch tief auf der Seite „Problembehandlung“ vergraben), mit dem alle Benutzer zum Verhalten aus Windows 3.11 zurückkehren konnten, bei denen aufgrund des Fehlers Probleme mit den Programmen aufgetreten waren.

Später wiederholte sich die ganze Geschichte. In Windows Server® 2003 fand das E/A-Team einen Fehler, bei dem alle Anforderungen, die als FUA (Forced Unit Access) gekennzeichnet sind, das FUA-Tag verlieren und stattdessen als normale E/A-Vorgänge durchgeführt werden. Die Neuauflage für das Ignorieren der Leerungsanforderungen! Das Team hat den Fehler behoben und eine Option bereitgestellt, mit der die Benutzer das bisherige, fehlerhafte Verhalten wiederherstellen können. In Windows Server 2003 trägt dieses Kontrollkästchen die Bezeichnung „Erhöhte Leistung aktivieren“, doch wie Sie nun wissen, bedeutet dies tatsächlich nur „Rückkehr zum bisherigen, fehlerhaften Verhalten“.

Raymond ChensWebsite, The Old New Thing, und sein gleichnamiges Buch (Addison-Wesley, 2007) beschäftigen sich mit der Windows-Geschichte und der Win32-Programmierung. Lieber nicht den Ast absägen, auf dem man sitzt.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.