Windows 8.1 Upgrade – Tag 1 – Fehleranalyse

Seit einigen Tagen habe ich mich mit dem Gedanken herumgeschlagen, eine Aktualisierung auf Windows 8.1 durchzuführen. Heute war dann die Zeit gekommen.

Der Fehler

Das Update konnte bei der von mir eingesetzten Windows 8 Version leider nicht über den Windows-Store erfolgen. Ob das beim Upgrade einen Unterschied macht, kann ich nicht sagen, möchte es aber der Vollständigkeit wegen erwähnen. Habe mir einfach das passende ISO Image besorgt und die Installation direkt unter Windows 8 gestartet. Nach einer ganzen Weile ist das Update bei ca. 95% mit folgender Fehlermeldung abgebrochen:

Error during installation of Windows 8.1

Die Analyse

Das ist wieder einmal eine sehr aussagekräftige Fehlermeldung. Man weis sofort was hier die Ursache ist. (**sarcasm-off**) Leider ist auch nirgends erwähnt, wo genau man nun weitere Details finden könnte bzw. ob und wo ein Logfile der Installation existiert. In den Windows-Ereignisprotokollen bin ich nicht fündig geworden. Jedoch gibt es auf dem C-Laufwerk ein neues verstecktes Verzeichnis mit dem Namen “$WINDOWS.~BT”.

win81-temorary-install-folder

Unter “C:\$WINDOWS.~BT\Sources\Panther” findet man zwei Protokolldateien mit den Namen “setupact.log” und “setuperr.log”. In der erst genannten Datei ist das gesamte Protokoll enthalten und in “setuperr.log” werden nur die Fehler weggeschrieben. Für einen kurzen Überblick ist die err-Datei sicherlich hilfreich, leider konnte ich daraus nicht auf den kompletten Zusammenhang schließen. Daher zeige ich hier jetzt die schlussendlich aus meiner Sicht relevanten Informationen für den Fehler.

[sourcecode language=”plain”]
2013-10-27 13:39:40, Info                  MIG    UserIsAdminCheck: Hobel04\User IsAdmin = TRUE
2013-10-27 13:39:40, Info                  MIG    Adding indirect mapping for HKCU (C:\Users\User\NTUSER.DAT) to 0x80000003, S-1-5-21-000000000-00000000-0000000000-1001 (1)
2013-10-27 13:39:40, Info       [0x0803e2] MIG    Adding indirect mapping from HKCU to <C:\Users\User\NTUSER.DAT> loaded at HKEY_USERS\S-1-5-21-000000000-00000000-0000000000-1001 (1) (R/W)
2013-10-27 13:39:40, Warning    [0x0803d9] MIG    IndirectKeyMapper: RegLoadKey(HKEY_USERS,S-1-5-21-000000000-00000000-0000000000-1001 (1),C:\Users\User\NTUSER.DAT) failed (32)
2013-10-27 13:39:40, Info                  MIG    Dumping hive list at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\hivelist…
2013-10-27 13:39:40, Info                  MIG      [\REGISTRY\MACHINE\HARDWARE] =>
2013-10-27 13:39:40, Info                  MIG      [\REGISTRY\MACHINE\BCD00000000] => \Device\HarddiskVolume1\Boot\BCD
2013-10-27 13:39:40, Info                  MIG      [\REGISTRY\MACHINE\SYSTEM] => \Device\HarddiskVolume2\Windows\System32\config\SYSTEM
2013-10-27 13:39:40, Info                  MIG      [\REGISTRY\MACHINE\SOFTWARE] => \Device\HarddiskVolume2\Windows\System32\config\SOFTWARE
2013-10-27 13:39:40, Info                  MIG      [\REGISTRY\USER\.DEFAULT] => \Device\HarddiskVolume2\Windows\System32\config\DEFAULT
2013-10-27 13:39:40, Info                  MIG      [\REGISTRY\MACHINE\SECURITY] => \Device\HarddiskVolume2\Windows\System32\config\SECURITY
2013-10-27 13:39:40, Info                  MIG      [\REGISTRY\MACHINE\SAM] => \Device\HarddiskVolume2\Windows\System32\config\SAM
2013-10-27 13:39:40, Info                  MIG      [\REGISTRY\USER\S-1-5-20] => \Device\HarddiskVolume2\Windows\ServiceProfiles\NetworkService\NTUSER.DAT
2013-10-27 13:39:40, Info                  MIG      [\REGISTRY\USER\S-1-5-19] => \Device\HarddiskVolume2\Windows\ServiceProfiles\LocalService\NTUSER.DAT
2013-10-27 13:39:40, Info                  MIG      [\Registry\User\S-1-5-21-000000000-00000000-0000000000-1001] => \Device\HarddiskVolume3\Users\User\NTUSER.DAT
2013-10-27 13:39:40, Info                  MIG      [\Registry\User\S-1-5-21-000000000-00000000-0000000000-1001_Classes] => \Device\HarddiskVolume3\Users\User\AppData\Local\Microsoft\Windows\UsrClass.dat
2013-10-27 13:39:40, Info                  MIG      [\registry\machine\Schema] => \Device\HarddiskVolume2\Windows\System32\SMI\Store\Machine\SCHEMA.DAT
2013-10-27 13:39:40, Info                  MIG      [\REGISTRY\MACHINE\DRIVERS] => \Device\HarddiskVolume2\Windows\System32\config\DRIVERS
2013-10-27 13:39:40, Info                  MIG      [\REGISTRY\MACHINE\$ONLINE_RW$ELAM] => \Device\HarddiskVolume2\Windows\System32\config\ELAM
2013-10-27 13:39:40, Info                  MIG    End of hive list
2013-10-27 13:39:40, Warning    [0x0803da] MIG    Waiting 6000 msec to retry hive load (tries remaining: 19)…
2013-10-27 13:39:46, Warning    [0x0803d9] MIG    IndirectKeyMapper: RegLoadKey(HKEY_USERS,S-1-5-21-000000000-00000000-0000000000-1001 (1),C:\Users\User\NTUSER.DAT) failed (32)
2013-10-27 13:39:46, Info                  MIG    Attempting to find and unload hive C:\Users\User\NTUSER.DAT (\Device\HarddiskVolume2\Users\User\NTUSER.DAT)
2013-10-27 13:39:46, Warning    [0x0808aa] MIG    Failed to find and unload hive: C:\Users\User\NTUSER.DAT (error 2)

2013-10-27 13:41:34, Warning    [0x0803db] MIG    IndirectKeyMapper: RegLoadKey(HKEY_USERS,S-1-5-21-000000000-00000000-0000000000-1001 (1),C:\Users\User\NTUSER.DAT) failed; giving up (32)
2013-10-27 13:41:34, Error      [0x08039d] MIG    Cannot add mapping for user profile C:\Users\User. Error: 32: Win32Exception: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. [0x00000020] __cdecl Mig::CIndirectKeyMapper::CIndirectKeyMapper(class UnBCL::String *,struct HKEY__ *,class UnBCL::String *,class UnBCL::String *,int,int,const Mig::HiveLoadRetryOptions *)[gle=0x000000cb]
2013-10-27 13:41:34, Error      [0x080801] MIG    User profile loading error. Aborting due to external request.[gle=0x000000cb]
2013-10-27 13:41:34, Error                        MigStartupOnline caught exception: Win32Exception: User profile loading error. Aborting due to external request.: Der angegebene Benutzer hat kein gültiges Profil. [0x000004E5] void __cdecl Mig::COnlineWinNTPlatform::ProcessUser(class Mig::CRegistryDataStore *,class Mig::CRegistryDataUnit *,class UnBCL::String *,class UnBCL::String *,int,int)
2013-10-27 13:41:34, Error                 SP     pSPDoMainGather: Engine initialization failed with error: 0x00000004
2013-10-27 13:41:34, Error                 SP     CGatherData: Migration phase failed. Status: 4[gle=0x00000012]
2013-10-27 13:41:34, Error                 SP     Operation failed: Gather data, scope: Everything. Error: 0x80070004[gle=0x000000b7]
2013-10-27 13:41:34, Error                 CONX   Failed to apply the new system. Error code is [0x80004005][gle=0x000000b7]
2013-10-27 13:41:39, Error                 CONX   Setup has encountered an error. Error code is [0x80004005]
2013-10-27 13:41:39, Error                 CONX   ConX::Setup::Media::CDialogModelDownlevelInstall::NotifyMessage: Error message is displayed at time of downlevel execution: Fehler beim Installieren von Windows 8.1.
[/sourcecode]

Wenn man jetzt genau hinschaut, dann sieht man, dass das Profile von meinem User von \Device\HarddiskVolume3\Users\User\NTUSER.DAT geladen wurde, während alle anderen Registry-Hives von HarddiskVolumne2 geladen wurden. Und scheinbar entlädt der Installer mein eigenes Profil nicht korrekt und kann es somit auch nicht wieder laden.

Im Logfile sieht man …

[sourcecode language=”plain” light=”true”]
Attempting to find and unload hive C:\Users\User\NTUSER.DAT (\Device\HarddiskVolume2\Users\User\NTUSER.DAT)
Failed to find and unload hive: C:\Users\User\NTUSER.DAT (error 2)
[/sourcecode]

An dieser Stelle kann ich nur vermuten: Zunächst gibt der Installer eine Liste der geladenen Registry-Hives aus (siehe: “Dumping hive list”). Danach versucht man anhand dem Profilpfad zur NTUSER.DAT (es wird nach “\Device\HarddiskVolume2\Users\User\NTUSER.DAT” in der Hive-Liste gesucht) und da dieser Pfad (korrekt wäre HardiskVolumne3) nicht geladen ist, wird auch der entsprechende RegistryKey nicht entladen. Beim nächsten Versuch C:\Users\User\NTUSER.DAT in die Registry zu laden, schlägt der Aufruf von RegLoadKey mit der Meldung “Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird” fehl. Logisch, denn mein Profil ist ja noch geladen, wird also verwendet.

Der Installer ist somit nicht in der Lage mein Profil korrekt zu handhaben und bricht mit einer nicht gerade hilfreichen Meldung ab.

Ursache?

Nun muss ich mir an dieser Stelle selbst an die Nase fassen. Auch wenn ich in meinem Rechner eine recht große SSD verbaut habe, wollte ich die Lebensdauer der SSD nicht unnötig verkürzen und habe alle schreibintensiven Dateien und Verzeichnisse auf eine zweite Festplatte verlagert. Dazu habe ich mit der Recovery-DVD gebootet und die entsprechenden Verzeichnisse mittels robocopy von C auf D verschoben und dann mit mklink einen Verzeichnislink eingerichtet. D.h. C:\Users ist ein Link der auf D:\Users zeigt. Und somit liegen alle User-Profiles auf dem D-Laufwerk.

Fazit

Nach etwas Suchen im Netz bin ich über diesen Artikel gestolpert, in dem darauf hingewiesen wird, dass man sich durch das Verschieben von derartigen Dateien/Verzeichnissen auf einen nicht mehr von Microsoft supporteten Weg begibt. Es wird auch in der Mircosoft Dokumentation explizit darauf hingewiesen, dass man (auch wenn den Ordner mit sysprep durchaus offiziell verschieben kann) sein System später nicht mehr aktualisieren kann.

Also alles nur ein Problem von verspielten Power-Usern, die ihr System verbiegen? Ja, so kann man es sehen. Dummerweise habe ich die Änderung nicht aus reiner Langeweile gemacht. Ja, man kann auch für jeden Benutzer spezielle Verzeichnisse wie Documents, Desktop, Downloads, Favoriten usw. verschieben, ohne das eigentliche Profil zu verschieben. Doch man kann z.B. das AppData-Verzeichnis eines Benutzer mit offiziellen Mitteln nicht verschieben, und alleine dieses Verzeichnis ist bei mir 35GB groß.

Ich finde es einfach nicht mehr zeitgemäß, dass einem ein aktuelles Betriebssystem fest vorgibt, wo man seine Benutzerdaten hinlegen muss. Angenommen ich belasse alles vom Betriebsystem (also auch die Profile) an seinem standardmäßigem Platz. Alle Anwendung wollen sich auch standardmäßig nach C:\ installieren. Mit der gleichen Argumentation könnte dann ein Software-Hersteller sagen, dass er das Updaten der Software nur noch dann unterstützt, wenn die Software in den Standard-Pfad installiert wurde. (Und dummerweise ist das bei manchen Programmen auch der Fall!) Man müsste somit nachzu alles nach C: installieren. Das kann doch nicht die Lösung sein. Schon gar nicht, wo SSD-Festplatten noch unter 1TB Kapazität aufweisen.

Aber zurück den den möglichen Lösungen. Ich muss definitiv die Benutzerprofile wieder auf die C-Festplatte verschieben. Da ich das Verschieben manuell durchgeführt habe, sollte es keine Schwierigkeiten geben. Dazu später mehr.

Update: Hier gehts zum zweiten Teil des Berichts.

Comments are closed.