Windows 10 kaputt nach Entfernung anderer Partionen

[Knogle]

Ich gruesse euch liebe community.
ich habe bisher debian parallel zu windows installiert, jedoch bin ich nun von debian auf ubuntu umgestiegen.
daher habe ich die alten debian partitionen inklusive swap geloescht, und ubuntu installiert.
weiterhin musste ich die windows 10 partition verschieben, das hat auch alles geklappt.
nun jedoch scheint die reihenfolge der partitionen anders zu sein, und windows kommt damit nicht klar.
das heisst: wenn ich windows starte, kommt der ladewurm unten, und irgendwann ist er weg, und das system startet ohne fehlermeldung einfach neu.
habe dann viele dinge probiert mit bcdedit etc. das hat aber nun darin geendet dass das system schon direkt neustartet wenn ich windows im grub menu auswaehle, also noch nichtmal mehr der ladewurm kommt.
hat jemand eine idee wie ich das reparieren kann?
neuinstallation ist erstmal keine option fuer mich wobei das wohl schneller waere, jedoch moechte ich auch lernen mit solchen problemen umzugehen, und nicht immer die neuinstallation zu machen, wobei ich auch da dann wieder den grub aufwaendig fixxen darf.
Die Systempartition ist intakt, als auch die Bootpartitionen, nur die Reihenfolge und die Offsets scheinen nun anders zu sein.

 

[HITCHER_I]

siehe https://www.deskmodder.de/wiki/index.php?title=Bootmenü_reparieren_wiederherstellen_Windows_10

Vielleicht ist grub falsch konfiguriert und sucht auf der falschen Partition.

 

[K-BV]

Hallo!

Liefere doch mal dieTerminalausgabe von
sudo parted -l
aus Ubuntu.

Wie hast du die Windows Partition bearbeitet? Mit Gparted wäre keine gute Idee gewesen.

L.G.

 

[Knogle]

Ja tatsaechlich mit Gparted.
Habe zumindest in der Vergangenheit immer sehr gute Erfahrungen damit gemacht vorallem was vergroessern/verkleinern von Partitionen in Windows angeht.

Modell: PM961 NVMe SAMSUNG 512GB (nvme)
Festplatte /dev/nvme0n1: 512GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags:

Nummer Anfang Ende Größe Dateisystem Name Flags
1 1049kB 17,8MB 16,8MB Microsoft reserved partition msftres
4 17,8MB 490MB 472MB ntfs Basic data partition versteckt, diag
5 490MB 595MB 105MB fat32 EFI system partition boot, esp
6 595MB 258GB 258GB ntfs Basic data partition msftdata
8 258GB 512GB 254GB ext4

 

[K-BV]

Die Windows Systempartition(en) immer mit Windows Software, wenn möglich mit der bordeigenen Datenträgerverwaltung bearbeiten. Und Linux Partitionen eben mit Linuxsoftware.Gerade bei Größenveränderungen kann es bei Verwendung von Gparted vorkommen, dass Windows nicht mehr bootet. Die Daten an sich sind aber O.K.

Du hast ein UEFI Dualbootsystem. Ergo solltest du Windows unabhängig von Grub über das direkte Bootmenü des Rechners starten können mit dem Windows Boot Manager. Wie dieses Menü bei deinem Rechner aufgerufen wird musst ggf. selbst nachschlagen. Meist ist es eine hohe F-Taste.

Treten dort die gleichen Fehler auf, ist was kaputt gegangen bei deiner Aktion. Google also nach Windows UEFI Boot reparieren oder ähnlich. Klappt das via Win Boot Manager müsste man Grub noch mal neu konfigurieren. Ggf. hier melden.

Du könntest aber versuchen Windows mit Hilfe der kleinen bootfähigen ISO SuperGrub2Disk zu starten. Klappt das nicht, siehe letzten Absatz.

Poste aber noch mal die Ausgabe von
sudo efibootmgr -v
Falls efibootmgr nicht installiert, auf die gewohnte Weise nachinstallieren.
Vielleicht liegt ja ein Eintrag im NVRAM quer, was ich aber eher nicht glaube.

L.G.

https://www.supergrubdisk.org/super-grub2-disk/

 

[Knogle]

Ich habe irgendwie die Vermutung dass WIndows die geaendert Partitionsreihenfolge nicht mag.
Ich kann WIndows direkt ueber den Boot MAnager starten, also den WIndows BOot MAnager, jedoch kommt halt da genau das gleiche PRoblem, dass direkt nach dem LAdewurm das System einfach sofort neustartet.

SUper GRub 2 werde ich mal probieren.
HABe einige GUides bezueglich REparatur des BOotvorgangs gefunden, jedoch scheiterts bei mir immer am BEfehl "bootrec /fixboot", da kommt immer Zugriff VErweigert, und "bootrec /scanos" findet keine WIndows INstallationen, obowohl die DAten noch tip top sind.

WEnns garnicht geht muss ich wohl WIndows wirklich neu installieren.
DEn GRub BOotloader habe ich sonst immer mit der chroot Methode ueber ein Live System repariert.

Finde aber schade dass Windows im allgemeinen nicht so robust ist.

 

[K-BV]

Ja aber das Problem liegt hier ja wohl bei Windows und nicht bei Grub. Grub macht ja nichts anderes als via chainloading den Windows Boot Manager aufzufordern seinen Job zu tun. Chroot bringt hier gar nichts.

Ich würde ganz einfach mal die automatische Reparatur mit nem W10 Installationsmedium starten.

Ansonsten denke noch mal an die Ausgabe von efibootmgr, siehe oben!

Was heißt robust? Wenn man den Partitionen „rum fummelt“ kann so was gerne mal passieren. Auch bei Linux.

 

[HITCHER_I]

Die Partitionsreihenfolge kann man nachträglich ändern, ohne die Partitionen zu verschieben.
Also man kann den Partition-Table löschen, und dann die selben Partitionen in anderer Reihenfolge (so wie früher) neu eingeben.

 

[K-BV]

Es stellt sich die Frage, ob die UUID verändert wurde. Die Löschung der GPT würde auch Grub ins Nirvana schicken. Bei EFI könnte auch die Neuerstellung des Win Boot Manager Eintrags im NVRAM reichen. Wovon ich hier aber nicht ausgehe. Trotzdem wäre die Ausgabe von efibootmgr hier aufschlussreich. Und wenn die SuperGrub2 Disk hier scheitert, fehlen eben die entsprechenden Dateien oder sind nicht mehr da wo sie sein sollten und müssen neu erstellt werden.

daher habe ich die alten debian partitionen ........ geloescht,

Sollte da die ESP bei gewesen sein, wurde eine neue erstellt, der Win-Eintrag im EFI/NVRAM verweist aber noch auf die alte. Resultat, Windows kann nicht booten. Die Computerreparaturfunktion von Windows könnte das aber automatisiert wieder einrichten.

Wir wissen es nicht genau, was passiert ist, daher abwarten!

L.G.

 

[Knogle]

Hier der Output von Efibootmgr

Windows Reparatur konnte keine Fehler feststellen, und raet zu einem Neustart.

Folgende Idee habe ich.
Ich habe per Clonezilla ein Backup der Platte gemacht.
Ich wuerde die Platte komplett leer machen, neue Partionstabelle erstellen.
Dann wuerde ich Windows 10 drauf installieren.
Dann leere ich die WIndows 10 Partition komplett mit rm -r * , und kopiere den Inhalt der alten WIndows 10 Partition drauf.
Dann verkleinere ich die Partition mit Windows Bordmitteln, und kopiere die Ubuntu Partition auf den verbleibenden Teil mit GParted.
Dann repariere ich mit der chroot Methode den GRUB Bootloader.

Die ESP wurde nicht geloescht, es waren nur 2 SWAP Partitionen welche geloescht wurden.

BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0002,000E,0011,0012,0013,0006,000A,0007,0014,0001
Boot0001* UEFI: Built-in EFI Shell    VenMedia(5023b95c-db26-429b-a648-bd47664c8012)..BO
Boot0002* debian    HD(5,GPT,043c73f4-7db2-413c-afc3-c069b347da3a,0x11aab000,0x32000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0003* ubuntu    HD(5,GPT,043c73f4-7db2-413c-afc3-c069b347da3a,0x11aab000,0x32000)/File(\EFI\UBUNTU\SHIMX64.EFI)
Boot0006* Hard Drive    BBS(HD,,0x0)..GO..NO........{.P.M.9.6.1. .N.V.M.e. .S.A.M.S.U.N.G. .5.1.2.G.B....................A...........................%8.q..w.....>..Gd-.;.A..MQ..L. . . . . . .S.3.3.Y.N.B.0.J.4.0.4.7.1.8........BO
Boot0007* Network Card    BBS(Network,,0x0)..GO..NO........q.I.B.A. .G.E. .S.l.o.t. .1.F.0.0. .v.1.5.5.0.........................rN.D+..,.\...........B..Gd-.;.A..MQ..L.I.B.A. .G.E. .S.l.o.t. .1.F.0.0. .v.1.5.5.0........BO..NO..........M.L.N.X. .F.l.e.x.B.o.o.t. .3...3...4.0.0. .(.P.C.I. .2.9.:.0.0...0.).........................rN.D+..,.\)..........\..Gd-.;.A..MQ..L.M.L.N.X. .F.l.e.x.B.o.o.t. .3...3...4.0.0. .(.P.C.I. .2.9.:.0.0...0.)........BO
Boot000A* USB    BBS(USB,,0x0)..GO..NO........a.M.u.l.t.i. .F.l.a.s.h. .R.e.a.d.e.r. .1...0.0....................A................................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.6.6.4.7.1........BO..NO........e.I.n.t.e.n.s.o. .S.p.e.e.d. .L.i.n.e....................A.............................2..Gd-.;.A..MQ..L.1.7.0.9.1.1.0.0.0.1.2.5.2.3........BO..NO........a.S.T.5.0.0.L.T.0.1.2.-.1.D.G.1.4.2. .0.0.0.3....................A................................Gd-.;.A..MQ..L.2.0.1.1.0.9.2.0.1.2.D.1........BO
Boot000E* debian    HD(5,GPT,043c73f4-7db2-413c-afc3-c069b347da3a,0x11aab000,0x32000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO
Boot0011* Windows Boot Manager    HD(5,GPT,043c73f4-7db2-413c-afc3-c069b347da3a,0xe9800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO
Boot0012* ubuntu    HD(5,GPT,043c73f4-7db2-413c-afc3-c069b347da3a,0xe9800,0x32000)/File(\EFI\UBUNTU\SHIMX64.EFI)..BO
Boot0013* debian    HD(5,GPT,043c73f4-7db2-413c-afc3-c069b347da3a,0xe9800,0x32000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO
Boot0014* UEFI: Intenso Speed Line    PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x0)/USB(2,0)/CDROM(1,0x2fc,0x5600)..BO

Auch mal mit Gparted das NTFS Dateisystem gecheckt. Kam das hier raus.

Dateisystem (ntfs) auf /dev/nvme0n1p6 überprüfen und reparieren 00:00:02 ( ERFOLG )

/dev/nvme0n1p6 kalibrieren 00:00:01 ( ERFOLG ) Pfad: /dev/nvme0n1p6 (Partition) Anfang: 1161216 Ende: 504348671 Größe: 503187456 (239.94 GiB) Dateisystem auf /dev/nvme0n1p6 auf Fehler überprüfen und (falls möglich) diese beheben 00:00:00 ( ERFOLG ) ntfsresize -i -f -v '/dev/nvme0n1p6' 00:00:00 ( ERFOLG ) ntfsresize v2017.3.23 (libntfs-3g) Device name : /dev/nvme0n1p6 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 257631973888 bytes (257632 MB) Current device size: 257631977472 bytes (257632 MB) Checking for bad sectors ... Checking filesystem consistency ... 100.00 percent completed Accounting clusters ... Space in use : 139937 MB (54,3%) Collecting resizing constraints ... Estimating smallest shrunken size supported ... File feature Last used at By inode Multi-Record : 253939 MB 82974 $MFTMirr : 1 MB 1 Compressed : 157065 MB 99094 Sparse : 157082 MB 168713 Ordinary : 256741 MB 233116 You might resize at 139936145408 bytes or 139937 MB (freeing 117695 MB). Please make a test run using both the -n and -s options before real resizing! Dateisystem bis zum Auffüllen der Partition vergrößern 00:00:01 ( ERFOLG ) Simulation starten 00:00:01 ( ERFOLG ) ntfsresize --force --force --no-action '/dev/nvme0n1p6' 00:00:01 ( ERFOLG ) ntfsresize v2017.3.23 (libntfs-3g) Device name : /dev/nvme0n1p6 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 257631973888 bytes (257632 MB) Current device size: 257631977472 bytes (257632 MB) New volume size : 257631973888 bytes (257632 MB) Nothing to do: NTFS volume size is already OK. Echtes Vergrößern/Verkleinern 00:00:00 ( ERFOLG ) ntfsresize --force --force '/dev/nvme0n1p6' 00:00:00 ( ERFOLG ) ntfsresize v2017.3.23 (libntfs-3g) Device name : /dev/nvme0n1p6 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 257631973888 bytes (257632 MB) Current device size: 257631977472 bytes (257632 MB) New volume size : 257631973888 bytes (257632 MB) Nothing to do: NTFS volume size is already OK.

 

[HITCHER_I]

Sind da nicht zwei Einträge doppelt? Für was sind Boot0002* und Boot0003*, die gibt es ja auch unter 12 und 13?
Vielleicht sind da 2 davon verkehrt.

 

[Knogle]

So, ich habe Windows nun neu installiert.
Dabei habe ich alle Partitionen bis auf die Linux EXT 4 Partion entfernt.
Nun passt zumindest die Nummerierung wieder.
Nun will ich die neue Windows Partition durch die alte ersetzen.
Dabei probiere ich es erst indem ich den Inhalt jener komplett entferne, und den Inhalt der alten via Linux mit cp -R * kopiere auf die neue Partition.

 

[K-BV]

Hallo!

Die ESP wurde nicht geloescht

Ja, bestätigen auch die Ausgaben von efibootmgr. Der Windows Boot Manager und Grub greifen auf die gleiche UUID zu.

Boot0003* ubuntu HD(5,GPT,043c73f4-7db2-413c-afc3-c069b347da3a,0x11aab000,0x32000)/File(\EFI\UBUNTU\SHIMX64.EFI)

Boot0011* Windows Boot Manager HD(5,GPT,043c73f4-7db2-413c-afc3-c069b347da3a,0xe9800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO

Ansonsten stehen da haufenweise Einträge von früheren Installationen etc.. Kann man bei Gelegenheit mal löschen/aufräumen, sind aber imho irrelevant für das Windows-Problem.

Wenn du jetzt die ESP gelöscht hast, startet Linux natürlich nicht mehr.

L.G.

 

[Knogle]

Genau Linux ging wie erwartet dann nicht mehr.
Daher habe ich dann mit der chroot Methode den Bootloader gefixxt, und in fstab die UUID der ESP Partition angepasst.
Gerade bin ich am kopieren der Windows Daten auf die neue Partion, bin mal gespannt ob Windows das so mitmacht

 

[K-BV]

Das hier kennst du? Auf die EFI Partition achten!!

O.K.! Hat sich überschnitten! Du kennst es!

Ergänzung (3. März 2019)

bin mal gespannt ob Windows das so

Ich auch.....!? Hab aber die Befürchtung, dass die Schnittstelle ESP---->Systempartition Probleme machen wird.

 

[Knogle]

Gleich kommt der spannende Moment.
Nun nachdem das Kopieren abgeschlossen ist findet update-grub auch die Windows Installation wieder.

Sourcing file `/etc/default/grub'
GRUB-Konfigurationsdatei wird erstellt …
Hintergrund gefunden: /etc/default/background.jpg
Found background image: /etc/default/background.jpg
Linux-Abbild gefunden: /boot/vmlinuz-4.18.0-15-generic
initrd-Abbild gefunden: /boot/initrd.img-4.18.0-15-generic
Linux-Abbild gefunden: /boot/vmlinuz-4.18.0-10-generic
initrd-Abbild gefunden: /boot/initrd.img-4.18.0-10-generic
Windows Boot Manager auf /dev/nvme0n1p2@/EFI/Microsoft/Boot/bootmgfw.efi gefunden
Hinzufügen des Boot-Menü Eintrages für die EFI Firmware Konfiguration
erledigt

Ergänzung (3. März 2019)

Hahaha ich glaube es kaum, es geht!!!
Windows laeuft nun wieder prima, naja nicht ganz.
Ich habe keine Fonts mehr.
In Windows Explorer, und den Windows GUIs gibt es keinen Text mehr.
Weiss jemand wie man das Fixxt?
In der Systemsteuerung selbst habe ich noch Schrift, aber Taskmanager bspw. auch nicht.


Im Grunde habe ich jedoch folgende gemacht um Windows wieder zum laufen zu bringen.

1. NTFS Partition von Windows mit Clonezilla auf einer externen Platte gesichert.
2. Windows neu installiert, und alle Partitionen bis auf die Linux EXT 4 Partition geloescht.
3. GRUB Bootloader repariert, fstab von der EXT4 Partition angepasst.
4. Inhalt der neuen NTFS Partition vom neu installierten Windows geloescht.
5. Inhalt der alten NTFS Partition ruebergeschoben auf die neue, nun geleerte Partition.
6. update-grub ausgefuehrt, Bootloader wurde nun gefunden.
7. Windows gestartet, Automatische Reparatur ist angelaufen, und es startet.

 

[K-BV]

Super!

Nun nachdem das Kopieren abgeschlossen ist findet update-grub auch die Windows Installation wieder.

Daran habe ich nicht gezweifelt!

Windows gestartet, Automatische Reparatur ist angelaufen, und es startet.

Daran schon eher!

Würde dir empfehlen, einen separaten Thread für die neuen Probleme zu eröffnen, da es thematisch hier eh nicht passt und viele Windows-Helfer bei dem Linux/Windows/Boot Gemisch schon weiter vorne aufgehört haben zu lesen.

Es sei dir noch mal die weiter vorne verlinkte SuperGrub2Disk wärmstens empfohlen. Sollte man immer in der Schublade haben für den Notfall. Für alle Betriebssysteme. Wenn ich es nicht übersehen habe, hast du es hier nicht probiert. Gut möglich, dass dir das den ganzen Aufwasch erspart hätte, da man vom gestarteten Windows aus mehr Optionen gehabt hätte.

L.G.

 

[Knogle]

Mit SuperGrub2Disk habe ich es auch probiert, jedoch war das Ergebnis leider das gleiche wie bei einem direkten Start ueber den Boot Manager.
Aktuell bin ich gerade im laufenden Windows drinnen, halt nur ohne Text ausser im Firefox.

Folgende Schritte werde ich nun ausprobieren:

Partition direkt kopieren via Clonezilla oder GParted statt mit cp -i -R *
Denn ich habe festgestellt dass ich durch das rm -rf * leider die $Bitmap entfernt habe, und dadurch beim Start ein chkdsk Vorgang ausgeloest wurde bei dem viel korrigiert werden musste.

Dann werde ich nach dem Kopieren der ganzen Partition die GUID anpassen.

Vorher werde ich jedoch einfach mal ein sfc /scannow ausfuehren ueber den Windows 10 Stick.

Vielleicht hilft es ja irgendwem weiter.

Ergänzung (3. März 2019)

Hier das chkdsk log.
Scheinen wohl die Fonts betroffen zu sein.

Dateisystem auf C: wird überprüft.

Phase 1: Die Basisdatei-Systemstruktur wird untersucht...
Die zugeordnete Länge 0x360f000 ist kein Mehrfaches von 0x10000 für das Attribut
vom Typ 0x80 und der Instanzkennung 0x2.
Die zugeordnete Länge 0x618000 ist kein Mehrfaches von 0x10000 für das Attribut
vom Typ 0x80 und der Instanzkennung 0x2.
Die zugeordnete Länge 0x10b000 ist kein Mehrfaches von 0x10000 für das Attribut
vom Typ 0x80 und der Instanzkennung 0x2.
Die zugeordnete Länge 0x39000 ist kein Mehrfaches von 0x10000 für das Attribut
vom Typ 0x80 und der Instanzkennung 0x2.
Die zugeordnete Länge 0x7a000 ist kein Mehrfaches von 0x10000 für das Attribut
vom Typ 0x80 und der Instanzkennung 0x2.
Die zugeordnete Länge 0x7b4e000 ist kein Mehrfaches von 0x10000 für das Attribut
vom Typ 0x80 und der Instanzkennung 0x2.
Die zugeordnete Länge 0x2766000 ist kein Mehrfaches von 0x10000 für das Attribut
vom Typ 0x80 und der Instanzkennung 0x2.
Die zugeordnete Länge 0x1229000 ist kein Mehrfaches von 0x10000 für das Attribut
vom Typ 0x80 und der Instanzkennung 0x2.
Die zugeordnete Länge 0x229000 ist kein Mehrfaches von 0x10000 für das Attribut
vom Typ 0x80 und der Instanzkennung 0x2.
                                                                                      
  385814 Datensätze verarbeitet.                                                         


Dateiüberprüfung beendet.
                                                                                      
  236 große Datensätze verarbeitet.                                   


                                                                                      
  0 ungültige Datensätze verarbeitet.                               



Phase 2: Die Dateinamenverknüpfung wird untersucht...
Das erste freie Byte 0x28 und die zur Verfügung
stehenden Bytes 0x88 für den Stammindex $O
in der Datei 0x19 sind nicht identisch.
                                                                                      
  8 Analysedatensätze verarbeitet.                                 


Das erste freie Byte 0x28 und die zur Verfügung
stehenden Bytes 0x100 für den Stammindex $I30
in der Datei 0xb1 sind nicht identisch.
Das erste freie Byte 0x28 und die zur Verfügung
stehenden Bytes 0xa0 für den Stammindex $I30
in der Datei 0x1f9 sind nicht identisch.
Das Dateinamenattribut des Indexeintrags FontCache-FontSet-S-1-5-18.dat von Index $I30,
der 0x13a7c untergeordnet ist, kann in der Datei 0x1488d nicht
gefunden werden.
Indexeintrag FontCache-FontSet-S-1-5-18.dat in Index $I30 der Datei 13A7C wird gelöscht.
Das Dateinamenattribut des Indexeintrags FontCache-S-1-5-18.dat von Index $I30,
der 0x13a7c untergeordnet ist, kann in der Datei 0x1488c nicht
gefunden werden.
Indexeintrag FontCache-S-1-5-18.dat in Index $I30 der Datei 13A7C wird gelöscht.
Das Dateinamenattribut des Indexeintrags FONTCA~1.DAT von Index $I30,
der 0x13a7c untergeordnet ist, kann in der Datei 0x1488d nicht
gefunden werden.
Indexeintrag FONTCA~1.DAT in Index $I30 der Datei 13A7C wird gelöscht.
Das Dateinamenattribut des Indexeintrags FONTCA~4.DAT von Index $I30,
der 0x13a7c untergeordnet ist, kann in der Datei 0x1488c nicht
gefunden werden.
Indexeintrag FONTCA~4.DAT in Index $I30 der Datei 13A7C wird gelöscht.
Das erste freie Byte 0x28 und die zur Verfügung
stehenden Bytes 0x90 für den Stammindex $I30
in der Datei 0x14271 sind nicht identisch.
Die Indexbitmap $I30 in der Datei 0x527d4 ist nicht korrekt.
Fehler im Index $I30 der Datei 527D4 werden berichtigt.
                                                                                      
  508518 Indexeinträge verarbeitet.                                                     


Indexüberprüfung beendet.
CHKDSK überprüft nicht indizierte Dateien, um die Verbindung mit dem ursprünglichen Verzeichnis wiederherzustellen.
Verwaiste Datei ~FONTC~2.DAT (1488C) wird in Verzeichnisdatei 13A7C wiederhergestellt.
Verwaiste Datei ~FontCache-S-1-5-18.dat (1488C) wird in Verzeichnisdatei 13A7C wiederhergestellt.
                                                                                      


Verwaiste Datei ~FONTC~3.DAT (1488D) wird in Verzeichnisdatei 13A7C wiederhergestellt.
Verwaiste Datei ~FontCache-FontSet-S-1-5-18.dat (1488D) wird in Verzeichnisdatei 13A7C wiederhergestellt.
  2 nicht indizierte Dateien im ursprünglichen Verz. wiederhergestellt.
                                                                                      


                                                                                      
  8 Analysedatensätze verarbeitet.                                 



Phase 3: Sicherheitsbeschreibungen werden untersucht...
1894 nicht verwendete Indexeinträge aus Index $SII der Datei 0x9 werden aufgeräumt.
1894 nicht verwendete Indexeinträge aus Index $SDH der Datei 0x9 werden aufgeräumt.
1894 nicht verwendete Sicherheitsbeschreibungen werden aufgeräumt.
Überprüfung der Sicherheitsbeschreibungen beendet.
                                                                                      
  61353 Datendateien verarbeitet.                                       


CHKDSK überprüft USN-Journal...
Die Überprüfung von USN-Journal ist abgeschlossen.
CHKDSK hat freien Speicher gefunden, der in der Volumebitmap als
zugeordnet gekennzeichnet ist.

Es wurden Korrekturen am Dateisystem vorgenommen.
Es sind keine weiteren Aktionen erforderlich.

 251543551 KB Speicherplatz auf dem Datenträger insgesamt
 142992120 KB in 324173 Dateien
    114720 KB in 61354 Indizes
    465331 KB vom System benutzt
     65536 KB von der Protokolldatei belegt
 107971380 KB auf dem Datenträger verfügbar

      4096 Bytes in jeder Zuordnungseinheit
  62885887 Zuordnungseinheiten auf dem Datenträger insgesamt
  26992845 Zuordnungseinheiten auf dem Datenträger verfügbar
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00

Ergänzung (3. März 2019)

Font Problem behoben!!!! Dank dieses Beitrages hier

https://www.tenforums.com/general-s...0-a-4.html?s=18fda2d6e69887e1c6bd04c517c63cf8


Alles laeuft nun wie vorher!

Sorry for resurrecting an old thread.

I came across this issue and thought i'd post the fix that worked. All text disappeared on some Wimdows 10 machines after copying some old group policies into the Win10 container. Turns out some of the policies had overwritten the permissions to multiple folders within C:, in particular it had removed "All Application packages" and "All Restricted App Packages" from the "c:\windows\fonts" folder.
We fixed it by using psexec from another machine, to run the command "ICACLS.exe c:\Windows\Fonts /T /Q /C /RESET" to reset the permissions (and then ran "ICACLS c:\Windows /T /Q /C /RESET" when we found some other permissions were affecting other apps).

 

[Knogle]

Habe das ganze nochmal ausprobiert.
Letztendlich kann man Windows neuinstallieren, und die neue NTFS Partition mit der alten einfach ersetzen.
Ob die GUID stimmt oder nicht ist egal, weil die Windows Reparatur erledigt das von alleine.
So kann man sich den riesen Aufwand sparen den Bootloader irgendwie zu fixen.

Habe das erneut machen muessen, da ich die Berechtigungen durch diesen icacl Befehl gesetzt habe wobei die Schriften dann gingen, jedoch ging Internetverbindung dann nicht mehr als auch Startmenu und andere Dinge.