Wartezeit bei Anmeldung

Seit einiger Zeit habe ich auf meinem Entwicklungsrechner das Problem, dass beim Windows-Start nach der Eingabe des Kennworts noch etwa 30 Sekunden vergehen, bis der Willkommensbild durch den Desktop ersetzt wird. Als Schuldiger kam dafür eigentlich nur eines der Programme in Betracht, die kürzlich installiert wurden.

Der Zweitrechner musste nun nochvom RC auf die finale Windows 7-Version aktualisiert werden. Direkt nach der Installation habe ich dann den Desktop und die Farben angepasst. Nach einem Neustart hatte ich dann auf der frischen Installation den gleichen Effekt. Zwischen Eingabe des Kennworts und der Anzeige des Desktops vergingen wieder 30 Sekunden. Diesmal konnte kein fremdes Programm schuld sein, es war nämlich noch keines installiert.

Daraufhin aktivierte ich wieder das Standard-Aerodesign, quasi den Auslieferungszustand. Erstaunlicherweise erschien der Desktop nun wieder sofort nach Eingabe des Kennworts. Nach etwas Herumspielen hatte ich dann die problematische Einstellung gefunden. Sobald der Desktophintergrund auf Einfarbig gesetzt wird, kommt es zu dieser Wartezeit. Ein Hintergrundbild zeigt dagegen keine Verzögerung.

Auf meinem Entwicklungsrechner machte ich dann die Gegenprobe. Dort war seit einiger Zeit wieder ein einfarbiger Hintergrund aktiviert. Nach der Umschaltung auf ein Hintergrundbild war die Wartezeit bei der Anmeldung auch hier verschwunden.

Auch auf dem Laptop lässt sich dieser Effekt reproduzieren. Ein möglicher Workaround ist die Erstellung einer einfarbigen Bilddatei, die dann als Hintergrundbild gewählt wird. Die Betaversion sowie der Releasekandidat haben dieses Problem nicht gehabt, hier konnte man ohne Einschränkungen einen einfarbigen Hintergrund aktivieren.

Könnt ihr dieses Verhalten bei euch auch nachvollziehen?

Ganz schön viel Auswahl

Gestern bei der Installation der Checked Build von Windows 7:

Auswahl Windows 7 (Teil 1)

Und weiter geht’s…

Auswahl Windows 7 (Teil 2)

Habe mich dann doch für die normale Ultimate entschieden.

Windows 7 auf MSDN verfügbar

Seit 19.00 Uhr können sich MSDN-Abonnenten die englischsprachigen Versionen von Windows 7 herunterladen. Folgende Fassungen sind verfügbar:

  • Windows 7 Starter (x86)
  • Windows 7 Home Basic (x86)
  • Windows 7 Home Premium (x86 und x64)
  • Windows 7 Professional (x86 und x64)
  • Windows 7 Ultimate (x86 und x64)

Dazu gibt es noch die Debugsymbole, das Windows Automated Installation Kit und das Windows Driver Kit. Das Windows SDK wird wie schon beim RC in drei Fassungen angeboten (x86, x64 und ia64). Das deutsche MUI-Pack kann ebenfalls heruntergeladen werden.

Die SHA1-Prüfsummen für die Ultimate-ISO lauten übrigens überraschenderweise

  • x86: 5395DC4B38F7BDB1E005FF414DEEDFDB16DBF610
  • x64: 326327CC2FF9F05379F5058C41BE6BC5E004BAA7

Die Downloadgeschwindigkeit ist erwartungsgemäß wieder unter aller Sau. Der vorgezogene Vertrieb über die Tauschbörsen scheint also keine Entlastung zu bringen.

Update: Über die Top-Downloads (Akamai Download-Manager) geht es deutlich fixer.

Das Ende von Multi-Boot

Seit dem Erscheinen von Windows 95 waren auf meinem Entwicklungsrechner immer mehrere Betriebssysteme installiert. Das war auch bitter nötig, denn Virtualisierer waren damals noch ein Fremdwort. Entwickelt habe ich weitgehend unter NT4, unter Windows 95 brauchte man dazu gute Nerven. Fast jede Schutzverletzung hat das Betriebssystem in’s Schwitzen gebracht, häufig musste anschließend das System neu gestartet werden. Ab und zu musste der Debugger aber auch mal unter Windows 95 angeworfen werden. In Hochzeiten waren fünf Systeme nebeneinander installiert (Windows 95, 98, ME, NT4 und Windows 2000).

Heute sind es nur noch drei (Windows XP x64, Windows Vista x64 und Windows 7 x64). Das aber nur, weil es Virtual PC nicht schafft, ein 64-Bit Betriebssystem zu installieren. Vor einiger Zeit habe ich mir deshalb mal wieder VMWare Workstation angeschaut, das neben der Unterstützung für 64-bit Gastsysteme auch eine viel bessere Snapshot-Verwaltung bietet. Mit der Remote Debugging-Funktion von VS 2008 ist so das Debuggen auf den verschiedensten Systemen ein Kinderspiel, zudem hält man sich immer in der gewohnten Arbeitsumgebung auf.

Damit entfällt nun die Notwendigkeit, auf dem Entwicklungsrechner verschiedene Betriebssysteme installieren zu müssen. Mit der Aktualisierung auf die finale Version von Windows 7 gibt es dann nur noch ein Betriebssystem auf der Festplatte. Der Rest findet in einer VM statt.

Kleines Einmaleins

Wenn man in Windows 7 ‘winver’ aufruft, wird man damit überrascht:

Info über Windows

Wie war gleich noch mal die Begründung für den Namen ‘Windows 7′? Es sei die siebente Windows-Version. Ich frage mich jetzt, woran Microsoft das genau festmacht. Windows 1, 2 und 3 sind eigentlich unstrittig. Windows 9x/ME und NT 4.0 liefen unter der Versionsnummer 4.0. Windows 2000 war dann das fünfte Windows (5.0). XP müsste man trotz 5.1 eigentlich als das sechste Windows zählen. Windows Vista bekam eine neue Hauptversionsnummer (6.0) spendiert und sollte damit als Nummer 7 durchgehen.

Damit wären wir nun bei Windows 8 angelangt. Oder bei Windows 7, wenn man XP aufgrund der .1 nicht mitzählt. Aber warum zählt dann Windows 7 trotz .1 wieder als volle Version? Warum hat man die Hauptversionsnummer dann nicht auf 7.0 gesetzt, was besser zum Namen gepasst hätte? Fragen über Fragen. Habt ihr Antworten darauf?

Deprimierend

Irgendwie fühle ich mich an alte ISDN-Zeiten erinnert:

Download Windows SDK

Vor zwei Jahren habe ich den Akamai-Downloadmanager noch verflucht. Er war zwar schrottig zu bedienen, brachte dafür aber wenigstens eine akzeptable Geschwindigkeit. Bin mal gespannt, wie heute abend die Geschwindigkeit bei der öffentlichen W7-Beta ist. Vermutlich ist diese schneller auf meiner Festplatte als die MSDN-Version, die ebenfalls gerade geladen wird. Mit der ist nämlich erst in 70 Stunden zu rechnen, wenn es in dieser Geschwindigkeit weitergeht.

Erweiterte Partition unter Vista erstellen

Wer noch mit DOS und Windows 9x gearbeitet hat, wird sich daran erinnern, dass man Laufwerke mit Daten immer auf erweiterten Partitionen anlegen sollte. Der Grund dafür war, dass DOS bei der Vergabe der Laufwerksbuchstaben immer erst alle vorhandenen primären Partitionen bevorzugte, bevor die erweiterten Partitionen an die Reihe kamen. Dabei war es egal, ob die primäre Partition nun auf der ersten oder auf der vierten Platte lag.

Diese Art der Vergabe ist heute zwar Geschichte, aber trotzdem bevorzuge ich bei Wechseldatenträgern immer noch die erweiterte Partition. Zudem kann man bei einer erweiterten Partition auch mehr als vier Laufwerke anlegen. Bis einschließlich Windows XP war das Erstellen einer erweiterten Partition bequem über die Datenträgerverwaltung möglich. Unter Vista erscheint allerdings die Auswahl zwischen primärer und erweiterter Partition nicht mehr, es wird immer stumpf eine primäre Partition angelegt.

Glücklicherweise gibt es mit DISKPART ein sehr mächtiges Kommandozeilen-Werkzeug, mit dem sich auch erweiterte Partitionen erstellen lassen. Nach dem Aufruf einer Eingabeaufforderung mit erhöhten Rechten (im Startmenü cmd eingeben und mit Strg+Umschalt+Enter starten) kommt man mit DISKPART in den Konfigurationsmodus.

? zeigt alle möglichen Befehle an. Mit list disk werden die verfügbaren Datenträger aufgelistet. select disk 5 wählt einen Datenträger, 5 steht stellvertretend für die Nummer des gewünschten Datenträger. create partition extended erstellt schließlich die erweiterte Partition. Mit exit wird der Konfigurationsmodus wieder verlassen.

Nach dem Wechsel zur Datenträgerverwaltung sieht man dann die frisch erstellte erweiterte Partition. Nun lassen sich die gewünschten Laufwerke in gewohnter Weise erstellen.

FXSAPIDebugLogFile.txt loswerden

Das vollständige Löschen des Tempverzeichnisses von Vista scheitert bei mir jedesmal an der Datei FXSAPIDebugLogFile.txt. Sie gehört zu Windows Fax und Scan und damit stellt sich eigentlich auch die Frage, was ein ungefragt erstelltes Debug-Log in einer Release-Version zu suchen hat.

Wer mit seinem Rechner weder faxt noch scannt bzw. dazu nicht das Windows-eigene Modul verwendet, der kann diese Funktion über Systemsteuerung > Programme und Funktionen deaktivieren. Hier klickt man im Aufgabenbereich auf Windows-Funktionen ein- und ausschalten, anschließend wird das Kontrollkästchen bei Windows-Fax und -Scan demarkiert. Nach einem Neustart kann man die Datei löschen, sie wird anschließend auch nicht wieder neu erstellt.

Service Pack 3 Setup-Fehler

Bei der Installation des Service Pack 3 für Windows XP wurde mir folgende Fehlermeldung angezeigt:

—————————
Service Pack 3 Setup-Fehler
—————————
Auf Laufwerk H: steht nicht genügend Speicherplatz für die Service Pack 3-Installation zur Verfügung. Mindestens 4 MB zusätzlicher freier Speicherlatz sind erforderlich. Wenn Sie ebenfalls Dateien für eine Deinstallation sichern wollen, erfordert die Installation 4 MB zusätzlichen freien Speicherlatz. Geben Sie Speicherplatz auf der Festplatte frei und wiederholen Sie den Vorgang.
—————————
OK  
—————————

H: ist das im Floppy-Laufwerk eingebaute Kartenlesegerät, ein Medium war nicht eingelegt. Nach der temporären Deaktivierung des Laufwerks in der Datenträgerverwaltung ließ sich das Service Pack ohne Fehler installieren.

Aus und vorbei

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.