So einige technik-affinere Nutzer von Windows 10 erleben beim Feature-Upgrade auf Windows 10 Anniversary einen Installationsabbruch nach wenigen Prozent. Wer mit dem c't Notfallsystem experimentierte, dürfte betroffen sein.
Anzeige
Der Installationsabbruch des Windows 10 Anniversary Update (oder auch beim Umstieg von Windows 7 SP1 auf Windows 10) scheitert mit der Meldung Windows 10 konnte nicht installiert werden oder mit den Fehlercodes WindowsUpdate_80070003 und WindowsUpdate_dt000.
Ich hätte es letztendlich nicht mitbekommen – zu viele Baustellen an zu vielen Ecken hier. Aber ein Blog-Leser hat diesen Kommentar hinterlassen (danke dafür). Windows-Nutzer, die sich mit dem c't Notfallsystem auseinander gesetzt und dieses auf ihren Maschinen zusammen gebaut haben, bleiben mit einem inkonsistenten System zurück.
c't-Redakteur Peter Siering hat es in diesem Forenbeitrag zusammen getragen (hier postet ein c't-Leser weitere Infos). Sucht man unter Windows nach der Datei setuperr.log, kopiert diese auf den Desktop und öffnet die Protokolldatei in einem Editor, findet sich folgender Hinweis:
Failed to mount WIM file C:\$WINDOWS.~BT\Sources\SafeOS\winre.wim
Anzeige
Die winre.wim mit Windows PE kann nicht gemountet werden (diese Umgebung wird aber beim Upgrade benötigt). In der Datei setupact.log kommt man dann dem Übeltäter auf die Spur.
Adding service [WIMMount] Service belongs to driver path: [\??\C:\ctnot\Projects\Tools\Win8.1SE\X64\wimmount.sys] Adding driver [\??\C:\ctnot\Projects\Tools\Win8.1SE\X64\wimmount.sys] type [0x00000002] nitializing driver [\??\c:\ctnot\projects\tools\win8.1se\x64\wimmount.sys] type 0x00000002 CreateFile failed for file [\??\c:\ctnot\projects\tools\win8.1se\x64\wimmount.sys] Failed to add driver [\??\C:\ctnot\Projects\Tools\Win8.1SE\X64\wimmount.sys]
Es findet sich eine Pfadangabe auf c:\ctnot, und weil die meisten Nutzer nach dem Experiment diesen Ordner nicht mehr auf der Festplatte haben, kann die winre.wim mit Windows PE nicht geladen werden.
Die Lösung wird von Peter Siering auch gleich mitgeliefert. Man muss den Registrierungseditor regedit.exe über Als Administrator ausführen mit administrativen Berechtigungen aufrufen. Dann kann man zum Schlüssel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WIMMount
navigieren. Dort findet sich der REGSZ_EXPAND_SZ-Wert ImagePath mit dem Pfad auf die .WIM. Trägt man dort System32\drivers\wimmount.sys ein, sollte der Installationsfehler 0x80070003 nicht mehr auftreten.
Anzeige
Wobei man sich da auch fragen muss:
Wenn dieser Eintrag mit dem Pfad der Datei "wimmount.sys" so absolut wichtig für das Update/ Ugrade von Windows xx ist, warum prüft ihn das Setupprogramm von Microsoft nicht und setzt ihn auf den Originalwert zurück?
Klar wären auch die Programmierer des Ct'-Notfallwindows gut beraten gewesen, wenn sie diesen Eintrag nach Nutzung des Builders zurückgesetzt hätten …
Aber Microsoft ist an dieser Stelle mindestens genauso in der Pflicht. Wozu erstellen die denn Tools wie UpgradeAdvisor, MediaCreationTool u.a. wenn diese Tools ein so grundlegendes Problem nicht erkennen.
Offensichtlich wird ja der Treiber "wimmount.sys" grundsätzlich benötigt, wenn WIM-Dateien ins Spiel kommen. Und das ist beim Windows Update/ Upgrade auf jeden Fall der Fall.
MfG P.B.
Dank diesem Artikel konnte ich (nach tagelanger Lösungssuche…) den Fehler 80070003 beheben. Jetzt bekomme ich den Fehler 0x8007007b angezeigt. Es ist zum k…
In der setuperr.log steht:
2016-08-14 11:10:44, Error MOUPG CDlpActionImpl<class CDlpErrorImpl<class CDlpObjectInternalImpl<class CUnknownImpl > > >::Suspend(1066): Result = 0xC1800104
2016-08-14 11:10:44, Error MOUPG CSetupManager::ExecutePreDownloadMode(7045): Result = 0x800705BB
2016-08-14 11:10:44, Error MOUPG CSetupManager::ExecuteDownlevelMode(383): Result = 0x800705BB
2016-08-14 11:10:44, Error MOUPG CSetupManager::Execute(236): Result = 0x800705BB
2016-08-14 11:10:44, Error MOUPG CSetupHost::Execute(372): Result = 0x800705BB
2016-08-14 11:10:46, Error MOUPG CSetupManager::CopyDynamicUpdateFiles(2330): Result = 0x80070020[gle=0x00000020]
2016-08-14 11:10:54, Error SP CSetupPlatform::ResurrectNewSystem: Cannot resurrect new system.: Win32Exception: \\?\C:\$Windows.~BT\Sources\NewSystem.dat: The system cannot find the file specified. [0x00000002] __cdecl UnBCL::FileStream::FileStream(const class UnBCL::String *,enum UnBCL::FileMode,enum UnBCL::FileAccess,enum UnBCL::FileShare,unsigned long)[gle=0x00000002]
2016-08-14 11:22:42, Error MOUPG CSetupManager::CopyDynamicUpdateFiles(2330): Result = 0x80070020[gle=0x00000020]
2016-08-14 11:34:53, Error CONX Failed hashing for syswow64\drivers\vstor2-mntapi20-shared.sys, 0x80070003
2016-08-14 11:34:53, Error CONX Failed hashing for [syswow64\drivers\vstor2-mntapi20-shared.sys] 0x80070003
2016-08-14 11:34:53, Error CONX Failed hashing for c:\windows\system32\drivers, 0x80070005
2016-08-14 11:34:53, Error CONX Failed hashing for [c:\windows\system32\drivers] 0x80070005
2016-08-14 11:34:53, Error CONX Failed hashing for \??\d:\notfallwin\projects\tools\win10pese\x64\wofadk.sys, 0x80070003
2016-08-14 11:34:53, Error CONX Failed hashing for [\??\d:\notfallwin\projects\tools\win10pese\x64\wofadk.sys] 0x80070003
2016-08-14 11:50:47, Error SP CMountWIM::DoExecute: Failed to mount WIM file C:\$WINDOWS.~BT\Sources\SafeOS\winre.wim. Error 0x8007007B[gle=0x0000007b]
2016-08-14 11:50:47, Error SP Operation failed: Mount WIM file C:\$WINDOWS.~BT\Sources\SafeOS\winre.wim, index 1 to C:\$WINDOWS.~BT\Sources\SafeOS\SafeOS.Mount. Error: 0x8007007B[gle=0x000000b7]
2016-08-14 11:50:47, Error MOUPG MoSetupPlatform: ExecuteCurrentOperations reported failure!
2016-08-14 11:50:47, Error MOUPG MoSetupPlatform: Using action error code: [0x8007007B]
2016-08-14 11:50:47, Error MOUPG CDlpActionImageDeploy::ExecuteRoutine(403): Result = 0x8007007B
2016-08-14 11:50:48, Error MOUPG CDlpActionImpl<class CDlpErrorImpl<class CDlpObjectInternalImpl<class CUnknownImpl > > >::Execute(441): Result = 0x8007007B
2016-08-14 11:50:50, Error MOUPG CDlpTask::ExecuteAction(3243): Result = 0x8007007B
2016-08-14 11:50:54, Error MOUPG CDlpTask::ExecuteActions(3397): Result = 0x8007007B
2016-08-14 11:50:54, Error MOUPG CDlpTask::Execute(1631): Result = 0x8007007B
2016-08-14 11:50:56, Error MOUPG CSetupManager::ExecuteTask(2067): Result = 0x8007007B
2016-08-14 11:50:56, Error MOUPG CSetupManager::ExecuteTask(2030): Result = 0x8007007B
2016-08-14 11:50:56, Error MOUPG CSetupManager::ExecuteInstallMode(815): Result = 0x8007007B
2016-08-14 11:50:56, Error MOUPG CSetupManager::ExecuteDownlevelMode(391): Result = 0x8007007B
2016-08-14 11:51:10, Error SP CDeploymentBase::CleanupMounts: Unable to unmount the directory C:\$WINDOWS.~BT\Sources\SafeOS\SafeOS.Mount. Error: 0xC142011C[gle=0xc142011c]
2016-08-14 11:51:39, Error MOUPG CSetupManager::Execute(236): Result = 0x8007007B
2016-08-14 11:51:39, Error MOUPG CSetupHost::Execute(372): Result = 0x8007007B
Scheinbar hat sich dieses NotfallWin auch noch woanders niedergelassen… Als nächstes Suche ich restlichen Registry-Einträge…
So! :-). Es lag bei mir auch an dem c't Notfallwin, was ich irgendwann mal ausprobiert hatte… Nur musste ich nicht nur wie in diesem Artikel beschrieben, den einen Wert in der Registry unter
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WIMMount
ändern. Erst nachdem ich von einem anderen Win10-PC den ganzen Zweig (mit allen Untereinträgen) ex- und bei mir wieder importiert hatte, hat das Upgrade auch geklappt. Nur so als Tipp ;-).
Hallo Paulchen Panther,
was genau meisnt Du mit dem "ganzen Zweig (mit allen Untereinträgen)"?
In einem anderen Windows 10-System regedit.exe starten, zu HKLM\…. navigieren, dann unter Datei – Exportieren die Einträge in eine .reg-Datei speichern lassen. Die reg-Datei auf den betreffenden Windows 10-Rechner kopieren, regedit.exe über Als Administrator ausführen wieder starten und über Datei – Importieren die Einträge aus der .reg-Datei einlesen lassen. Das war das, war er gemacht hat.
Hallo Günther o. Martha,
danke für die schnelle Antwort! Das mit dem Exportieren und Importieren hatte ich schon verstanden. Nicht verstanden habe ich, ob der gesamte "Zweig" HKEY_LOCAL_MACHINE importiert werden soll, oder nur ein Teil davon (etwa: HKEY_LOCAL_MACHINE\SYSTEM oder gar nur HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet).
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WIMMount
Danke! Import in Registry hat geklappt – und dann endlich auch das Update auf Windows Version 1607!!!
Nachdem mich der Beitrag hier auf den Lösungsweg gebracht hat – es aber mit der Korrektur des einen Registry-Eintrags nicht getan war – hier eine kleine Ergänzung:
Nach der Korrektur von
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WIMMount
gab es bei mir noch einen weiteren durch das c't Notfallsystem verbogenen Registry-Eintrag. setuperr.log hatte noch folgende Einträge:
Error CONX Failed hashing for \??\c:\ctnotwin\projects\tools\win10pese\x64\wofadk.sys, 0x80070003
Error CONX Failed hashing for [\??\c:\ctnotwin\projects\tools\win10pese\x64\wofadk.sys] 0x80070003
Entsprechend brach das Upgrade ab.
Nach ein wenig Recherche habe ich dann herausgefunden, dass wofadk.sys unter C:\Windows\System32\DRIVERS liegen sollte. Bei meinem System gab es diese Datei allerdings nicht. Habe dann noch weiter recherchiert und kam zu der ziemlich starken Vermutung, dass diese Datei nur von WinPE benötigt wird. Habe dann folgende Schritte durchgeführt, die letztlich zum Erfolg führten:
1. Wiederherstellungspunkt erstellen
2. mittels regedit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WofAdk ansteuern, dann diesen Schlüssel erstens komplett exportieren und zweitens komplett löschen
3. Neustart – auch jetzt brach das Upgrade wieder mit Fehlermeldungen ab, daher:
4. Eingabeaufforderung (als Admin) starten und folgende Befehle ausführen:
sfc /scannow
DISM.exe /online /cleanup-image /restorehealth
ipconfig /release
ipconfig /renew
ipconfig /flushdns
ipconfig /registerdnsnetsh firewall reset
netsh int ip reset
netsh winsock reset
netsh interface tcp set global autotuning=disabled
(siehe auch https://answers.microsoft.com/de-de/windows/forum/windows_10-update/probleme-beim-installieren-von-updates/5a121d3f-a0eb-4a44-8afc-0059f62c6e82?tm=1466684952287&auth=1)
5. Neustart
Danach lief das Upgrade bei mir problemlos durch. Was von den Befehlen in der Eingabaufforderung wirklich notwendig war und was davon Windows-Voodoo, weiß ich offen gestanden nicht. Es hat aber geholfen… ;-) Nervig war dann nur, das Win10 mit dem Upgrade ungefragt Fastboot wieder aktiviert hat. Das hätte wieder Probleme mit meinem primären OS gegeben, hätte ich das unter Win10 nicht direkt geprüft und wieder deaktiviert.