[English]Es kommt immer wieder vor, dass die Update-Installation unter Windows 10, Windows 11 oder den Windows Server-Pendants plötzlich mit dem Installationsfehler 0x8024001E abbricht. Dann ist natürlich guter Rat teuer und es stellt sich die Frage nach der Fehlerursache bzw. nach einer Abhilfe für den Installationsabbruch. Nachdem mit dieser Fehler beim Februar 2022 Patchday mal wieder bei Nutzern untergekommen ist, hier eine kurze Erläuterung, was man wissen sollte.
Anzeige
Der Windows Update-Fehler 0x8024001E
Der Fehlercode 0x8024001E steht für WU_E_SERVICE_STOP, weil ein Dienst beendet wurde (siehe auch Windows 10: Update-Fehlercodes 0x8024…. entschlüsselt). Konkret lautet die Fehlerbeschreibung:
0x8024001E WU_E_SERVICE_STOP Operation did not complete because the service or system was being shut down.
Die betreffende Transaktion konnte nicht abgeschlossen werden, weil der Dienst oder das System heruntergefahren wurden. Lässt sich ein heruntergefahrenes System ausschließen, bleibt die Frage, was dieses Problem verursacht.
Internet Explorer: Temporärer Ordner undefiniert
In sehr vielen Fällen scheitert der Download der Updates, weil der Pfad auf den Temporären Ordner für Internetdateien (im Internet Explorer oder Edge-Browser) undefiniert ist. Oder es gibt Zugriffsprobleme mit dem Zielordner. Man kann über Internet Optionen der Systemsteuerung gehen oder die Menüschaltfläche Extras des Internet Explorers und dann den Befehl Internet Optionen wählen. Dann geht man zur Registerkarte Allgemein schaut sich dort über die Schaltfläche Einstellungen der Gruppe Browserverlauf den Pfad für "Temporäre Internetdateien" an. Dieser Pfad sollte auf:
C:\Users\….\AppData\Local\Microsoft\Windows\Temporary Internet Files\
stehen (ggf. über Ordner verschieben setzen). Wichtig ist, dass der Pfad nicht auf eine andere Partition zeigt, da die Sicherheitseinstufung (Vertrauensstufe niedrig) da meist nicht gegeben ist.
Anzeige
Notfalls kann der Internet Explorer auch auf der Registerkarte Erweitert über die Schaltfläche Zurücksetzen einfach zurückgesetzt werden.
Anzeige
"did not complete because the service or system was being shut down." …
Lösung:
Fehlender oder falscher Temp-Ordner … TOLL, wie soll man an Hand dieser Fehlermeldung auf so eine Ursache/Lösung kommen?
Wieder so eine irreleitende Fehlermeldung, die nicht zur Fehlersuche & Korrektur beiträgt.
Ähnliches habe ich letztens erst an einer Parkhauseinfahrt/Schranke (davon gab es 3 Stk.) erlebt:
QRcode vor Leser gehalten: Fehlermeldung "QRcode ungültig oder kann nicht gelesen werden" … 3 mal versucht – immer wieder der selbe Fehler.
Mit Auto zurück gesetzt und eine andere Einfahrt/Schranke genommen, da wurde mein QRcode sofort anstandslos akzeptiert.
Ich habe mir dann die 3 Einfahrten später nochmals angeschaut und die zuerst von mir genutzte Einfahrt/Schranke war für Tagegäste (und damit ein anderes bauliche getrenntes Parkareal innerhalb des Parkhauses) und nicht für Dauerparker >24h gedacht.
Eine aussagekräftige Fehlermeldung wäre hier sinnvollerweise "falsche Parkhauseinfahrt" oder "Benutzen sie Einfahrt 2 oder 3" gewesen.
Bei den Windows-Fehlercodes gibt es zwei grundsätzliche Probleme:
a) die unsägliche "as-a-service"-Manie hat dazu geführt, dass bei jedem Funktionsupdate neue Fehlercodes definiert werden. Die bekommt nur heraus, wer sich die SDKs jedes Mal neu zieht und dann die betreffenden Definitionsdateien durchforstet. Es gibt von MS ein Command Line-Tool, was das macht – das muss aber bei jedem Funktionsupdate aktualisiert werden. Andernfalls bekommt man bei Eingabe eines Fehlercodes den Hinweis, dass der nicht bekannt ist. Tolle Wust, haben die Entwickler fein hingebracht.
b) Durch die 1.000 Dienste und Abhängigkeiten werden ggf. Fehlercodes generiert, wo absolut unklar ist, an welcher Stelle es knallt. Es gibt hier einen Blog-Beitrag, der ein "leeres graues Fenster" bei irgend einer Update-Funktion thematisiert. Ursache ist wohl eine deaktivierte Option zum Speichern von Daten im Internet Explorer – der von irgend einem Dienst genutzt wird. Noch tollere Wurst.
Das einzige, was ich hier versuchen kann: Den Fehlercode bestmöglich zu interpretieren und dann mögliche Ursachen zu beschreiben. Funktioniert oft ganz gut – auch dank der Leserschaft, die dann ihre Erfahrungen als Kommentare zu den Blog-Beiträgen postet. Aber es gibt leider (allzu häufig) den Fall "stochern im Nebel, nix genaues weiß man nicht". Unbefriedigend hoch 3.
SDK / Command Line-Tool: hast Du da zufällig weiterführende Infos/Links oder die passenden Suchbegriffe parat?
Danke!
Ich wollte noch einen separaten Artikel drüber verfassen. Möglicherweise stricke ich eine kleine GUI um das Tool, damit der elende DOS-Mode gekapselt wird und man einfach einen Fehlercode eingeben kann. Mal schauen.
Vorab: Es ist das Error Lookup Tool (err.exe) – Link mit Erklärungen – und noch eine Download-Seite.
Danke!
Mit dem Tool würdest Du dich wahrscheinlich international beliebt machen.
"as-a-service"-Manie…sehr gut, sehe ich auch so! Vor 30 Jahren hätten sich die Kunden geweigert, mit solchen Fehlermeldungen und dem damit verbundenen Stochern im Dunkeln zu leben. Heute schauen die Entwickler nur noch mit Scheuklappen auf ihren Service und sagen: "Beweise mir erstmal, dass es daran liegt". Da kaum jemand den Gesamtüberblick hat, können Fehler oft nicht mehr richtig identifiziert werden. Die armen Administratoren müssen es ausbaden.
>> Wichtig ist, dass der Pfad nicht auf eine andere Partition zeigt, … <<
Es gibt im Netz Tips, dass man den Pfad auf eine andere Partition legen soll (HDD), um die SSD zu schonen, auf der die Systempartition liegt…
"eine andere Partition legen soll (HDD), um die SSD zu schonen …" – Wow, macht ja tierisch Sinn … !?!?!
Um die SSD zu schonen, den Webcache auf eine unsäglich langsame HDD auszulagern … :-(
Ich verbaue seit ca. 2013 SSDs und hatte letztens erst eine Server-SSD aus einem 24/7-Server, die rund 6 Jahre im Dauerbetrieb lief hier (rund 50.000 Betriebsstunden). Samsung irgendwas … 1 TB. Zustand lt. Crystal Diskinfo 95% !!
OK, es war eine Server-SSD, und keine Consumer-SSD.
Aber selbst im Consumerbereich habe ich bisher seit ca. 2013 (Samsung 840, 850, 860, 870 EVOs und 970EVOplus M.2) nicht einen einzigen Defekt …
Seit gut 2 Jahren verbaue ich auch Crucial MX500, P2 & P5. Auch da bisher keinerlei Ausfälle …
Also, die Dinger, die SSDs halten … HDDs – Good bye!
HDDs machen schon an manchen Stellen Sinn, insbesondere bei großen Kapazitäten > 2 TB, aber nicht an den Stellen, wo ich direkt mit arbeite …
Das ist Lebenszeitverschwendung.
Ich habe hier eine SSD aus einem Desktop-PC in der Familie liegen, also nicht sooo intensiv benutzt wie ein Server, die am Ende ihres Lebenszyclus keine Schreibzugriffe mehr macht, die war, als ich das Problem erkannt hatte, rund 6 Jahre alt. Immerhin konnte ich sie auf eine neue SSD clonen und damit den PC ohne weiteren großen Aufwand wieder benutzbar machen.
" nicht sooo intensiv …" sieht deine SSD evtl. anders, da kann man sich sehr täuschen …
Nach 6 Jahren schon?
Da wäre mal interessant, was die SSD-Daten wie Betriebsstunden, TBW, Einschaltzyklen etc. sagen.
Natürlich Hersteller und Modell auch.
Wäre nett, wenn du das nachliefern könntest ? Danke, 1ST1.
Meine NVMe Samsung 960 Pro 512GB hat mittlerweile eine Schreibleistung von 21,13TB. Sie wurde 2017 als Systemlaufwerk verbaut. Ich nutze häufig den Ruhezustand (S4). Das sorgt für eine größere Schreiblast da Windows den Inhalt des Arbeitsspeichers in die Datei hiberfil.sys auf die SSD schreibt. Das war auch ein Grund weshalb ich die Pro Version gekauft habe. Die verkraftet mehr Schreibvorgänge.
Schreibvorgänge: 21,13TB
Lesevorgänge: 79,98TB
Betriebszeit: 8300 Stunden
Laufwerkszustand: 99%
Bei dem beschriebenen PC würde ich vermuten das in Windows der Schnellstartmodus aktiviert ist. Der funktioniert ähnlich wie der Ruhezustand (S4).
Ein anderer Grund könnte ein zu knapp dimensionierter RAM sein. Ständiges auslagern von Daten auf die SSD kann auch die Schreiblast erhöhen.
Es stimmt zwar, dass SSDs durch Schreibzugriffe verschleißen, aber diesen Effekt sollte man auch nicht überschätzen. Die paar Gigabyte, welche da ggf. im Monat als temporäre Dateien geschrieben werden, machen den Kohl nicht fett. Mal als Bespiel aus meinen System:
SAMSUNG 512 GB NVMe SDD (Systemlaufwerk):
Lesevorgänge: 20.272 GB
Schreibvorgänge: 9.481 GB
Betriebsstunden: 5.753
Restlebensdauer der Verschließregulierung: 99%
SAMSUNG SSD 860 QVO 4TB:
Lesevorgänge: kein Zähler
Schreibvorgänge: 20.041 GB
Betriebsstunden: 6.554
Restlebensdauer der Verschließregulierung: 98%
Das Ende der Verschleißregulierung wird also theoretisch in ca. 50 Jahren erreicht. Das dürfte als allgemeine Lebenserwartung für meinen Laptop allerdings nicht wirklich realistisch sein.
Im Server stecken noch zwei SSDs. Diese werden stärker belastet, da diese als Flashspeicher im RAID verwendet werden. Zwischen den langsamen WD Red Festplatten (RAID-10) und den SSDs (RAID-1) werden permanent Daten verlagert (Auto-Tiering).
2 x SSD 860 EVO M.2 1 TB im RAID 1:
Selbst hier sind nach zwei Jahren Dauerbetrieb noch 92% der Restlebensdauer vorhanden. Somit wären auch hier rechnerisch 25 Jahre Lebensdauer möglich.
Natürlich kann eine Festplatte oder SSD immer ausfallen. Es gibt keine Garantie, dass diese auch wirklich viele Jahre sicher durchhält. Daher laufen Festplatten im Server im RAID und es gibt auch immer eine aktuelle Sicherung der Daten sollte etwas schief gehen.
Meiner Erfahrung nach muss man aber keine Sorge haben, dass man sich eine SSD durch so etwas wie temporäre Dateien kaputtschreiben kann. Die Datenmengen sind für modere SSDs viel zu gering.
Gruß Singlethreaded
Es kommt aber auch auf den SSD Hersteller an :
Ich hab hier Intel SSD's verschiedener Baureihen die bei normaler Nutzung als Systemplatte zu fast 100% ausfallen. Daten liegen dabei auf HDD.
Die stabeln sich dann neben Embedded Intel Systemen, die auch nach ca 4-5 Jahren komplett ausfallen (Errata APL47).
Samsung, Crucial, Kingston laufen und laufen und laufen derweil.