[English]Im aktuellen Blog-Beitrag greife ich den Fall eines Blog-Lesers auf, der mit einem Windows 10 Pro-System (Medion-Hardware) vor dem Problem stand, dass die monatlichen kumulativen Updates scheiterten. Es wurde der Fehler 0x80073701 gemeldet. Der Versuch, über ein USB-Installationsmedium Windows 10 Pro in aktueller Fassung zu installieren, endete mit dem Fehler 0x8007025D. Am Ende des Tages hat der Blog-Leser die Ursache gefunden – es waren fehlende Updates des Intel Grafiktreibers, die manuell nachgeholt wurden und endlich die Update-Installationsfehler beseitigten.
Anzeige
Ich bereite den Fall mal chronologisch auf, vielleicht hilft er dem einen oder anderen Betroffenen in ähnlichen Szenarien weiter. Denn an Hand der beschriebenen Installationsfehler wäre ich vermutlich in die falsche Richtung geleitet worden (ich muss vorsichtig sein, denn ich hatte das System ja nicht in den Fingern und muss mit den Details auskommen, die mir per Kommentar vorliegen). An dieser Stelle auf jeden Fall mein Dank an den Blog-Leser, dass er mir die Informationen zukommen ließ. So habe ich wenigstens eine Möglichkeit, das ein wenig aufzubreiten.
Upgrade wirft Installationsfehler 0x80073701
Bereits im April 2021 hatte der Blog-Leser einen Kommentar zum Beitrag Windows 10: Fix für Grafikprobleme bei Spielen nach April-Update gepostet, in dem er sich über den Fehler 0x80073701 bei den monatlichen kumulativen Updates beklagte.
Mein Notebook hat keine Grafikkarte von Nvidia, einzig eine Intel OnBoard-Grafik. Trotzdem bricht seit der Veröffentlichung am April-Patchday das kumulative Update KB5001330 nach längerem Installationsversuch mit Verweilen bei 20%, 44% und 100% mit dem Fehlercode 0x80073701 ab. Zu aktualisieren wäre Windows 10 Pro x64 20H2 (19042.867). Leider sind im Netz und in den Foren nur Hinweise auf das kurzzeitige Deaktivieren von Anti-Virensoftware zu finden, was beim einzig installierten Microsoft Defender nicht zum Ziel führte.
Hätten Sie eine Idee, wo die Ursache zu suchen wäre?
Ich lese zwar alle Kommentare, die hier im Blog eintreffen. Auf die Frage im letzten Satz hatte ich aber adhoc überhaupt keine Idee, und habe in diesem Fall daher auch nicht geantwortet. Auch die Tage danach kam mir nichts unter die Augen, was irgend eine Erkenntnis der Art "suche mal in dieser Richtung" bedingt hätte.
Der Fehlercode 0x80073701 steht für ERROR_SXS_ASSEMBLY_MISSING, d.h. Windows findet bei der Update-Installation eine Assembly-Datei im Ordner WinSxS nicht mehr, die für das betreffende Paket gebraucht wird. In diesem Ordner legen viele Programme ihrer Bibliotheksdateien ab. Fehlt da ein Bezug, der in der Registrierung vorhanden ist, wird der obige Fehler ausgeworfen.
Anzeige
Der Fehler 0x80073701 tritt bei Updates häufiger auf und ich hatte das im Blog-Beitrag Windows 10 V1903: Installationsfehler mit Update KB4512508 aufgegriffen. Der erste Ansatz wäre, die im Blog-Beitrag Windows 8: Komponentenstore reparieren beschriebenen Ansätze zu probieren, um Windows 10 mit dism reparieren zu lassen. Wird aber meistens nicht weiter helfen, und man könnte höchstens versuchen, Dateien wie die cbs.log auszuwerten, um ggf. näheres herauszufinden. Meist wird dann aber eine Neuinstallation fällig.
Windows 10 Pro-Installation scheitert
Die Idee einer Neuinstallation oder einer Reparatur per Inplace-Upgrade (Windows 10 über die bestehende Installation installieren) scheiterte aber. Denn der Blog-Leser meldete sich im Juni 2021 zum Blog-Beitrag Windows 10 Pro: Installation auf OEM-Maschinen aus dem Jahr 2015 mit dem nachfolgenden Kommentar:
Hallo,
könnte es sein, daß die oben beschriebenen Vorgehensweisen neuerdings nicht mehr funktionieren? Auf meinem ursprünglich mit Windows 10 Home ausgelieferten Notebook hatte ich, da damals der 7 Pro-Key noch nicht direkt eingebbar war, Windows 7 Pro installiert und im Anschluß die erfolgreiche Migration auf 10 Pro inkl. Aktivierung durchgeführt. Seit einigen Monaten scheitern auf diesem Rechner regelmäßig die monatlichen kumulativen Updates.
Beim jetzigen Versuch, mittels eines per Media Creation Tool erzeugten USB-Sticks mit Windows 10 Pro ebenjenes auf einer jungfräulichen Festplatte zu installieren, scheinen sowohl ei.cfg als auch pid.txt ignoriert zu werden, da angeblich erforderliche Dateien nicht verfügbar seien (0x8007025D). Der Stick wurde übrigens auf diesem und für diesen Rechner erzeugt und enthält „nur" die Pro-Version.
Der Fehlercode 0x8007025D steht für ERROR_BAD_COMPRESSION_BUFFER, irgend etwas ist mit dem Installationsmedium bzw. mit dem Entpacken der betreffenden Daten fehlerhaft. An diesem Punkt ist man natürlich aufgeschmissen, weshalb ich auch nichts dazu geschrieben hatte.
Das Einzige, was ich noch probiert hätte, wäre die ISO-Datei unter Windows 10 zu mounten und dann über die setup.exe ein Inplace-Upgrade zu versuchen. Alternativ wäre noch die Möglichkeit, den Inhalt der ISO-Datei nach dem Mounten in einen lokalen Ordner zu kopieren, um dann eine ei.cfg oder pid.txt hinzuzufügen. Ob dann die Installation klappt, kann ich aktuell nicht beurteilen.
Die Auflösung der Fehlerursache
Der Blog-Leser stand natürlich vor dem Problem, dass jeden Monat ein kumulatives Update bei der Installation scheiterte. Vor einigen Tagen ist er dann aber auf die Ursache für seine Update-Installationsfehler gestoßen. Unter dem Titel Ursache von Update-Problemen gefunden erreichte mit die Tage eine Mail mit folgendem Inhalt.
Hallo Herr Born,
in den letzten Monaten habe ich zwei Mal Beiträge zu verschiedenen Blogeinträgen verschickt. Heute möchte ich Ihnen die Ursache mitteilen, über die evtl. auch andere Anwender stolperten.
Mindestens seit März'21 konnte ich Windows 10 Pro (64bit) auf einem Medion Akoya-Notebook mit Core i3-6100U und integrierter Grafikkarte (HD Graphics 520) nicht aktualisieren. Das kumulative Updatepaket scheiterte regelmäßig mit einem nicht weiterhelfenden Fehlercode.
Letztendlich stellte sich heraus, daß Intel im November'20 eine neue Treiberversion (21.20.16.5174 vom 08.11.2020) für integrierte Grafikeinheiten, u.a. des oben genannten Prozessors, veröffentlichte, die zumindest auf meinem System nicht über Windows Update verteilt wurde.
Nach Installation dieses auf der offiziellen Supportseite von Intel zu findenden Treibers aktualisierte sich Windows wieder selbstständig. Ebenso verlief das Upgrade auf 21H1 erfolgreich.
Auch wenn ich Ihren Blog nur unregelmäßig besuche, möchte ich Sie zu Ihrem Blog beglückwünschen, der – wie Ihre Beiträge auf heise online – eine gewisse Seriosität ausstrahlt und oftmals Hintergrundwissen vermittelt, was auch Nicht-ITlern nützt.
Schönen Sonntag und "weiter so"
Das ist natürlich eine überraschende Lösung – hier im Blog gibt es zwar immer mal wieder Beiträge, die sich mit Update-Problemen und Grafiktreibern befassen (siehe z.B. Windows 10 V1903: KB4517389 verursacht Probleme mit Intel Grafiktreiber). Aber die hier skizzierte Ursache liegt nicht direkt auf der Hand. Möglicherweise hätte eine Analyse der cbs.log-Protokolldaten weiter geholfen, sofern ein Verweis auf die Intel-Grafiktreiber enthalten war (siehe Windows 8.1 Update: Fehleranalyse per CBS.log). Dazu ist die CBS.log im Ordner C:\Windows\Logs\CBS auf den Desktop zu kopieren und in einem Editor zu öffnen. Dann lassen sich die Einträge durchgehen und die Zeilen mit dem Fehlercode suchen. Manchmal findet sich ein Hinweis, welche Dateien bemängelt werden.
Ergänzungen des Blog-Lesers
In obigem Text habe ich einige Hinweise zur generellen Fehlersuche in solchen Fällen gegeben. Der Blog-Leser hatte Gelegenheit, diesen Text vorab zu lesen und schickte mir noch einige Anmerkungen. Diese stelle ich einfach zur Information hier ein. Der Leser lieferte die nachfolgenden Ergänzungen zu meinen obigen Vermutungen und Lösungsansätzen:
Die Sache mit dem dism-Befehl hatte ich zwischenzeitig erfolglos probiert.
Das Logfile habe ich zwar im Editor öffnen können, aber die Zeilen mit den Fehlermeldungen deuteten nicht auf die Grafiktreiberproblematik hin.
Der Versuch bei laufendem Windows mittels MCT-Stick eine Reparaturinstallation durchzuführen, scheiterte ebenfalls mehrfach mit dem nichtssagenden Fehlercode ("riesiger" Zeitaufwand für die Installation zuzüglich "ewiger" Zeit zur Rückabwicklung).
Meine Idee, die letzten erfolgreich installierten Updates (inkl. dem Upgrade auf 20H2) nach und nach zu deinstallieren, führte einzig dazu, daß ich ein paar Monate "nur" 20H1 auf dem Rechner hatte …
Letztendlich habe ich die SSD mit der fehlerhaften Windows-Installation und die Daten-Festplatte ausgebaut und durch eine leere Festplatte ersetzt. Auf diese habe ich mittels eines MCT-Sticks Windows 10 Home(!) 21H1 installiert, welches sich selbstständig aktivierte und aktualisierte, inklusive des neuesten kumulativen Updates. Nur die Grafik sah bescheiden aus … was auch der Geräte-Manager meinte.
Da weder die Windows-eigene Update-Funktion noch die Problembehandlung einen passenden Treiber auf dem Rechner bzw. im Internet finden wollten, machte ich mich auf der Intel-Seite auf die Suche. Mit bekanntem Ergebnis …
Der Rückbau und das händische Einspielen des Grafiktreibers in der Pro-Installation bewegten dann auch die Update-Funktion wieder zur Mitarbeit, so daß sich zwischenzeitlich das kumulative Juli-Update fehlerfrei installierte.
Mit den Ergänzungen wird jetzt ein Schuh draus – es kann schon recht aufwändig werden, einen solchen Fehler einzukreisen und auszumerzen, wie der Fall zeigt.
Ähnliche Artikel:
Windows 8: Komponentenstore reparieren
Windows 10: Fix für Grafikprobleme bei Spielen nach April-Update
Windows 10 Pro: Installation auf OEM-Maschinen
Windows 10 V1903: KB4517389 verursacht Probleme mit Intel Grafiktreiber
Windows 8.1 Update: Fehleranalyse per CBS.log
Windows 10: Fehler 0x800f0988/0x800f0900 bei KB4551762
Windows 7: CBS.log-Bug müllt Festplatte voll
Anzeige
Der Fehler 0x8007025D kann aber auch auf einen Hardware defekt hindeuten wie z.B.:
Defekte Sektoren bei einer HDD.
Defekter Speicherbereich auf einer SSD.
Defekter Speicherbereich im RAM (Arbeitsspeicher).
Defekter Speicherbereich auf dem USB Stick.
Bei diesem Fehler gibt es viele Möglichkeiten wo es klemmen kann.
Intel Treiber sollte man mit dem Intel Driver Update Utility aktualisieren, wenn ein Update verfügbar ist wird das in der Taskleiste angezeigt. Für WLAN und Bluetooth gibts alle paar Wochen neue Treiber, Grafiktreiber werden seltener aktualisiert.
Funktioniert leider nicht zuverlässig. Ich habe letztens irgendwo gelesen, dass es neue Bluetooth und WLAN Treiber gibt, das Intel Driver Update Utility im Systray angeklickt, es checkt über die Intel-Seite nach Updates und behauptet mein X360 wäre von HP und dafür gibts keine neuen Treiber – dass Intel-Treiber installiert sind, hat es richtig erkannt. Treiber manuell runtergeladen, installiert, klappt. Bei Dell häufig das selbe Drama.
Ist auch mein Informationsstand – abgeleitet von den Erfahrungen von Blog-Leser Karl. Wurde auch schon an Intel herangetragen, Erfolg gleich Null.
Die Grafiktreiber waren ein Problem, hab ich selber erlebt. Intel Driver Update Utility meldet neuen Grafiktreiber, bei der Installation Fehlermeldung nicht für diese Hardware geeignet, man solle beim Hersteller schauen, dort gibts aber nichts.
Letzes Jahr haben sich Intel und die OEM-Hersteller endlich zusammengerauft, Artikel von Martin Geuss mit dem Hinweis auf das Intel Driver Update Utility:
Endlich: Update der Intel-Grafiktreiber unabhängig vom Hersteller möglich
https://www.drwindows.de/news/endlich-update-der-intel-grafiktreiber-unabhaengig-vom-hersteller-moeglich
Au weia, wieder nichts mit der Idee einer zentralen Stelle (Microsoft Update), die sich um Treiber-Updates kümmert. Intel-Komponenten sind ja irgendwie doch nicht sooo wenig verbreitet, dass man sagen könnte: Für derart exotischen Kram müsst ihr schon ein eigenes Tool des Herstellers installieren.
Jedes Programm, das ständig im Hintergrund nach Hause telefoniert, ist ein Sicherheitsrisiko. Und speziell mit Intels Hilfsprogrämmchen hat man schon haarsträubende Dinge erlebt: von groben Fehldiagnosen bis zu missglückter Deinstallation, nach der es bei jedem Systemstart Fehlermeldungen hagelt.
Anscheinend ist man bei Intel der Ansicht dass Microsoft das mit den Treiber-Updates nicht hinbekommt, was ich bestätigen kann.
Das stimmt schon, mir geht das auch auf die Nerven, wenn ich so sehe, was da alles für Udate-Dienste laufen
– Windows-Update (muss sein)
– Google Update (für Chrome, Drivem Earth, …)
– Update-Dienst von Firefox
– Update-Dienst von Dropbox
– Intel Treiber Update Dienst
– OneDrive Hintergrundaktualisierung
– Teams Hintergrundaktualisierung
– Office 365 Hintergrundaktualisierung
– Windows Store
– iCloud Update Dienst
usw. das sind jetzt nur mal die gängigsten. Auf der Seite hat Linux tatsächlich mit apt/yum/… was vorraus, aber wie diese Nennung aufzeigt, es ist auch schon wieder nicht mehr einheiltlich. Aber etwas Besserung ist in Sicht, man installiere sich mal WinGet, auch wenn das nun schon Update-Dienst Nummer 6 von Micrsoft ist, und richte einen Task in der Aufgabenplanung ein, "winget upgrade –all –silent", das deckt inzwischen schon vieles ab, aber eben auch noch nicht alles, weil viele Softewarehersteller dieses Tool noch nicht entdeckt haben oder falsch verstehen "Das ist doch nur für Store-Apps" – "Nein!". "Nein!". "Nein!". Und nochmals "Nein!".
Was mir letztens sauer aufgestoßen ist, ist dass Windows (zumindest 20H2) nach Aktivierung KEINE Treiber mehr automatisch nachinstalliert!
Das muss man jetzt manuell via optionale Updates nachholen, oder via Powershell.
Das scheint wohl Hand in Hand mit der Bereitstellung von Firmware einhergegangen sein.
Find ich jetzt nich so nett, weil der unbedarfte 0815 user so sicher bald nach neuinstallation über nicht mehr nutzbare Hardware klagen wird.
Vorsicht vor diesen optionalen Updates! Auf unserer Win 10 Kiste sind dort mehrere Einträge für Firmware und Treiber enthalten, es ist nicht ersichtlich für welche Geräte diese Firmware oder Treiber gedacht sind, also Finger weg.
Wie ich bereits im Beitrag weiter oben geschrieben habe sollte man für Intel Treiber das Intel Driver Update Utility benutzen, Firmware Updates gibts beim Hersteller der Hardware.
Die Hersteller der Hardware veröffentlichen genau diese FirmwareUpdates via Microsoft. Eigentlich eine gute Sache!
Die Frage ist halt nur, was ist, wenn z.b. ein BIOS Update das Mainboard schrottet? Haben wir…
Was ist, wenn hunderte Rechner plötzlich für das BIOS upgrade ein Passwort wollen und stecken bleiben? Haben wir…
Wer trägt hier den Schaden der entsteht? Ich prophezeie hier durchaus den einen oder anderen Rechtsstreit.
Eine Passwortabfrage bei BIOS-Updates habe ich noch nie beobachtet, wir machen das recht regelmäßig bei vielen DELL-Systemen. Was passieren kann, ist gelegentlich die Abfrage des Bitlocker-Keys, aber das lässt sich ja verhindern.
Bei uns hat es etwas älter HP Elitedesk 800 G3 getroffen. Hier hat HP irgendwann im BIOS einen Switch für das BIOS Update aus dem OS heraus integriert. Trifft nun ein neues Update auf einen Rechner der das noch nicht kennt, weil BIOS zu alt, bleibt man schön im BIOS Passwort prompt picken.
Unschöne Szenen…
Ich verlinke dann mal. Das Thema war ja im Blog-Beitrag https://www.borncity.com/blog/2021/07/09/nderungen-und-unklarheiten-bei-treiber-updates-ber-wsus-zieht-windows-10-update-am-wsus-vorbei/ angesprochen worden.
Ich weiß nicht, wo dieser Irrglaube her kommt. Treiber, die installiert werden, die aber nicht aktiviert werden, weil die Hardware nicht da ist, sind erstmal irrelevant. Aber es ist neuerdings wieder gut, dass sie da sind, nämlich, wenn man die Platte mal an ein anderes System dran hängt. Dann nämlich bekommen diese Treiber Relevanz, wenn nämlich dann genau diese Hardware da ist. Und ja, Windows 10 lässt sich an andere Hardware umhängen. Seit Windows 2000 sind wir das nicht mehr gewohnt, machte man das z.B. mit XP oder 7, so quittierte meistens der Boot-Prozess mit "illegal Boot device" Bluescreen. Aber Windows 10 erkennt die Verhänderung in der Hardware, nennt sich "Plug and Play", und sucht sich aus seinem Bestand zusammen, was es braucht, und lädt sogar automatisch aus dem Update nach, sofern Internetverbindung besteht. Das kann auchschonmal 20 Minuten dauern, aber Windows 10 schafft es immer, sich aus dem Sumpf zu ziehen. Ich war selbst verblüfft, als ich das entdeckt habe, seit Windows 98 habe ich das nicht mehr beobachtet (und damals fast täglich benutzt, weil ich damals viele verschiedene Mainboards mit unterschiedlichsten Chipsätzen (Intel, AMD, VIA, SIS, UMC, ALI, Winbond, und was es da alles gab) testen musste, so viele vorinstallierte Platten wie ich damals unterschiedliche Boards zwischen den Fingern hatte, kann man garnicht haben). Inzwischen habe ich schon mehr als ein Dutzend Win 10 Installationen in neue PCs/Notebooks umgezogen.
"Seit Windows 2000 sind wir das nicht mehr gewohnt, machte man das z.B. mit XP oder 7, so quittierte meistens der Boot-Prozess mit „illegal Boot device" Bluescreen."
Mit Windows XP auf AMD-Hardware hab ich das mehr als 10 Jahre lang gemacht, war nie ein Problem.
Ich denke, der "Irrglaube" kommt schlicht als Kollateralschaden von verunglückten Treiberupdates – manche von Treiber-Optimierungs- oder Aktualisierungstools wie Driver Booster & Co. Da war es nicht selten so, dass danach nichts mehr ging oder längst gefixte Fehler über veraltete Treiber in die Systeme kamen.
Treiber auf dem aktuellen Stand halten, ist eine der Archillesfersen von Windows! Denn setzen wir den Spezialisten-Hut ab, den wir hier alle aufhaben, bleibt doch eines: Bei den 1,5 Milliarden Windows 10 Systemen müssen sich 80-90 % der Leute drauf verlassen, dass einschalten und läuft ohne zutun gewährleistet ist.
Nun beantwortet sich jeder selbst, ob dies für ihn und seine Systeme zutrifft. Da gibt es ja die unterschiedlichsten Erfahrungen, wie ich so lesen ;-)
Mal dumm gefragt: Wie verhält es sich da mit der Windows-Aktivierung? Ist die nicht mehr an bestimmte Hardware-IDs gekoppelt?
Demnach könnte man ja ein aktiviertes Windows 10 einfach auf andere Platten klonen, in zig Rechnern verbauen, und MS würde nur gutmütig die Treiberupdates beisteuern.
Man muss Windows anschließend neu aktivieren. Das war ab XP schon so. Hat man eine Volumen- oder Retailversion von Windows 10 oder hat der Ziel PC eine digitale Lizenz im BIOS, ist das kein Problem. Hat man die Installation von Windows 7 auf 10 aktualisiert, hat man Pech gehabt. Einmal von 7 auf 10 aktiviert, ist der Windows 7 Key fest an den PC gebunden. Schon der Austausch des Mainboards kann dazu führen, dass die Aktivierung flöten geht und sich nicht wieder herstellen lässt.
Kommt drauf an. Wer ein lokales Konto hat, der muss neu aktivieren. Wer ein Microsoft-Konto hat, dessen Lizenzen sind an dieses Konto verknüft. Meldet man sich mit der Platte an "umgesteckter" PC-Hardware an, ist automatisch wieder aktiviert.
@mvo:
Kann ich nicht bestätigen was du Schreibst. Man kann nach wie vor ein neu Installiertes Windows 10 mit einem Windows 7 Key aktivieren, auch nach Wechsel des Mainboards. Im April ist hat sich mein FM2+ Mainboard verabschiedet, bin dann auf die AM4 Plattform umgesattelt. Hab dann Windows 10 darauf neu installiert, und konnte Windows 10 problemlos mit meinem Windows 7 Ultimate Key wieder Aktivieren (Mit Lokalem Nutzer konto). Der Windows 7 Key ist somit nicht an die PC Hardware gebunden, wenn man von Windows 7 auf Windows 10 geupgradet hat, ansonsten hätte bei mir ja die Aktivierung von Windows 10 mit meinem Windows 7 Ultimate Key nicht funktioniert. Wie das mit Windows 8.1 ist weis ich nicht, aber bei Windows 7 Keys geht das Aktivieren von Windows 10 nach wie vor problemlos.
"Seit Windows 2000 sind wir das nicht mehr gewohnt, machte man das z.B. mit XP oder 7, so quittierte meistens der Boot-Prozess mit „illegal Boot device" Bluescreen."
Das hat mit XP, Vista und besonders Windows 7 immer gut funktioniert. Allerdings muss man halt darauf achten, dass im BIOS der Zugriff IDE/AHCI richtig eingestellt ist, sonst gibt es eben genau diesen Bluescreen. Bei Windows 10 im übrigen ganz genauso.
Ne, hab ich andere Erfahrung gemacht, habe schon Platten zwischen Intel und AMD Systemen hin und her gesteckt, auch manche XEON-Chipsätze sind problematisch (z.B. der in der Dell Precision 3600, der SATA-Treiber dafür war bis Win 10 1607 nicht mal dabei und musste händisch per DISM ins boot+install.wim eingepflegt werden, damit man die Mühle installieren konnte), und das ging trotzdem. AHCI ist natürlich seit Jahren immer Pflicht. Win 10 schaltet imer erstmal auf einen generischen AHCI-Treiber um, schnüffelt die Hardware ab, und installiert dann automatisch den optimalen Treiber.
@1ST1
Ähm Sorry aber den Standard IDE Treiber gab es unter Windows 98 oder Windows NT 4.0 auch, nur war der halt echt Bockmist. Ohne DMA war halt die CPU alleine mit dem Schaufeln der Daten von und zur Festplatte beschäftigt. Der Gerätespezifische Treiber hat dann auch UDMA aktiviert und dafür gesorgt das man mit seinem Pentium 133 Mhz zumindest Mp3s ohne Aussetzer abspielen konnte ;)
Wenn ich unter Windows 10 einen herstellerspezifischen Treiber verwende, werde ich auch bei Windows 10 einen inaccesable bootdevice bekommen wenn ich von AMD nach Intel oder umgekehrt wechsel. Darum gilt für mich seit Ewgikeiten den Standard AHCI Treiber von Windows zu nutzen dann ist man bei sowas save. Blöde nur wenn man von SATA zu NVME wechselt. Wenn man vorm Klonen dran denkt sind es 15 Sekunden Arbeit. Wenn mans vorher vergessen hat dauert es ein bisschen länger. Also die 15 Sekunden + solange wie man vom Windows Install USB-Stick bootet und dann braucht um den Registry Hive zu laden :)
Ansonsten mache ich Treiber Updates und Bios Updates mit Ausnahme des Nvidia Treibers mitlererweile per Windows Update als optionale Updates und habe damit keine Probleme.
Bei Audio und Storage verwende ich aber immer Standardtreiber von Windows da sich beides schon oft als Showstopper bei Updates und Upgrades erwiesen hat. Besonders dämlich: Dell aktiviert immer den Raid Modus bei Clients dann hat man den doofen Rapid Storage Treiber drauf und der ist echt oft ein Problem bei Upgrades gewesen.
Hast du es mal ausprobiert?
Meine Windows 98 Test-Festplatten waren immer mit allen IDE-Treibern von Intel, AMD. VIA, SIS, … bestückt, Windows 98 hat automatisch gewechselt, so wie es Windows 10 glücklicherweise jetzt auch wieder macht.
@1ST1 Ja öfter. Auf einigen Systemen ist der Standard AHCI Treiber (stor-ahci) aktiv, da ist Wechseln kein Problem. Aber beim Wechsel von AMD zu Intel und umgekehrt hatte ich schon häufiger den inaccesable bootdevice. Wenn der Intel SATA Treiber aktiv ist wird der stor-ahci nicht mehr automatisch geladen. Häufig kein Problem wenn man zwischen Intel Systemen wechselt, manchmal aber auch doch weil Intel wiederrum mehrere Treiber für verschiedene Chipsatz (PCH) Generationen hat. Der von mir genannte Lösungsvorschlag ist auch nichts anderes als den Startparamenter der auf Deaktiviert steht für den entsprechenden Treiberdienst aus der Registry zu löschen, dann wird er auf jedenfall einmalig gestartet. Wenn Windows beim Starten aber erkennt das es den Treiber doch nicht braucht wird es ihn wieder deaktivieren.