[English]Seit dem 30. April 2018 verteilt Microsoft ja das Funktionsupdate für Windows 10 Version 1803 (April Update). Nach dem Upgrade tauchen bei einigen Leuten plötzlich OEM- bzw. Wiederherstellungs- (Recovery) Partitionen auf, denen ein logischer Laufwerksbuchstabe zugewiesen ist. Dann nervt Windows 10 mit ständigen Benachrichtigungen, dass das Laufwerk voll sei. Hier einige Erklärungen und ein Reparaturansatz.
Anzeige
Nerviges Partitionsproblem
Einige Leute stellen nach der Upgrade-Installation fest, dass eine neue Partition (Recovery-Partition mit Windows PE) vorliegt, der dann ein Laufwerksbuchstabe zugeordnet ist. Dieser Kommentar bei heise.de beschreibt das ganz gut.
Plötzlich neuer lokaler Datenträger da
Was kann das sein? Nach dem Update gibt es einen neuen lokalen Datenträger mit Recovery-Verzeichnis. 450MB groß, davon 405MB belegt. Diese Tatsache teilt mir Windows nun leider dauernd mit… (Ich weiß es doch nun schon !!)
Kann die Partition (scheint ja wichtig) irgendwie versteckt und von Füllstandswarnungen ausgenommen werden)
Es wird wohl eine neue Recovery-Partition angelegt (450 bis 500 MByte groß), der dann fälschlich ein Laufwerksbuchstabe zugewiesen wird. Windows 10 wird dann ständig Warnungen einblenden, dass das Laufwerk voll sei.
Der obige Screenshot zeigt den Explorer, wo das Laufwerk auftaucht. Der Screenshot stammt aus diesem tenforums.com-Thread, wo ein Betroffener aufgeschlagen ist. Ich habe aber entsprechende Anfrage auch über Google+ erhalten (hier ist ein Foto eines chinesischen Systems. Und in diesem tenforums.com-Thread ist ein weiterer Fall in der Datenträgerverwaltung zu sehen.
Anzeige
Der Bug ist seit längerem aus Insider Previews bekannt, tritt aber nicht bei jedem Gerät auf. Hier wird sogar eine weitere 100 MByte Partition für den Bootlader (dürfte die EFI-Partition sein) erwähnt.
Ich tippe darauf, dass es auf Systemen auftritt, wo diverse Recovery Partitionen des OEMs schon vorlagen. Manchmal legt Windows 10 beim Setup aber auch selbst zusätzliche Recovery-Partitionen an (hier eine Fundstelle aus 2016). Eine Theorie geht dahin, dass eine bestehende Recovery Partition beim Setup als zu klein angesehen und eine weitere Partition angelegt wird. Von Aomei gibt es diesen Artikel, der sich mit der Frage der zusätzlichen Recovery-Partitionen befasst.
Jetzt wird lediglich ein Laufwerksbuchstabe zugeordnet, wodurch es erst auffällt.
Ausblenden des logischen Laufwerks
Der Workaround besteht darin, dass man dieser Partition den Buchstaben für das logische Laufwerk entzieht. Dann taucht die Partition nicht mehr als Laufwerk im Explorer auf, ist aber weiter vorhanden und kann zur Wiederherstellung von Windows 10 herangezogen werden.
Die Datenträgerverwaltung patzt
Die erste Idee, die viele Nutzer haben, besteht darin, der Partition mit der Datenträgerverwaltung den Laufwerksbuchstaben zu entziehen. Wer die Datenträgerverwaltung verwenden möchte, um das Problem zu lösen und der Partition den Laufwerksbuchstaben zu entziehen, kommt in den meisten Fällen nicht weiter. Das Kontextmenü unterstützt bei dieser Recovery-Partition keine Befehle.
Der obige Screenshot (Quelle) zeigt, dass nur die Hilfe im Kontextmenü als Befehl verfügbar ist. Die Partition hat wohl den OEM-Status. Je nach Variante können aber andere Partitionskennungen vorhanden sein. Man kann daher aber mal probieren und nachsehen, ob der Weg vielleicht doch funktioniert. Auf meinem System ist der betreffende Befehl Laufwerksbuchstaben und -pfade ändern zum Verwalten von Laufwerksbuchstaben für die Recovery-Partition aber gesperrt.
Workaround zum Fixen
Partitionierungstools von Drittanbieter weisen diese Einschränkungen nicht auf. Man kann aber auch mit Bordmitteln über das Tool diskpart die Laufwerksbuchstaben solcher Partitionen ganz gut verwalten. Ich habe das z.B. in meinem Windows 10 PowerTipps-Buch beispielsweise beschrieben. Hier die Schritte für eine mögliche Lösung über die Eingabeaufforderung.
1. Unter einem Administratorkonto die Eingabeaufforderung öffnen (cmd im Suchfeld der Taskleiste eintippen und dann den Treffer über Als Administrator ausführen aufrufen).
2. Im Fenster der administrativen Eingabeaufforderung die nachfolgend aufgeführten Befehle ausführen.
diskpart
list volume
select volume <Nummer des betreffenden Volume>
remove letter=<Buchstabe des betreffenden Volume>
exit
Hier habe ich die betreffenden Befehle der Eingabeaufforderung in einem Screenshot herausgezogen.
Mit list volume werden ja die gefundenen logischen Laufwerke mit ihren Nummern aufgelistet. Hier ist dem Volume 0 ein Buchstabe I zugewiesen. Im Nachgang kann das betreffende Volume (hier 0) selektiert und dann der Buchstabe mit remove letter entzogen werden. Dann ist das logische Laufwerk weg und die Toast-Benachrichtigung mit der Warnung, dass das logische Laufwerk fast voll sei unterbleibt.
Oder MountPoint entfernen
Wer mit diskpart nicht so ganz gut zu Fuß ist, kann auch den Befehl mountvol in einer administrativen Eingabeaufforderung verwenden. Hierzu, wie oben skizziert, eine Eingabeaufforderung mit administrativen Berechtigungen aufrufen und den folgenden Befehl eingeben:
mountvol I: /D
wobei I: hier der betreffende Laufwerksbuchstabe ist, während der Schalter /D das Löschen des MountPoints bewirkt. Das Ganze ist u.a. hier nochmals skizziert und wird nachfolgend in diesem Kommentar (danke an Doc WP) als funktionierend beschrieben.
Inflationäre OEM-Partitionen bereinigen
Manche Nutzer stellen fest, dass nach einem Upgrade eine ganze Reihe neuer OEM-Partitionen angelegt wurden. Normalerweise ist mein Plädoyer, das Ganze zu belassen. Wer sich gut auskennt und ggf. vorher ein Backup angefertigt hat, kann das System aber möglicherweise folgendermaßen bereinigen:
- Mit den obigen Befehlen diskpart aufrufen, die Partition selektieren und dann mit delete partition entfernen.
- Anschließend Windows 10 direkt aus dem laufenden Betriebssystem über die setup.exe des Installationsdatenträgers als Reparaturinstallation per Inplace Upgrade neu aufspielen.
Mit dem zweiten Schritt werden die benötigten Recovery-Partitionen durch Windows angelegt. Allerdings möchte ich an dieser Stelle eine deutliche Warnung aussprechen: Werden die falschen OEM-Partitionen gelöscht, kann es zum Verlust von Funktionen (die der OEM dort abgelegt hat) oder zu einem gebrickten System (wenn ein modifizierter Bootlader des OEMs entfernt wird) kommen.
Ergänzung: Mögliche Ursache
Inzwischen habe ich zu meinem englischsprachigen Blog-Beitrag diesen Kommentar erhalten. Dem Blog-Leser ist aufgefallen, dass der GPT-Partitionstyp einen fehlerhaften Wert aufweist. Normalerweise sollte dieser den Wert 0x8000000000000001 aufweisen, was Windows anweist, dieser Partition kein Laufwerk zuzuweisen. Die mit einem Laufwerksbuchstaben versehenen GPT-Partitionen hatten aber die Kennung 0x0000000000000001, wodurch Windows 10 den Laufwerksbuchstaben zuweisen muss. Also gilt es, nach dem Entzug des Laufwerksbuchstaben noch die GPT-Partitionskennung mit einem Drittanbieter Partitionierungstool oder diskpart entsprechend anzupassen (siehe auch Windows 10 V1803 und das GPT-Partitionsproblem).
Noch eine Erklärung zu den obigen Kennungen. Microsoft hat in diesem Beitrag die GPT_BASIC_DATA_ATTRIBUTES offen gelegt.
- GPT_ATTRIBUTE_PLATFORM_REQUIRED: Wert 0x0000000000000001; Bedeutung: Ist das Attribute gesetzt, wird die Partition benötigt, damit das System funktioniert.
- GPT_BASIC_DATA_ATTRIBUTE_NO_DRIVE_LETTER: Wert 0x8000000000000000; Bedeutung: Ist das Attribute gesetzt, darf das Betriebssytem dieser Partition keinen Laufwerksbuchstaben zuweisen.
Offenbar ist das letztgenannte Attribut beim (oder vor dem) Upgrade auf Windows 10 Version 1803 verloren gegangen. Folgerichtig weist der Installer der Partition einen Laufwerksbuchstaben zu.
Ähnliche Artikel:
Microsoft kündigt Windows 10 April 2018 Update zum 30.4. an
Windows 10 April Update: ISO-Installationsabbild herunterladen
Windows 10 Version 1803: Update KB4135051 (Insider Preview)
Windows 10 April Update ist da – Downloads und mehr
Anzeige
Boot und Uefi Partitionen kann man zwar Ausblenden bzw. verstecken, sollte man aber nach Möglichkeit unangetastet lassen da sich sonst der Rechner nicht mehr starten (booten) lässt.
Auf jeden Fall lassen sich doppelte oder mehrere Recovery Partitionen mittels diskpart löschen und dann entweder der Windows Partition oder einer Zweit Partition hinzufügen. Ganz Wichtig man sollte jedoch vorher mal zur Sicherheit ein Backup (1:1 Datenträgerabbild) erstellen.
Mich würde mal interessieren ob es unter Windows eine sichere Möglichkeit gibt heraus zu finden welche der Recovery Partitionen die Windows so großzügig erstellt zum Momentanen Betriebssystem gehört, ist denn das nun die erste vor oder nach der Systempartition von Windows?
Ich hab das hier auf einem Notebook eines Bekannten von mir festgestellt das Windows im Laufe der Zeit drei Recovery Partitionen mit je 850MB auf einer 128GB SSD auf der eh schon Platzmangel herrscht erstellt hat, die sind wohl mit der zeit mit den verschiedenen Windows Upgrades hinzugefügt worden.
Ich hab dann ein 1:1 Backup erstellt und so lange herum probiert bis ich zwei dieser Ominösen Recovery Partitionen löschen und der Systempartition wieder hinzufügen konnte.
Ich kann dem Puritaner nur beipflichten. Es gibt bei mir die neue OEM-Partition mit 450 MB und eine alte mit 300 MB. Kann man die alte jetzt löschen?
Ich hatte das Problem hier bei einem (von vielen upgedateten) PC.
Eine Recovery-Partition war als Laufwerk G eingebunden und Windows meckerte häufig über zu wenig Speicherplatz.
Habe im Netz gefunden:
mountvol G: /D
als Administrator eingegeben.
So sollte die Partion noch vorhanden sein, ist aber kein Laufwerk mehr und wird nicht mehr bemeckert. Ist auch nach Neustart noch so.
Danke für die Ergänzung, war mir entfallen. Ich habe es (mit Verweis auf deinen Kommentar) noch oben im Text eingefügt – dürfte für viele Nutzer etwas einfacher als mit diskpart sein.
Habe versucht die leidige Meldung "Wenig Speicherplatz" mit dem Befehl mountvol E:/D über die Administrator Eingabeaufforderung auszuschalten, hat aber leider nicht geklappt.
Können Sie vielleicht noch ein Sreenshot der Administrator Eingabeaufforderung mit dem mountvol Befehl erstellen.
Danke
Danke für die vielen Informationen zu diesem Bug. Ein Glück, dass es dieses Blog gibt und ich wöchentlich die Beiträge verfolge. Dafür ein mal ein herzliches Dankeschön.
Somit wusste ich schnell Bescheid, als ich am Lenovo T460s einer Kollegin auf eine leere Partition blickte und nach einblenden der versteckten Dateien einen recovery Ordner erblickte:
Ich hatte zunächst auch erfolglos mit diskpart probiert, den Laufwerksbuchstaben zu entfernen. Nach dem Neustart war das Laufwerk weiterhin vorhanden. Dasselbe übrigens auch nachdem ich mit Paragons Festplattenmanager 16, via Rettungsstick, den Laufwerksbuchstaben entfernt hatte. Mit mountvol hate es dann geklappt. Auch nach dem Neustart blieb das Laufwerk verborgen.
Nachtrag: Ich hatte den exit Befehl bei diskpart übersehen? ist der eventuell dafür verantwortlich, dass es via diskpart nicht funktionierte?
Der exit-Befehl sollte eigentlich nicht relevant sein, da er nur diskpart beendet. Möglicherweise war die falsche Partition im Eingriff. Aber Du hast ja mit mountvol das Problem gelöst.
Hallo. Vorab, ich habe keine Ahnung von PCs und so nem Zeug :)
Ich habe es so eingegeben wie gesagt und das G durch E ausgetauscht, weil das bei mir Lokaler Datenträger E heisst. Mir wird aber der Zugriff verweigert.
Wissen sie eine Lösung?
Dann läuft die Eingabeaufforderung nicht mit administrativen Rechten.
Merkwürdige Geschichte.
Auf einem Gerät (UEFI) bei mir ist das nach Update 1803 ebenfalls aufgefallen.
Jetzt gibt es als OEM-Partitionen eine
„Wiederherstellungspartition 450 MB NTFS (OEM-Partition)" und eine
(rund) „800 MB NTFS (OEM-Partition)".
Bezeichnungen laut Datenträgerverwaltung (keine Laufwerksbuchstaben).
Laut reagentc /info (Eingabeaufforderung Administrator) sei die mit rd. 800 MB WinRE. Ob das zuverlässig ist mit dem Befehl weiß ich nicht.
Fragt sich, soll das so sein, gäbe es es einen Sinn?
Wenn nein, wäre in diesem Fall die kleine OEM-Partition dann überflüssig;
und könnte vlt. gelöscht werden?
ich habe das lästige <Laufwerk einfach
mit dem Mini Tool Partition Wizzard free gelöscht.
@Kunsorow123:
Mit reagentc /info liegst Du mMn völlig richtig!
Entschuldige, wenn ich Deinen Nickname in meinem Beitrag falsch angegeben habe.
Deine Frage kann ich Dir ohne genaue Kenntnis der Lage und ohne Erfahrungen mit UEFI-BIOSsen nicht beantworten.
Versuche irgendwie festzustellen, ob in der alten Partition überhaupt noch etwas Sinnvolles drinsteht.
Blind(wütig)es Löschen einer Partition halte ich für kontraproduktiv.
Im genannten Beitrag findest Du einen vielleicht für Dich
sinnvollen Link.
Gruß, Nemo
Das Problem wird normal werden, da immer mehr neue Hardware grundsätzlich eine UEFI-Installation verlangt. Alle 6 Monate kann ein neues Windows 10 Funktionsupdate die Partitionen durcheinander würfeln, was einen heiden Spaß macht.
Ich schätze, dass mit Windows 10 die erzwungenen Neuinstallationen einen Rekordwert erreichen. Windows 7 habe ich 2014 das letzte mal neu installiert mit dem Austausch des Mainboards. Windows 10 ist seit 2015 ohne Änderung der Hardware 3 mal neu installiert worden, weil nichts mehr ging. Und dabei sichere ich grundsätzlich per Imagesicherung. Aber die werden nutzlos mit einer neuen Windows 10 Version.
Bei mir hats eben gerade auf meinem Notebook mal hin gehauen, keine neue Partition hinzugekommen aber ich kann mich noch gut an das Windows 10 Fall Creators Update erinnern da musste ich auch neu installieren, das "neue Hardware grundsätzlich eine UEFI-Installation verlangt" stimmt nicht so ganz falls du noch ein Linux mitverwendest würde allein schon aus Prinzip von eine Uefi Installation abraten.
Aber du hast Recht sofern man unter Windows 7 nicht ständig was neues Probiert lief Windows 7 recht anspruchslos und ich weiß nicht wo der Sinn darin liegt alle halb Jahr das System per Upgrade Komplett neu zu installieren.
Vielen Dank für diesen Hinweis. Hat bei mir mit "mountvol J: /D" super funktioniert.
FYI: bei einer Neuinstallation funktioniert es wie gehabt.
eine Wiederherstellungspartition (499MB), eine EFI-Systempartition (100MB) beide ohne Laufwerksbuchstabe und dann der entsprechende Datenträger C.
Nach Microsoft vorgaben soll die Recovery Partition eigentlich am Ende des Datenträgers angelegt werden damit sie vom Setup, falls notwendig, vergrößert werden kann. Nur hält sich halt keiner dran, MS selber auch nicht.
https://docs.microsoft.com/de-de/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions
In SCCM wurde das Layout erst mit Version 1706 gefixt, allerdings muss dazu eine neue TS erstellt werden. In MDT ist der korrigierte Zustand 499 MB (anstatt 350 MB) allerdings auch am an Anfang des Datenträgers.
Reddit Diskussion dazu:
https://www.reddit.com/r/SCCM/comments/7eh3kk/fyi_update_your_ts_partition_steps/
Das aktuelle Update läuft in Summe bei mir schon etwas zuverlässiger als noch vor 6 Monaten oder davor, aber von ausgereift würde ich noch nicht sprechen. Vielleicht ausgereifter in Sachen Schnüffelei (gefühlte 100 Einstellungen mehr), damit Otto-Normal-Verbraucher nicht mehr alles abstellen kann ;-)
Nicht nur UEFI & Linux-Dualboot killt alle 6 Monate den Geräte-Start, sondern auch Legacy mit Grub2 geht bei mir regelmäßig in die Hose.
Wenn es gut läuft, sind nur die Grub-Menüs zu reparieren, diesmal ist mir ein Acer V5 mit NVIDIA-GPU bei 75% noch kurz vor der Fertigstellung des Updates abgeraucht. Ich habe mich entschieden ein Sicherungs-Image mit Clonezilla zu reaktivieren.
Ich meine mich an einen Artikel in diesem Forum vor knapp ein bis zwei Jahren zu erinnern. Wo es in einem anderen Zusammenhang darum ging, dass der Ärger mit der OEM Partition genau dann los geht, wenn der Platz darauf ausgeht und Windows selbst nach Alternativen sucht (sprich eine neue OEM Partition anlegt).
Ich glaube, dass Problem begann mit dem 1609 Upgrade, wo so einiges bei der Umstellung in die Hose gegangen ist (auch bei den Benutzerrechten in Verzeichnissen und Dateien). Und wer sein System immer fleißig weiter upgradet und nicht zwischenzeitlich neu aufsetzt, wird wahrscheinlich in immer größere Schwierigkeiten geraten.
Ich habe ein System nach dem Testen der ursprünglichen 1803 neu aufgesetzt. Und muss sagen, dass sich die knapp eine Woche für die Neuinstallation aller Programme gelohnt. (Ja, dauert leider so lange, wenn man für die Programmentwicklung nicht nur die Standprogramme eines Windows/Browsers/Office verwendet). Leider gibt es viele Programme, die einem eine Neuinstallation vermiesen, weil man sie vor dem Neuaufsetzen deaktivieren muss. Weil sie sonst danach nicht erneut aktiviert werden können. Nicht jedes Produkt gestattet es einem wie TrueImage, die alten Aktivierungen einfach wegzukanten.
Aber das neu aufgesetzte Windows ist nicht wieder zu erkennen. Höhere Geschwindigkeit, wesentlich weniger Probleme. Selbst Grafikprobleme mit der UE4 (Überbelichtung) sind mit einem Mal verschwunden. Scheint, dass das ständige Upgraden und Updaten sich auf ein System irgendwann nicht mehr so positiv auswirkt. Selbst wenn man nicht an den Einstellungen und Treibern herumspielt.
bei mir ist das Problem nur auf dem Hauptrechner aufgetaucht. Mein Convertable hat keine neue Partition gebastelt. Möglicherweise auch, weil nichts mehr frei war.
Das jetzt jeder manuell das Problem beheben soll anstatt, dass MS das über das nächste Update repariert ist in Anbetracht der Verbreitung von Windows ein Armutszeugnis von MS.
Als Tipp zur besseren Lesbarkeit: Nummeriere doch auch in der deutschen Version die Lösungsvorschläge durch (#1 #2 …). Fand ich in der englischen Version deutlich übersichtlicher als "Oder …"
Bei mir ist die Situation folgende:
Das Wiegerherstellungslaufwerk ist in der Datenträgerverwaltung vorhanden. Wird aber als leer ausgewiesen, kein Laufwerksbuchstabe zugeordnet und LIST VOLUME führt es auch nicht auf.
Also ist es da, aber ich kann es nicht deleten, weil es nicht da ist !!?? ;-)
Vielen Dank für die ausführliche Anleitung. Genau so muss man vorgehen.
Die Antwort von GBorn war sehr gut.
Nach seiner Anweisung, mit dem Befehl „diskpart", habe ich Windows zum Schweigen gebracht. Die Meldung „zu wenig Speicher" wird nicht mehr angezeigt.
Danke für den ausführlichen Hinweis.
Vielen, vielen, vielen Dank! :) Endlich ist Ruhe! Wielange habe ich danach gesucht…
Herzlichen Dank für Ihren Blog, welcher mir schon oft geholfen hat. Diesmal auch mit dem Driveletter OEM Partitions Bug, nach dem Update 1803.
DANKE !
Vielen Dank! War Erfolgreich mit ihrer ausgiebigen Problemlösung!
Machen Sie weiter so!
MfG
Vielen Dank. genau das wonach ich gesucht habe.
Mal eine naive Frage: Ist denn damit zu rechnen, dass dieses Problemchen (Alle 10 Minuten ploppt die nervige Warnung auf) mit dem nächsten Update behoben sein wird. Mir ist nämlich mit der eigenhändigen Fehlerbehebung nicht wirklich wohl.
Ich kann es definitiv nicht beantworten. Meiner persönlichen Einschätzung nach wird Microsoft aber nichts per Update reparieren. Der Fix 'Mount Point entfernen' sollte auch für nicht so erfahrene Nutzer machbar sein. Man muss sich im Grunde nur den richtigen Laufwerksbuchstaben merken.
Vielen Dank für die Info. Nur noch eine Verständnisfrage. Bei mir wird das LW J angemahnt. Wird durch mountvol J:/D das LW nur versteckt oder wird es entfernt und wird wieder frei ? Ich habe eben unter J: ein externe Festplatte und würde die gerne auch beibehalten.
Mit dem Befehl wird der Buchstabe J: als logisches Laufwerk entfernt, dann sollte die externe HD wieder auftauchen – falls deren Laufwerksbuchstabe nicht durch das Upgrade zerdeppert wurde.
Danke! hab gestern mein Upgrade gemacht (dachte ich muss meinen Lapotp nur wegen einem normalen Update neustarten..Danach gingen die Fn Tasten (Lenovo Thinkpad) nicht mehr anständig, die Laustärke regelung hat wahnsinnig gehangen.
Und wie oben beschrieben hat die OEM Recovery Partition einen Buchstaben bekommen.
Nach einmal Ruhezustand funktioniert jedoch die Fn Geschichte mit Laustärke wieder, nur das Laufwerk ist noch da. Bei mir jedoch als 34,8 MB frei und 498 MB groß.
Danke für diesen Artikel. war das einzig nützliche dass ich dazu finden konnte.
Hallo,
danke für den Artikel. Hab es mit diskpart gut umgangen.
Warum schickt Microsoft bei so einem dämlichen Bug eigentlich nicht sofort einen Fix nach?? Bei Android Apps bekommt man gefühlt jeden Tag ein mini-update, warum braucht eine so große Firma für die Beseitigung eines lästigen Unsinns-Bugs so lange?
LG
Bei Android bekommst Du üblicherweise nur für Apps und die Play-Services Updates. Das ist was fundamental anders als für den Windows 10 Kern.
Hallo, habe dasselbe Problem gehabt, wo sich dann die 450mb Partition G erstellt hat. Habe die in cmd mit dem disk part remove letter entfernt.
Nun lässt sich mein PC nicht mehr starten, was kann ich jetzt tun?
Mit einer Rettungsdisk (Windows 10 DVD oder USB-Installationsstick) booten und schauen, ob man mit diskpart was re-aktivieren oder Windows reparieren lassen kann. Da ist vermutlich was bei diskpart falsch gelaufen (Buchstabe für ein anderes logisches Laufwerk deaktiviert).
Wenn das nicht hilft, bleibt nur eine Reparaturinstallation aus Windows PE oder ein Recovery.
Nach jedem neuen Funktionsupdate kann so was wieder vorkommen.
Ich habe deshalb eine UEFI-Installation vermieden.
Bei neuen Geräten kann man das immer weniger, da sie vom Werk aus für Windows 10 vorgesehen sind und der legacy Modus nicht mehr ausgewählt werden kann. .
Danke für den Tip. Mit Diskpart ist die Zuordnung zum Laufwerksbuchstaben jetzt weg. Mein Homeserver hat ständig Warnungen wegen zu wenig Speicherplatz auf diesem Client-Laufwerk ausgespuckt. Nu ist Ruhe.. erstmal.
Danke!
Also ich habe keine Ahnung was ich da machen soll ich versteh das einfach nicht. Könnte mir das jemand Schritt für Schritt erklären ?
Nix für ungut – die obigen Hinweise sind Schritt-für-Schritt, aber man sollte wissen, was man tut. Andernfalls gibt es lokale Dienstleister, die das für kleines Geld erledigen.
Vielen Dank, hat super funktioniert
Hallo zusammen.
Dieses Problem mit der OEM-Partition hatte ich auch vor kurzem nach dem Update auf 1803. Mitten zwischen System- und Datenpartition tauchte auf einmal diese OEM-Partition mit 450 MB Größe auf. Die ersten paar Mal Neustart erschien nur die Speicherplatzwarnung, sonst lief der Rechner aber. Dann kam aber der Hinweis: 'Kein Speicherplatz mehr vorhanden' und danach lief nichts mehr. Beim Neustart des System kam ich nur noch bis zum 'blauen Donut', die Festplatten-LED bescheinigte mir, das die Platte eifrig ihren Dienst tat, aber auch nach über einer halben Stunde kein Ergebnis.
Da dieses Verhalten naheliegenderweise mit dem Platzproblem auf der OEM-Partition zu tun hatte, habe ich den Rechner mit gparted gebootet, meine Datenpartition verkleinert und an das Ende verschoben und somit Platz für die OEM-Partition geschaffen. Nach einem Start im abgesicherten Modus und einem erneuten Neustart lief dann aber alles wieder wie gewohnt.
Ich habe im Anschluss dann – wie oben beschrieben – mit diskpart noch den Laufwerksbuchstaben entfernt und aus die Maus.
Obwohl ich einen etwas anderen Lösungsweg für das Problem gewählt habe, bin ich sehr dankbar für die hier gefundenen Anregungen und Lösungsvorschläge.
Herzlichen Dank an GBorn für die verständlichen Ausführungen zum Befehl diskpart.
Hat super geklappt.
Ganz neu ist das vom Hausherrn beschriebene Problem nicht.
Beim Upgrade von Win10-v1511 auf v1507 fiel mir zum ersten Mal auf, dass mir eine zusätzliche Wiederherstellungspartition untergejubelt wurde. Nicht so gravierend wie im neueren Fall (mit zusätzlichem Lw-Buchstaben); aber trotzdem ärgerlich genug, da "mein" Partitionsschema durcheinandergebracht wurde.
Bevor hektisch irgendeine Partition gelöscht oder ihr ein Lw-Buchstabe entzogen wird, sollte man sich mit entsprechend dem Vorschlag von Forist Konsurow123 https://www.borncity.com/blog/2018/05/02/windows-10-v1803-erzeugt-neue-oem-recovery-partition/#comment-57393
erst einmal einen Überblick darüber verschaffen, wo Windows die Wiederherstellungsumgebung mit WinRE.wim verortet.
Das deckt sich mit dem, was ich unter
"Wiederherstellungsumgebung (RE) (zurück-)verlegen"
https://www.win-unattended.de/viewtopic.php?f=13&t=349
mit Lösungsansätzen dokumentiert habe.
Unter Abschnitt 5 zeige ich dort mein aktuell bevorzugtes Partitionsschema mit großzügig bemessener Wiederherstellungspartition auf. Zwar beziehe ich mich dort auf auf Legacy-HW; jedoch sollten sich die Erkenntnisse auch auf UEFI-Rechner mit zusätzlichen UEFI- und MSR-Partitionen übertragen lassen.
Damit verlieren hoffentlich die halbjährlichen Upgradezirkusfestivals ihren Schrecken.
Gruß, Nemo
Der Lauf werks buchstabe kann im Windows 10 wie folgt gelöscht werden:
Windows PowerShell (Administrator) aufrufen
mountvol x: /d
x: zu löschender LW-Buchstabe
In der Datenträgerverwaltung sehen Sie das Ergebnis.
Hat super geklappt, nachdem ich mich als Admin bei der Eingabeeinstellung anmelden konnte. Zuvor fand ich auch nicht, wie ich da als Admin arbeiten kann. DANKE… endlich wieder ohne die nervenden Hinweise
Hurra!!!
Nun kann ich wieder ungestört ohne Meckerei von Windows arbeiten. Nach einigen Anläufen hat es geklappt.
Vielen vielen Dank für den unkomplizierten Tipp.
Ich möchte die Systempartition (C:) gern erweitern, weil ich eine zweiter Partition (D:) auf dieser SSD installiert habe aber jetzt liegt diese OEM Partition (H:) dazwischen.
Was nun? Diese H: Partition müsste ich doch zumindest verschieben oder löschen (435 MB frei von 449 MB )?
Gruß
Mit einem anständigen Partitionierungs-Manager sollte es gehen, wenn das log. Laufwerk auf der SSD liegt. Es sei denn, da wurden undokumentierte Partitionskennungen verwendet.
Danke, funktioniert wohl!
Hatte auch eine (relativ) nervige (I:)-Platte-Voll-Meldung.
Habe es mit der Kombination
mountvol I: /D
diskpart
list volume
select volume 3
attributes volume set nodefaultdriveletter
exit
gelöst. Mal sehen ob es hält, aber da bin ich optimistisch
Hallo Günter, gute Nachrichten. Microsoft hat sich erbarmt den Fehler zu beheben. Beim Upgrade eines 1803 Windows wo ich diese Laufwerke extra unberührt gelassen habe, in der Hoffnung des Nachweises MS würde es mit einem Monatsupdate fixen – was nicht geschah – nach dem Upgrade auf 1809 ist es nun wieder verschwunden wie es sich gehört.
Beste Grüße
Karl
Glückwunsch an Karl (al Qamar)!
Bei mir ist's gerade umgekehrt: 1803 lief anstandslos, das Problem trat jetzt erst nach dem Update auf 1809 auf. Seit Tagen quält mich mein Windows mit immer neuen Systemabstürzen und ominösen neuen Partitionen. Ich werde gleich mal die hier genannten Lösungsansätze probieren, schon vorab gleich mal herzlichen Dank!
Thomas
Hallo,
dien Blog hat mein Problem schon etwas erhellt. Recovery ist Volume 2 bei mir ohne Laufwerksbuchstabe. Der Wiederherstellungspunkt soll aber lauf WinRe auf Volume 4 erstellt werden.
Das Problem tauchte auch nach einem Update auf.
Hast Du vielleicht dafür eine Idee?
Ich habe UEFI-Installation mit 1803 erstellt – da hatte ich dieses Layout.
https://docs.microsoft.com/de-de/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions#partition-layout
Jetzt nach Upgrade auf 1903 dieses – Screenshot – Link auf meiner HiDriveCloud.
Keinen Sorge Link/Bilddownload ist sauber.
https://my.hidrive.com/lnk/lugDiNJP
Wohlgemerkt im WIN-Explorer ist außer 1-1 C-Laufwerk und 1-2-D-Laufwerk sonst nichts sichtbar.
Ext. Geräte werden weiterhin einwandfrei angezeigt.
alles sehr eigenartig.
Noch schlimmer: Plötzlich habe ich ein 105-MB-Volume (OEM oder was auch immer) mit dem LW-Buchstaben C: und das alte LW C: (auf dem Windows liegt) hat nun den Buchstaben D:
Ergebnis: Nichts läuft mehr, automatische Reparatur startet (und scheitert) immer wieder. Dem LW C: den Buchstaben "entziehen" und LW D: in C: umbenennen?