Windows 10 V1803 und das GPT-Partitionsproblem

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).

Recovery-Laufwerk in Explorer

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.

Windows Speicherplatzwarnung

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:


Anzeige

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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Problemlösung, Windows 10 abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

28 Antworten zu Windows 10 V1803 und das GPT-Partitionsproblem

  1. Holger sagt:

    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

    • Günter Born sagt:

      Danke für die Ergänzung – hatte kurz gesucht, aber in meiner Beschreibung das Ganze nicht gefunden.

    • Ralf sagt:

      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.

  2. Siebenhof sagt:

    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.

    • der_Puritaner sagt:

      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.

  3. Markus sagt:

    Hab den Fehler gleich mit zwei Partitionen gehabt. Hab mit diskpart allerdings beide Platten "removed".
    Könnte das zu Problemen führen? O.o

    • Fritz sagt:

      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"

      • Günter Born sagt:

        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.

  4. Janami25 sagt:

    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!

      • Uwe Bieser sagt:

        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.

      • Ralf sagt:

        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.

          • Janami25 sagt:

            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.

  5. Areiland sagt:

    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.

    • Günter Born sagt:

      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.

  6. Karl Wester-Ebbinghaus (al Qamar) sagt:

    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.

  7. ThBock sagt:

    Wat'n Frickelsystem…

  8. Michael Ba sagt:

    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.

    • Janami25 sagt:

      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.

      • Janami25 sagt:

        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. ;)

  9. Sherlock sagt:

    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.

  10. Marco sagt:

    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

  11. Paul sagt:

    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.)

Schreibe einen Kommentar zu Markus Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.