Jo, so ists auch richtig und von mir gemeint. ;)

@moinmoin
Also ich habe das Update auf Build "17763.55" mit KB4465477 (SSU) und KB4464330 (kum.) durchgeführt.
Und das anschließende Update auf Build "17763.134 erfolgte (am 13.11.) mit den obengenannten "KBs".

@WinRE Das SSU gab es im Zusammenhang mit der *.55. Danach keine neuere Version (außer heute natürlich)
Aber gut, dass du darauf hinweist. :)

Dann ist ja alles gutgegangen. Woran es denn nun lag - wer weiß?

Wenn der "große Sprung" von ".55" auf ".134" [u]manuell[/u] durchgeführt wurde:
Hattest Du [u]vor[/u] dem kumulativen Update "KB4467708" auch das sog. Service-Update (SSU)
"KB4465664" installiert? Auf die Notwendigkeit wird hier im Forum regelmäßig hinge-
wiesen. Wenn vorhanden, sind die entsprechenden Download-Links auch angegeben.
Ich weiß zwar nicht, welche Wirkung diese "Regelverletzung" nach sich zieht, aber
vielleicht könnte dadurch Dein Problem entstanden sein?!

Hallo WinRE,

Sorry, ich habe einen großen Fehler mit der Betreffzeile gemacht. Ich habe ein Update von der 55 auf die 134 durchgeführt. Hierbei entstand der o.a. Fehler. Der Fehler bezieht sich einzig und allein auf dieses Update. Das ehemals beigefügte Bild spiegelt die Situation wieder. Ich habe die Betreffzeile nun geändert. Es ist klar, dass dies verwirrend war und ich bitte vielmals um Entschuldigung.

Nachdem ich die defekte 134 mittels meines Backups wieder auf die 55 downgegradet hatte, habe ich mir versuchsweise mit dem MediaCreationTool die 107 geholt und installiert und siehe da: die Recovery war in Ordnung, enthielt wieder WinRE, alle Funktionen waren vorhanden.

Auf diese Installation der 107 konnte man nun problemlos die 134 installieren. Die Version läuft jetzt bei mir ohne Probleme.

Das Problem trat also lediglich bei einem Sprung von der 55 auf die 134 auf.

CORTANA würde ich nicht so bevorzugen, weil sie relativ dumm ist. :lol: Alexa und Echo oder den Assistent von Lenovo würde ich dann schon mehr favorisieren.

Freundliche Grüße
Fuchs

Irgendwie ist mir nicht klar, wie Dein(e) Update(s) tatsächlich erfolgt ist/sind:
Eingangs sprichst Du von einem Update auf "Build *.107". Die Screenshots
beziehen sich auf die ursprüngliche "*.55" und die derzeitige ".134"!? Nebenbei
erwähnst Du auch noch die "Insider-Builds *.104 und *.107". Wenn also zwischendurch
weitere "Updates" eingespielt wurden, so wird es noch schwerer werden, der Ursache
auf den Grund zu gehen.

Gäbe es eine "neue" Recovery-Partition, so würde sie in der Datenträgerverwaltung
aufgeführt - es sei denn, sie hätte den Status "versteckt". Sie kann sich auch nicht in
einer anderen Partition befinden. Dein "Größenvergleich" ist leider auch kein Indiz,
zumal Du hier die unterschiedlichen Einheiten [MB] und [GB] übersehen hast.

Ich vermute/behaupte - wie auch schon an anderer Stelle erwähnt, aber ohne Reaktion
geblieben -, daß die "Recovery" (belegt ca. 444 MB von ca. 499 MB) aus "Sicht von Windows"
zu klein war, um die neuen Daten aufzunehmen. (Dabei gibt es doch den systeminternen
Taschenrechner.) In der Folge hätte nun eine "neue Recovery" (hinter der Start-Position)
auftauchen müssen, während die "alte" unverändert ihr nunmehr nutzloses Dasein gefristet
hätte. Aber WANN ist diese Aktion schiefgelaufen?

Auch ich würde gerne wissen, was sich dort in der "Black-Box Windows" abspielt - vielleicht
mal CORTANA fragen?

… Entschuldigung, ich hatte mich nicht eingeloggt-Sorry!

Das Bild wird nicht angezeigt, offensichtlich war es zu gross. Hier noch einmal der Link zum anschauen:

[url]http://www.myimg.de/?img=Macrium6b970.png[/url]

Grüße, Fuchs

Hallo miteinander,

Ich habe mal das Update von *. 55 auf *. 134 deutlich gemacht mit diesem Bild:

http://www.myimg.de/?img=Macrium6b970.png

Die untere Festplatte ist die *.55 während die obere Festplatte die upgedatete *.134 ist. Auffällig ist, dass alle Partitionsgrößen gleich geblieben sind. Während in der ursprünglichen Festplatte die Recovery-Partition gut gefüllt ist, ist diese in der upgedateten Partition fast leer (in der Partition befindet sich nur ein Verzeichnis LOGS). WinRE ist nicht mehr zu finden. Gleichzeitig hat sich die Partition OS ungewöhnlich gefüllt. Die Differenz ist in etwa die, die in der Partition Recovery verloren gegangen ist. Offensichtlich wurde fälschlicherweise die Recovery-Partition in die OS-Partition kopiert und eine neue Recovery-Partition erstellt.

Ich benutze übrigens ein UEFI- System, die Unterschiede zu BIOS sind mir noch nicht aufgefallen. Die ständig wechselnde Festplatten-Aufteilung ist ein Ärgernis vor allem im Hinblick auf die Updates. Allerdings ist zu sagen, dass das Vorgehen mit den ISO-Dateien auch seine Tücken hat.

Folgende Vorgehensweise ist ausprobiert und für gut befunden:

Offiziell gab es am 2./3. Oktober Build 17763.1, dann eine Woche später Build 17763.55.
Für Insider (Slow und Release Ring) gab es noch die Build 17763.104 und Build 17763.107, siehe

[url]https://blogs.windows.com/windowsexperience/2018/09/18/announcing-windows-10-insider-preview-build-17763/.[/url]

Beim Installieren über das Media Creation Tool wird bei aktiver Internet-Verbindung sofort Build 17763.107 installiert, muss dann auf Build 17763.134 aktualisiert werden.

Viele Grüße
Fuchs

@Mike2018 Sei so gut und verwende nicht die Zitatfunktion, wenn du direkt antwortest. Das macht hier alles nur unendlich lang.

[quote=DK2000 post_id=320711 time=1542233415 user_id=39966]
Nö, das is nicht unbedingt die halbe Wahrheit. Das ist irgendwie das Windows Setup beim Upgrade. Das hat da so seine eigenen Vorstellungen, was die Wiederherstellungspartition angeht.
...
Ist mir von der Logik her nicht ganz klar, warum das Setup beim Upgrade mit BIOS/MBR da so eine große Wiederherstellungspartition braucht und diese auch beim Upgrade zusätzlich neu anlegt und bei UEFI/GPT reicht die 450MB Partition am Anfang und es wird nichts neu angelegt. Aber kann nicht ausschließen, dass es auch bei UEFI vorkommt, dass die Wiederherstellungspartition neu angelegt wird. Nur trat das bei mir noch nicht auf.

Wäre in dem Zusammenhang interessant zu wissen, ob es hier um BIOS/MBR oder UEFI/GPT geht.

Und die Sache mit den Wiederherstellungspunkten, die klappt nach wie vor einwandfrei. Diese werden im Ordner 'System Volume Information' angelegt. Das hat nichts mit dem leeren RegBack-Ordner zu tun. Das ist ein komplett unabhängiger, leider im Moment nach wie vor defekter Backupmechanismus, welcher in regelmäßigen Abständen eine 1:1 Kopie der Registry anlegen soll, unabhängig ob sich etwas verändert hat oder nicht.
[/quote]

[u]Danke für den Hinweis zu den WHPs[/u]. Ich wußte, daß sie im Ordner "System Volume Information" gespeichert werden. Dann hatte ich aber während der Diskussionen rund um den "RegBack-Ordner" den Eindruck gewonnen, daß die dort gespeicherten Inhalte zusätzlich für eine Wiederherstellung benötigt würden.

[u]Die "Recovery-Partition(en)":[/u]
Bei "UEFI/GPT" ist das bei mir auf verschiedenen Rechnern mehrmals aufgetreten.
Ich kann mich allerdings nicht mehr genau erinnern, glaube aber, daß bei einer Neuinstallation von "Win10 -
Version 1709" eine neue "Recovery" HINTER der Start-Partition angelegt wurde. Die alte, am Anfang der Festplatte liegende "Recovery" (Partition 1 mit einer "typischen" Größe von 450 MB) blieb fortan "unbeachtet", obwohl ihre
Größe in einem Fall (knapp) ausreichend gewesen wäre. Gleichzeitig gibt es eine andere Situation, in der die neue "Recovery" mehr Speicherplatz beanspruchte (ca. 470 MB bereits bei Version 1803).
Ich habe das Thema irgendwann "abgehakt", schaue aber nach einem Upgrade nach, ob sich Windows
wieder mal in die Partitionierung eingemischt hat. Beim Upgrade auf "Version 1809" hat sich jedenfalls nichts
geändert.

Nö, das is nicht unbedingt die halbe Wahrheit. Das ist irgendwie das Windows Setup beim Upgrade. Das hat da so seine eigenen Vorstellungen, was die Wiederherstellungspartition angeht.

Normaler Weise sieht es so bei mir auf dem Laptop mit BIOS/MBR so aus (vor Upgrade auf 1809):

1. Systempartition 100MB
2. Startpartition
3. Wiederherstellungspartition 850MB

Nach dem Upgrade auf die 1809:

1. Systempartition 100MB
2. Startpartition
3. Wiederherstellungspartition 875MB (neu angelegt, mit WinRE.wim)
4. Wiederherstellungspartition 850MB (alt, leer)

Also wieder Hand angelegt, Partition 4 gelöscht, Partition 3 ans Ende verschoben und Partition 2 entsprechend vergrößert.

Das Verhalten habe ich aber nur bei Installationen mit BIOS/MBR (auch in der VM).

In der VM mit Windows im UEFI Modus mit GPT bleibt das Partitionschema erhalten, seltsamer Weise:

1. Wiederherstellungspartition 450MB
2. Systempartition (ESP) 100MB
3. $MSR 16MB
4. Startpartition

Ist mir von der Logik her nicht ganz klar, warum das Setup beim Upgrade mit BIOS/MBR da so eine große Wiederherstellungspartition braucht und diese auch beim Upgrade zusätzlich neu anlegt und bei UEFI/GPT reicht die 450MB Partition am Anfang und es wird nichts neu angelegt. Aber kann nicht ausschließen, dass es auch bei UEFI vorkommt, dass die Wiederherstellungspartition neu angelegt wird. Nur trat das bei mir noch nicht auf.

Wäre in dem Zusammenhang interessant zu wissen, ob es hier um BIOS/MBR oder UEFI/GPT geht.

Und die Sache mit den Wiederherstellungspunkten, die klappt nach wie vor einwandfrei. Diese werden im Ordner 'System Volume Information' angelegt. Das hat nichts mit dem leeren RegBack-Ordner zu tun. Das ist ein komplett unabhängiger, leider im Moment nach wie vor defekter Backupmechanismus, welcher in regelmäßigen Abständen eine 1:1 Kopie der Registry anlegen soll, unabhängig ob sich etwas verändert hat oder nicht.

Könnte es vielleicht sein, daß im Zuge des Updates eine neue "WinRE-Partition" angelegt wurde?
Diese Partition dürfte dann aber nach der Wiederherstellung der vorherigen Version verschwunden
sein!?
(Vor einiger Zeit wurde das Thema zusätzlicher Recovery-Partitionen ausgiebig diskutiert. Ob und
wann Windows so verfährt, kann ich nicht sagen. Ich selbst habe immer vermutet, daß eine neue
Recovery-Partition angelegt wird, wenn der benötigte Speicherplatz nicht mehr ausreicht. Das ist
aber nur die "halbe" Wahrheit.)

Und zu den Wiederherstellungspunkten: Diese Funktion ist immer noch "defekt" (leerer RegBack-Ordner),
hat aber auch keinen unmittelbaren Bezug zur Recovery-Partition.

Ja, jetzt verstehe ich.

Die 17763.55 gibt folgendes Ergebnis aus:

Konfigurationsinformationen zur Windows-Wiederherstellungsumgebung (WinRE) und
zur Systemwiederherstellung:

WinRE-Status: Enabled
WinRE-Ort: \\?\GLOBALROOT\device\harddisk2\partition1\Recovery\WindowsRE
Startkonfigurationsdaten-ID: 9fabc1df-c0a8-11e8-8786-fd7513ccf783
Ort des Wiederherstellungsimages:
Index des Wiederherstellungsimages: 0
Ort des benutzerdefinierten Images:
Index des benutzerdefinierten Images: 0

Viele Grüße
Fuchs

Nemo meinte damit die 17763.55

Hallo Nemo,

Einen Screenshot kann ich leider nicht mehr erstellen, da ich ja die vorherige Version wieder auf meinem Computer habe.

Ich habe übrigens meine Hyper-V VM auch geupdatet, dort ist der Fehler nicht aufgetreten.
REAGENTC habe ich ausgeführt, das Ergebnis erwartungsgemäß: disabled.
Mit *. 55 kann ich leider nichts anfangen. Eine solche Bezeichnung habe ich nicht gesehen.

Viele Grüße
Fuchs