Kleiner Nachtrag zum Partitionsproblem bei GPT-Datenträgern unter Windows 10. Windows 10 weist einigen Systempartitionen plötzlich (z.B. beim Funktionsupdate auf Windows 10 April Update) einen Laufwerksbuchstaben zu, was zu Ärger führt. Hier einige Hinweise zur Erklärung des technischen Hintergrunds.
Anzeige
Das Problem
Beim Upgrade auf Windows 10 April Update endeten einige Benutzer mit dem Problem, dass OEM- oder Recovery-Partitionen plötzlich ein Laufwerk zugewiesen wurde (siehe nachfolgender Screenshot).
Alleine das zusätzliche Laufwerk ist verwirrend. Aber es geht noch weiter, denn das Laufwerk wird anschließend von Windows 10 als 'voll' bemängelt. Es erscheint zyklisch die nachfolgende Benachrichtigung als Popup.
Anzeige
Speicherplatzwarnung abschalten
Microsoft hat zwar den KB-Artikel 555622 zum 26.4.2018 veröffentlicht, in dem erklärt wird, wie man diese nervige Warnung abschaltet.
1. Hierzu startet man den Registrierungseditor regedit.exe unter Windows und navigiert zu nachfolgendem Schlüssel.
2. Danach ist der angegebenen DWORD-Wert einzutragen und Windows neu zu starten.
Der Registrierungsschlüssel, der benötigt wird, ist:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
Dort wird dann der 32-Bit-DWORD-Wert NoLowDiskSpaceChecks hinzugefügt und auf 1 gesetzt. Nach dem Neustart sollte das Problem der ständigen Warnungen weg sein. Aber das ist keine wirkliche Lösung.
Temporärer Fix: Laufwerksbuchstaben entziehen
Ich hatte das Problem mit den OEM-/Recovery-Partitionen im Blog-Beitrag Windows 10 V1803: Erzeugt neue OEM-/Recovery-Partition behandelt. Ein (temporärer) Workaround, den ich im Artikel aufgezeigt hatte, bestand darin, den zugewiesenen Laufwerksbuchstaben zu entziehen. Das lässt sich mit Windows Bordmitteln erledigen.
Im Hinterkopf blieb bei mir aber: Wie lange hält das? Der Entzug des Laufwerksbuchstabens überlebt zwar einen Neustart von Windows 10. Aber jedes Funktionsupdate und möglicherweise jeder weitere kumulative Patch bringt das Laufwerksproblem wieder zum Vorschein. Und in meinem englischsprachigen Blog-Beitrag zum Thema gab es auch einen entsprechenden Kommentar.
Erklärung und finale Lösung
Der Blog-Leser mit dem obigen Kommentar wies mich dann auch auf die Ursache hin. Ihm war aufgefallen, dass der GPT-Partitionstyp auf 0x0000000000000001 gesetzt war. Ich habe daher im Blog-Beitrag Windows 10 V1803: Erzeugt neue OEM-/Recovery-Partition eine technische Erklärung angefügt. Hier in Kurzform: Die obige Kennung markiert die Partition nur als 'wird vom System benötigt'. Es müsste aber auch die Kennung 0x8000000000000000 gesetzt sein, die Windows anweist, keinen Laufwerksbuchstaben zuzuweisen.
Wer also von obigem Problem betroffen ist, muss den GPT-Partitionstyp auf 0x8000000000000001 setzen, um das Problem aus der Welt zu schaffen. Dann könnte höchstens ein neuer Patzer der Windows Update-Routinen den Partitionstyp wieder ändern. Dies lässt sich in einer administrativen Eingabeaufforderung (cmd über Als Administrator ausführen aufrufen) mit diskpart über den Befehl
diskpart
list volume
select volume <Nummer des betreffenden Volume>
attributes volume set nodefaultdriveletter
erledigen (siehe auch folgenden Kommentar), ich würde aber ein Drittanbieter Partitionierungstool mit komfortabler Bedienoberfläche verwenden.
Ähnliche Artikel
Windows 10 V1803: Erzeugt neue OEM-/Recovery-Partition
Windows 10 Version 1803: Diese Probleme gibt es
Anzeige
Das Ändern der Partitionsattribute geht auch mit Windows-Bordmitteln, nämlich mit dem Kommandozeilentool Diskpart. Da aber das nicht jedermanns Sache sein dürfte, da die Gefahr besteht, dass man bei der Auswahl der zu ändernden Partition sich vertun kann, und ich auch keine aktuelle, auf Windows 10 zutreffende Dokumentation bei Microsoft gefunden habe, wäre ein Tool mit GUI deutlich besser.
Der Vollständigkeit halber möchte ich aber doch noch den Link zu einer Dokumentation von Diskpart aus der Zeit von Windows Vista beifügen:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc766465%28v=ws.10%29
Danke für die Ergänzung – hatte kurz gesucht, aber in meiner Beschreibung das Ganze nicht gefunden.
Geht aber nach kurzer Zeit gut mit diskpart. Man muss sich nur angewöhnen, in diskpart mit den Kommandos list disk und select disk … anzufangen. Ich nehme das Tool jetzt immer, um USB-Sticks wieder hinzubiegen.
In diskpart den Befehl help eingeben, dann kommen die möglichen Befehle. Und zu den einzelnen Befehlen kann man sich dann auch die Kommandozeilen-Hilfe anzeigen lassen.
Zwei unserer Rechner die dieses Problem aufwiesen, haben das Löschen der Partition mittels Acronis Disk Director, von bootfähigem USB Stick gestartet, nicht übel genommen.
Unter gewissen Umständen funktioniert das ganz gut, ich würde das aber nicht so verallgemeinern, das kann nämlich auch voll in die Hose gehen wodurch das System sich nicht mehr starten lässt.
Hab das hier bei einem Notebook von einem Bekannten gehabt, da hatten sich mittlerweile auch schon mehrere OEM oder Recovery Partitionen angesammelt die wir zu einem Löschen als auch wieder Verstecken wollten, da empfiehlt es sich vor allem vorher ein Backup zu erstellen um im Fall der Fälle das System in den vorherigen zustand zurück zu setzen.
Hab den Fehler gleich mit zwei Partitionen gehabt. Hab mit diskpart allerdings beide Platten "removed".
Könnte das zu Problemen führen? O.o
Wenn die Partition manuell wirklich gelöscht wird, kann es sein, dass danach Bitlocker, die Windows 10 eigene PC-Zurücksetzen-Funktion oder Hersteller-Werkzeuge zum Zurücksetzen des PCs nicht mehr korrekt funktionieren.
Wenn du aber tatsächlich nur den diskpart Befehl "remove" benutzt hast, entfernt dies tatsächlich nur den zugewiesenen Laufwerksbuchstaben. Die Partition bleibt dabei weiter erhalten – und das ist üblicherweise gut und richtig so.
Die bessere Lösung ist, dazu noch das Partitionsattribut wie oben beschrieben, richtig zu setzen:
DISKPART> list volume
DISKPART> select volume #
Nun mit …
DISKPART> detail partition
… die Ausgabe von Typ(=ID) und Attribut kontrollieren und bei Bedarf wie folgt ändern:
DISKPART> set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
DISKPART> gpt attributes=0x8000000000000001
Dies setzt die Partition auf den Typ "(Windows/OEM) Recovery" und die Attribute auf "Benötigt, aber ohne Laufwerksbuchstabe"
Ich habe es gerade mal überprüft. Auf meiner Testmaschine ist das Attribut auf 0x8000000000000000 gesetzt. Und mit dem oben angegebenen Befehl:
attributes volume set nodefaultdriveletter
wird das Attribut auch gesetzt.
Da ich das Problem ebenfalls an zwei Rechnern hatte, finde ich es schon mehr als "komisch", das das niemand in Redmond aufgefallen ist. Was testen die denn eigentlich da ?! Das wurde schon in den Insider Versionen bemängelt, und es wurde bis in die Final mit rübergeschleppt.
Für mich ist die 1803 die problembehaftetste Version seit der TH2, und wurde auch wieder durch die 1709 ersetzt.
Das Frage ich mich seit jeher auch, was die in Redmond da testen falls die überhaupt da noch was testen!
Sicher testen die. Die Frage ist doch eher, wie gut deren Testsysteme die Breite der existierenden PCs abbildet und ob das überhaupt möglich ist.
Bei der unüberschaubaren Anzahl von Systemen mit unterschiedlichen Hard- und Softwarekonstellationen und der Update-Taktrate, wird die Möglichkeit, dass bei gravierende Updatefehler auftreten, in Zukunft auch immer größer.
Damit muß man als WIN-Nutzer leider leben oder in den sauren Apple beißen.
Das ist mir auch klar, aber bis vor 5 Jahren hat das Microsoft auch geschafft das nicht so gravierende Fehler bei Updates aufgetreten sind, möglich das Windows Vista, XP und 7 auch vom Aufbau her nicht so kompliziert waren.
Das ist aber keine Entschuldigung für so einen Bockmist den die seit einigen Jahren in Redmond verzapfen.
Wenn ich so eine Scheiße auf der Arbeit abliefern würde wäre ich den nächste Tag fristlos gefeuert.
Die testen wahrscheinlich mit frischen Systemen. Mit einem Clean-Install der 1709 und einem Upgrade auf 1803 nach zwei Wochen trat der Fehler nicht auf. Problematisch sind die Systeme, die sich von Feature-Upgrade zu Feature-Upgrade hangeln.
Blöd ist nur, dass der Fehler im Release-Ring der 1803 ja schon aufgefallen war, man aber trotzdem (in diesem Fall) unverändert das April Upgrade veröffentlicht hat. Wahrscheinlich dem Zeitdruck geschuldet (und dem ungeduldigen CEO)
Die gleichen Probleme treten aber auch selbst auf den eigenen Surface Systemen auf.
Die mögen wohl testen, aber eher schlecht, als recht, wie ich finde. Nichts desto trotz wird die Final einfach Released, obwohl zahlreiche Insider jede Menge Feedback dazu und für andere Fehler abgegeben werden, die ebenso bei mir stark vertreten sind. Vor allem die Netzwerkprobleme.
Und trotz allem wird dann so eine "Alpha" zur Final, nur damit auch das Datum stimmt.
Für mich ist das Insider System wertlos, wurde aber damals aber als das "Nonplusultra" genannt und propgagiert, wenn es um zügige Fehlerweiterleitung und Behebung ging.
Unter anderem aufgrund dessen gibt es doch das "Zwangsupdatesystem".
Aber man sieht ja, wohin das ganze geführt hat.
Und ja, die meisten Fehler treten bei Upgrades auf. Aber niemand hat Microsoft zu diesem Quatsch gezwungen, alle 6 Monate ein Upgrade aufzuwängen, das die meisten in solcher Form nicht brauchen.
Damals gab es keinen Zwang zur nächsten Version, und Microsoft hat sich trotzdem wirklich Zeit gelassen, meist so 1,5 Jahre, bis alles durchdacht war und ein Service Pack released wurde.
Ich musste Windows 7 nicht einmal in 5 Jahren neu aufsetzen, und alles lief wie geschmiert.
Bei Windows 10 habe ich alle 3 Rechner letztens mit der 1709 neu aufgespielt, und jetzt habe ich enorme Probleme beim Upgrade auf die 1803 und soll den ganzen Mist nochmals neu machen ?!
Das würde mich locker 3 Tage an allen Maschinen kosten, samt jeglicher Software, mehrerer Benutzer und den ganzen Einstellungen.
In dieser Form ist Windows 10 nicht mehr als eine "Kiddie" Experimentierwiese, leider. Und derjenige, der sich darauf verlassen können (sollte), könnte ganz blöd aus der Wäsche gucken. Insbesondere die Homeuser müssen offiziell upgraden, ohne das sie es schieben können.
Wenn es nicht so traurig wäre, könnte man darüber lachen…Upgrades für was, Timeline ?! Ja, und diese stürzt auch regelmässig ab, und es wird empfohlen, diese zu deaktivieren.
Man, was für ein Blödsinn, den MS da verzapft. Alle 6 Monate bei Null beginnen. Das hat schon was…Schwachsinniges.
Ich hab jetzt einfach mal nachkontrolliert, was mir Diskpart mit dem Befehl "attributes volume" für die Zuweisung eines Laufwerksbuchstabens auf der Wiederherstellungspartition ausgibt (das Volume muss vorher in den Fokus genommen werden). Dort wird eindeutig angegeben, dass eine automatische Zuweisung nicht erfolgt. Windows scheint nur nach der Bearbeitung der Partitionen die Aufhebung des Mappings nicht vorzunehmen. Und das passiert offenbar auch nicht auf allen Rechnern, sondern nur auf manchen.
Habe ich auch auf dem eigenen Testsystem (wo der Fehler nicht auftrat) gesehen. Aber zum US-Beitrag habe ich halt die Rückmeldung von einem Betroffenen, dass das betreffende Bit nicht gesetzt war. Daher kann man als Betroffener wenigstens das Disk-Attribut prüfen und bei Bedarf setzen.
Günter das Tool mit GUI gibt es auch in Windows
Windowstaste + X > Datenträgerverwaltung
Partition markieren rechtsklick Laufwerksbuchstaben entfernen
Das Problem wurde schon sehr lange im Feedback hub während der beta gemeldet. Passiert ist nichts. Auch der erste Patch behebt es nicht.
Karl, im Blog-Beitrag Windows 10 V1803: Erzeugt neue OEM-/Recovery-Partition hatte ich darauf hingewiesen, dass das häufig nicht funktioniert. Und das reine Entfernen des Laufwerksbuchstabens birgt die Gefahr, dass das Problem beim nächsten kumulativen Update wiederkommt.
Ich habe noch ein restliches Vertrauen darauf das Microsoft den Partitionsflag selbst mit eigenem CU korrigiert.
Wat'n Frickelsystem…
Hier gibt es doch nur eine Option:
Wer Windows 10 Pro oder Enterprise nutzt, das Update auf 1803, so lange es geht, blocken.
Das ist doch nicht mehr feierlich. Ein für viele Nutzer unsinniges Funktionsupdate, das dann auch noch derartig krasse Funktionsstörungen hervorruft.
Die Windows 10 Home Nutzer sind hier leider gekniffen.
Ich bin ja im Grunde ein großer Fan von Windows 10 und hier laufen 3 Systeme mit 1709 absolut rund.
Aber das, was Microsoft den Nutzern mit dem 1803 zumutet, ist schon eine Unverfrorenheit.
Kann dem ganzen nur zustimmen. Mich schockiert regelrecht der Zustand, in der die 1803 released wurde. Es ist mehr ein "Testsystem" in einem Alphastatus, als ein Produktives Upgrade. Jedenfalls, solche enormen Probleme, verbunden mit "Kleinigkeiten" wie hängenden Menüs, abstürzendem Chrome, usw. hatte ich bis dato noch nicht erlebt. Und jetzt gibt es wohl auch Probleme mit abstürzendem Store.
Die OEM Partitionsproblematik sowie die Netzwerkprobleme, die ich damit habe, zwangen mich auch wieder zur 1709 zurück.
Aber man kümmert sich lieber bei MS wohl um "dunkle Explorer" oder um die Verbesserung von "Notepad".
Ja, das sind wirklich Features, und wichtiger als jegliche Stabilität. ;)
In 1709 sah die UEFI-Recovery nach einer sauberen Neuinstallation so aus:
Typ : de94bba4-06d1-4d40-a16a-bfd50179d6ac
Versteckt : Ja
Erforderlich: Ja
Attribut : 0X0000000000000001
–
In 1803 nun so:
Typ : de94bba4-06d1-4d40-a16a-bfd50179d6ac
Versteckt : Nein
Erforderlich: Ja
Attribut : 0X8000000000000001
–
Die Upgrades bauen mit der Recovery aber schon lange Mist, vor allem auch auf MBR-Systemen. Das ist nicht erst seit 1803 so.
Also jetzt bin ich etwas verwirrt. O_o
Du schreibst:"Es müsste aber auch die Kennung 0x8000000000000000 gesetzt sein, die Windows anweist, keinen Laufwerksbuchstaben zuzuweisen."
und dann "..Wer also von obigem Problem betroffen ist, muss den GPT-Partitionstyp auf 0x8000000000000001 setzen.."
Muss jetzt die Partition den Wert 0x8000000000000000 oder 0x8000000000000001 aufweisen, damit das Problem langfristig gelöst bleibt?!
BG Marco
Das ist ein Bit-codierter Wert, die 8 setzt eine Option (kein Laufwerk) und die 1 eine andere (Partition erforderlich).
Ist zwar schon fast 2 Jahre her, aber ich habe nichts besseres als diesen Thread hier bei borncity gefunden.
Es sieht auch so aus als würde es funktionieren….aber.
Diese alles funktioniert nicht bei einem
partionierten "removable" USB-Stick (unter 1909).
(Achtung: Es gibt USB-Sticks die melden sich auf "Festplatte" an…)
Der erste Trick funktioniert nur in dem Rechner, an dem der Drive Letter gelöscht wurde. In einem anderen Rechner belegt der Stick wieder 2 Buchstaben.
(Der Stick wurde mit "rufus" erzeugt, die 2. Partion (FAT32) enthält nur den UEFI-NTFS-Treiber.)
Geht auch nicht:
DISKPART> attr vol set nodefaultdriveletter
Virtual Disk Service error:
The operation is not supported on removable media.
Oder:
DISKPART> detail part
Partition 2
Type : EF
Hidden: No
Active: No
Offset in Bytes: 30750919168
"Type" ist offensichtlich keine UID…oder?
mit 1803 gab es kein Problem.
Gibt es irgendwo eine Lösung?
(Ich mag nicht glauben das nur ich das Problem haben soll und sich daran stört.)