16
Windows 10 "INACCESSIBLE BOOT DEVICE" nach KB4041676 oder KB4041691
Hallo,
Da uns bei dem gestrigen Windows 10 Update sämtliche Installationen um die Ohren geflogen sind. Betroffen sind hier bei uns die Versionen 1607 mit Professional und Enterprise. LTSB haben wir nicht daher kann ich es hier nicht sagen ob das Problem auftritt. Es betrifft bei uns auch nicht alle Geräte mit Windows 10 nur die Geräte mit Version 1607. 1703 scheint zufunktionieren.
Die meisten Geräte waren von Dell Serien: Optiplex 5050, Mobile Workstation P7710, Latitude 5580.
Virenscanner ist bei uns McAffee im Einsatz mit Agent und McAffee VirusScan Enterprise Version 8.8.0
Betroffen ist das KB4041676 vom gestrigen Oktober Patchday. Wir haben bei unserem WSUS die Verteilung gestoppt. Bei Clients welche nicht in der Domäne sind den UpdateDienst deaktiviert.
Um das System wieder in gang zu bekommen ist keine Wiederherstellung notwendig. Funktioniert auch mit der Windowswiederherstellung nicht.
Mann muss bei dem betroffen Windows in den Reperaturmodus gehen ->Problembehandlung->Eingabeaufforderung.
Hier mit DISKPART der System Partition den Laufwerkbuchstaben C zuweisen.
Diskpart verlassen
Und folgende 4 Befehle ausführen:
Ich habe mir das ganze in eine Batchfile geschrieben welche ich von einem angeschlossenen USB-Stick starte.
Hoffe ich konnte euch helfen.
Gruß Niklas
Da uns bei dem gestrigen Windows 10 Update sämtliche Installationen um die Ohren geflogen sind. Betroffen sind hier bei uns die Versionen 1607 mit Professional und Enterprise. LTSB haben wir nicht daher kann ich es hier nicht sagen ob das Problem auftritt. Es betrifft bei uns auch nicht alle Geräte mit Windows 10 nur die Geräte mit Version 1607. 1703 scheint zufunktionieren.
Die meisten Geräte waren von Dell Serien: Optiplex 5050, Mobile Workstation P7710, Latitude 5580.
Virenscanner ist bei uns McAffee im Einsatz mit Agent und McAffee VirusScan Enterprise Version 8.8.0
Betroffen ist das KB4041676 vom gestrigen Oktober Patchday. Wir haben bei unserem WSUS die Verteilung gestoppt. Bei Clients welche nicht in der Domäne sind den UpdateDienst deaktiviert.
Um das System wieder in gang zu bekommen ist keine Wiederherstellung notwendig. Funktioniert auch mit der Windowswiederherstellung nicht.
Mann muss bei dem betroffen Windows in den Reperaturmodus gehen ->Problembehandlung->Eingabeaufforderung.
Hier mit DISKPART der System Partition den Laufwerkbuchstaben C zuweisen.
Diskpart verlassen
Und folgende 4 Befehle ausführen:
mkdir c:\temp
dism /image:c:\ /get-packages
dism /image:c:\ /remove-package /packagename:Package_for_RollupFix_Wrapper~31bf3856ad364e35~amd64~~14393.1770.1.6 /scratchdir:c:\temp
dism /image:c:\ /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~14393.1715.1.10 /scratchdir:c:\temp
dism /image:c:\ /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~14393.1770.1.6 /scratchdir:c:\tempIch habe mir das ganze in eine Batchfile geschrieben welche ich von einem angeschlossenen USB-Stick starte.
Hoffe ich konnte euch helfen.
Gruß Niklas
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 351536
Url: https://administrator.de/contentid/351536
Printed on: April 19, 2024 at 22:04 o'clock
16 Comments
Latest comment
Hi.
Beileid. Da es hier nicht passiert ist - könntest Du eine Liste mit hardwarenaher Software (Verschlüsselung, AV-Software, Virtualisierer) machen, die Ihr auf den betroffenen verwendet?
Und ebenso noch die Windowsversion (1607/1703 - oder haben bei Euch alle 14393=1607?)
Beileid. Da es hier nicht passiert ist - könntest Du eine Liste mit hardwarenaher Software (Verschlüsselung, AV-Software, Virtualisierer) machen, die Ihr auf den betroffenen verwendet?
Und ebenso noch die Windowsversion (1607/1703 - oder haben bei Euch alle 14393=1607?)
Habe ich ergäntzt
Danke. 1607er haben wir nur noch genau 3 - ich werde berichten, wenn ich deren Installation geprüft habe.
Siehe https://support.microsoft.com/en-us/help/4049094/windows-devices-may-fai ...
Die Details sind wirklich interessant...
Die Details sind wirklich interessant...
Wobei, wenn man sich den Chart hier anschaut, dürfte das KB4041676 gar nicht auf 1607 ausgerollt werden, bzw. gar nicht verfügbar sein. Wobei MS ja mittlerweile schreibt, dass es auch KB4041691 betrifft, also die 1607er Variante.
Die Client-Versionen sind meiner Meinung nach gar nicht mal so schlimm, aber das es gleichzeitig den SRV 2016 betrifft, ist schon ein dickes Ding.
Die Client-Versionen sind meiner Meinung nach gar nicht mal so schlimm, aber das es gleichzeitig den SRV 2016 betrifft, ist schon ein dickes Ding.
"das es gleichzeitig den SRV 2016 betrifft, ist schon ein dickes Ding" - mach Dir bewusst, dass die CU-Updatedateien für beide OS' (Server 2016 RTM und Win10 v1607) die selben sind - jeden Monat.
Zitat von @DerWoWusste:
"das es gleichzeitig den SRV 2016 betrifft, ist schon ein dickes Ding" - mach Dir bewusst, dass die CU-Updatedateien für beide OS' (Server 2016 RTM > und Win10 v1607) die selben sind - jeden Monat.
"das es gleichzeitig den SRV 2016 betrifft, ist schon ein dickes Ding" - mach Dir bewusst, dass die CU-Updatedateien für beide OS' (Server 2016 RTM > und Win10 v1607) die selben sind - jeden Monat.
Das ist klar und es bestätigt diesen Monat wieder, dass es ein unfassbar hohes Risiko ist.
@niklasschaefer:
Danke für die Anleitung.
Leider war ich betroffen (nur an den W2K16-Servern, W10-Clients mit Build 1607 haben wir zum Glück nicht mehr, alle schon auf 1703), und zwar durch Leichtsinn:
- automatische Genehmigungsregel WSUS für alle Updates
- GPO für WU per WSUS stand auf der Stufe, die automatisch installiert
Diskpart ist hier unnötig, man muß nur feststellen, welchen LW-Buchstaben die Windows-Systemplatte aus PE-Sicht hat (bei meinen Servern war es zum Beispiel D:\).
Den Schalter /scratchdir braucht es auch nicht zwingend, da geht's nur um die Performance des Remove-Vorganges, das Entfernen geht dadurch etwas schneller, es geht aber auch ganz ohne Scratchdir.
Die anschließenden Reboots haben bei den meisten Maschinen mehr als eine Viertelstunde gedauert, ich hatte erst Zweifel, ob die Methode funktioniert, es funktionierte dann aber. Ein virtueller W2K16 hat seine Netzwerkconfig verloren, das war aber flink wieder eingestellt.
Aber trotzdem vielen, vielen Dank für die sonstigen Befehle, das war die Rettung!
Nochmals danke.
Viele Grüße
von
departure69
P.S.: Ich frage mich, ob Microsoft mal wieder einen Praktikanten in der ersten Praktikumswoche an den Deploy-Server gelassen hat, der sich die zu veröffentlichenden Pakete aussuchen durfte. Nach dem Motto: So, Kaffeekochen haste jetz' gelernt, als nächstes Deployen wir mal Windows-Updates an die Welt.
Das so etwas überhaupt passieren kann, ist unfassbar. Ist aber irgendwie auch nicht das erste mal, wenn ich mich recht erinnere, wobei ich bislang nie betroffen war. Meine GPO ist schon überarbeitet, da passiert jetzt auf den Servern nix mehr automatisch.
Danke für die Anleitung.
Leider war ich betroffen (nur an den W2K16-Servern, W10-Clients mit Build 1607 haben wir zum Glück nicht mehr, alle schon auf 1703), und zwar durch Leichtsinn:
- automatische Genehmigungsregel WSUS für alle Updates
- GPO für WU per WSUS stand auf der Stufe, die automatisch installiert
Diskpart ist hier unnötig, man muß nur feststellen, welchen LW-Buchstaben die Windows-Systemplatte aus PE-Sicht hat (bei meinen Servern war es zum Beispiel D:\).
Den Schalter /scratchdir braucht es auch nicht zwingend, da geht's nur um die Performance des Remove-Vorganges, das Entfernen geht dadurch etwas schneller, es geht aber auch ganz ohne Scratchdir.
Die anschließenden Reboots haben bei den meisten Maschinen mehr als eine Viertelstunde gedauert, ich hatte erst Zweifel, ob die Methode funktioniert, es funktionierte dann aber. Ein virtueller W2K16 hat seine Netzwerkconfig verloren, das war aber flink wieder eingestellt.
Aber trotzdem vielen, vielen Dank für die sonstigen Befehle, das war die Rettung!
Nochmals danke.
Viele Grüße
von
departure69
P.S.: Ich frage mich, ob Microsoft mal wieder einen Praktikanten in der ersten Praktikumswoche an den Deploy-Server gelassen hat, der sich die zu veröffentlichenden Pakete aussuchen durfte. Nach dem Motto: So, Kaffeekochen haste jetz' gelernt, als nächstes Deployen wir mal Windows-Updates an die Welt.
Das so etwas überhaupt passieren kann, ist unfassbar. Ist aber irgendwie auch nicht das erste mal, wenn ich mich recht erinnere, wobei ich bislang nie betroffen war. Meine GPO ist schon überarbeitet, da passiert jetzt auf den Servern nix mehr automatisch.
@departure: Ich zweifle daran, dass Microsoft überhaupt noch mit WSUS testet. Ich denke, die nutzen selbst nur SCCM.
Schon der Bug mit win10 v1607 und Server 2016, die beide RTM nicht einmal fehlerfrei mit WSUS kommunizieren können, legt das nahe.
Schon der Bug mit win10 v1607 und Server 2016, die beide RTM nicht einmal fehlerfrei mit WSUS kommunizieren können, legt das nahe.
Moin,
ich wollte nur kurz berichten, dass ich 3 Windows Clients habe die das betrifft.
Bei 2 Kunden verteilt. Alle anderen von deren PCs die zum gleichen Zeitpunkt gekauft wurden, tritt das Problem nicht auf.
Auch nicht gleichzeitig. Verteilt über 3 Tage.
Welche Version kann ich nur bedingt sagen.
Kein WSUS. Direkte Windows Updates
Microsoft Windows 10 Pro Professional, 64-bit (build 14393)
DISM hat nicht funktioniert.
Ich setzte das System auf einen Wiederherstellungspunkt zurück.
Stefan
ich wollte nur kurz berichten, dass ich 3 Windows Clients habe die das betrifft.
Bei 2 Kunden verteilt. Alle anderen von deren PCs die zum gleichen Zeitpunkt gekauft wurden, tritt das Problem nicht auf.
Auch nicht gleichzeitig. Verteilt über 3 Tage.
Welche Version kann ich nur bedingt sagen.
Kein WSUS. Direkte Windows Updates
Microsoft Windows 10 Pro Professional, 64-bit (build 14393)
DISM hat nicht funktioniert.
Ich setzte das System auf einen Wiederherstellungspunkt zurück.
Stefan
Na super
Systemwieherstellung an PC1: OK
an PC2 und PC3: 0x80070091
Ich stelle mir gerade vor wenn das jetzt bei 200 PCs passiert....
Stefan
Systemwieherstellung an PC1: OK
an PC2 und PC3: 0x80070091
Ich stelle mir gerade vor wenn das jetzt bei 200 PCs passiert....
Stefan
@StefanKittel:
Sicher, daß das der gleiche Auslöser war, auf den sich der ursprüngliche Thread bezog? Hätte ohne WSUS eigentlich nicht passieren dürfen. "Normal"- und Privatanwender, eben die ohne WSUS, hatten dieses Problem eigentlich nicht. Egal mit welcher Version. Und meine/unsere 1703-Clients mit WSUS auch nicht, da sollen nur die 1607er mit WSUS betroffen gewesen sein.
Irgendwie klingen Deine Beschreibungen nach was anderem, ich weiß alerdings leider auch nicht, nach was
.
Viele Grüße
von
departure69
Sicher, daß das der gleiche Auslöser war, auf den sich der ursprüngliche Thread bezog? Hätte ohne WSUS eigentlich nicht passieren dürfen. "Normal"- und Privatanwender, eben die ohne WSUS, hatten dieses Problem eigentlich nicht. Egal mit welcher Version. Und meine/unsere 1703-Clients mit WSUS auch nicht, da sollen nur die 1607er mit WSUS betroffen gewesen sein.
Irgendwie klingen Deine Beschreibungen nach was anderem, ich weiß alerdings leider auch nicht, nach was
.Viele Grüße
von
departure69
Moin,
sicher bin ich mir nicht, aber 3 Windows PCs zeigen gleichzeit am Donnerstag Morgen ein "INACCESSIBLE BOOT DEVICE".
Das hatte ich so, ohne Hardwaredefekt, sehr lange nicht mehr.
Daher vermute ich einen Zusammenhang.
Stefan
sicher bin ich mir nicht, aber 3 Windows PCs zeigen gleichzeit am Donnerstag Morgen ein "INACCESSIBLE BOOT DEVICE".
Das hatte ich so, ohne Hardwaredefekt, sehr lange nicht mehr.
Daher vermute ich einen Zusammenhang.
Stefan
Hier eine Hilfestellung von MS
https://support.microsoft.com/en-us/help/4049094
Die PCs hier wurden durch ein Patchmanagement eines 3. Herstellers verseucht.
https://support.microsoft.com/en-us/help/4049094
Die PCs hier wurden durch ein Patchmanagement eines 3. Herstellers verseucht.
Aha.
Also, auf Umwegen, doch eine Art WSUS. Die eigenen Patchmanagementlösungen, die z. B. bei Softwareverteilsystemen von Drittherstellern im Einsatz sind, machen nämlich nichts anderes als der WSUS, sie greifen auf den Windows Update Catalog zu ...
Aber daß trotzdem dism bei Dir nichts brachte? Ich habe 3 W2K16-Server nach der obigen Anleitung wieder auf Spur gebracht.
Viele Grüße
von
departure69
Also, auf Umwegen, doch eine Art WSUS. Die eigenen Patchmanagementlösungen, die z. B. bei Softwareverteilsystemen von Drittherstellern im Einsatz sind, machen nämlich nichts anderes als der WSUS, sie greifen auf den Windows Update Catalog zu ...
Aber daß trotzdem dism bei Dir nichts brachte? Ich habe 3 W2K16-Server nach der obigen Anleitung wieder auf Spur gebracht.
Viele Grüße
von
departure69
Microsoft schreibt doch deutlich, dass die "inaccessible boot device"-Probleme nur bei Leuten auftreten dürften, die Express-Updates verwenden.
Prüft das mal.
Prüft das mal.
