Win10-64: Merkwürdiges Boot-Problem

[MarkF]

Hallole,
ich habe hier ein merkwürdiges Boot-Problem mit Win10-64, bei dem ich allein nicht weiter komme:
Auf der (traditionell mit MBR eingerichteten, kein UEFI) HD sind 4 aktive Partitionen, Win10-64, Win10-32, Win7-64 und Win7-32. Das BOOT-Verzeichnis, -Manager und BOOT-Daten habe ich auf die erste Partition - Win10-64 - verpflanzt. Das war schon vor zwei oder drei Jahren. Ein Boot-Manager mit BCD-Edit ist installiert und wie bei vielen anderen ähnlich eingericheten HD lief alles problemlos und ich konnte mit jedem BS booten.
Die HD lag für längere Zeit im Schrank, sie war für einen bestimmten Zweck so eingerichtet, und jetzt mußte ich sie wieder aktivieren. Beim Weglegen war noch alles o.k.
Von drei Partitionen läßt sich problemlos booten, nur nicht von der ersten Partition mit Win10-64. Es erscheint das Windows-Fenster und der drehende Kreis, dann verschwindet das Fenster und der Kreis bleibt - und das war´s. An sich müßte jetzt die Meldung kommen, daß man auf den Lokalen Sitzungsmanager warten müsse, aber es tut sich nichts. Auch nach Stunden ...
Das ist jetzt ja noch nicht so besonders - regelmäßig hilft, von einem Installations-Stick zu booten, die Reparaturoptionen auszuwählen, die Software werkeln zu lassen und dann klappt es mit dem Booten wieder. Meist muß ich danach den Boot-Manager neu einrichten, aber dafür habe ich entsprechend Backups der Konfiguration.
Die Reparaturoption kann das Problem aber nicht beheben. Nach gefühlt Stunden erscheint eine entsprechende Meldung.
Von einem alternativen Neuschreiben des MBR und den anderen auf Kommandozeilenebene einzugebenden manuellen Befehlen

• bootrec /fixmbr (schreibt mbr aber überschreibt keine Partitionstabelle)
• bootrec /fixboot (schreibt neuen Bootsektor auf die Systempartition)
• bootrec /scanos (scannt nach anderen Betriebssystemen, die zu bcd hingefügt werden)
• bootrec /rebuildbcd scannt nach einem installierten Betriebssystem und fügt diese dann in das Bootmenü hinzu)

habe ich abgesehen, weil ja MBR und Bootmanager usw. offensichlich nicht defekt sind - PartitionMagic meldet, daß diese erste Partition aktiv und die Systempartition ist und da der Bootmanager ja auch funktioniert muß damit alles o.k. sein. Daher sehe ich auch in

• bootsect /nt60 ALL /Force /MBR
• bcdboot c:\Windows /l de-de /s Z: /f BIOS - c: = Startpartition, muss eventuell angepasst werden.

keinen rechten Sinn.
Vom Explorer aus - gebootet mit einem der anderen BS/Partitionen - kann ich auf diese Partition nicht zugreifen ("Auf E: kann nicht zugegriffen werden - Zugriff verweigert"). Sie erscheint zwar in der Übersicht, ihr/der Win10-Installation wird auch ein Lw-Buchstabe zugewiesen, aber anstelle der Anzeige der Größe und des noch vorhandenen Platzes wird nur "NTFS" angezeigt.
Aber: In der Datenträgerverwaltung wird die Partition/das Lw als fehlerfrei angezeigt, auch die Größe und freier Platz, alle Anzeigen wie sie sein sollten. Eine Datenträgerüberprüfung sowie chkdsk sind möglich und erbringen keine Fehler. Dito für Laufwerksscan.
Und mehr noch: Mit PartitionMagic (Doppelklick bzw. Durchsuchen) kann ich "normal" auf die Partition zugreifen. D.h. es wird die Verzeichnisstruktur angezeigt, sie läßt sich durcklicken. "Dateisystem überprüfen" erbringt auch keine Fehler.
Und weiter: Boote ich mit dem Win10-64-Installationsstick und wechsele ich auf Kommandozeilenebene, kann ich auf diese Weise "normal" auf die Partition zugreifen. Ebenso beim Booten im abgesicherten Modus von eine der anderen drei Partitionen. Das funktioniert aber NICHT nach dem normalen Booten von einer der anderen Partition, dann wird auf Kommadozeilenebene (wie beim Explorer) "Zugriff verweigert" gemeldet.
Nicht weiter überraschend ist auch, daß auch im abgesicherten Modus nicht gebootet werden kann.
"Partition bereinigen" in PartitionMagic habe ich nicht ausprobiert, da ich nicht weiß, was diese Funktion genau macht. Das gleiche für die Funktion "Daten wiederherstellen" - der Scan läuft durch und es wird die Verzeichnisstruktur und Dateien dargestellt/angezeigt, wie sie sein sollten, aber da ich diese Funktion noch nie genutzt habe weiß ich, was dann passiert.
Also, ich bin mit meinem nicht ganz kleinen Latein am Ende. Nach meinen Erfahrungen passen die Symptome nicht zusammen. An Windows selbst kann es nicht liegen, weil dann zumindest auf die Partition/Lw zugegriffen werden könnte. Das Dateisystem ist anscheinend o.k. Auch MBR usw. müssen o.k. sein, da andernfalls auch nicht von den anderen drei Partitionen gebootet werden könnte. Ich begreife es nicht, sehe nicht, wo das Problem liegen kann.
Daher meine Frage: Habt ihr eine Diagnose, eine Idee, wie ich sicher wieder von dieser Partition booten kann (ohne das BS neu zu installieren, denn zum einen ist das und "meine" Einstellungen viel Arbeit, zum anderen sind dort reichlich Daten drauf, die ich ungern verlieren möchte).

 

[Wolf.J]

Hallo @MarkF
Ich habe den Thread jetzt dreimal gelesen, ohne dass mir ein Grund für das Problem einfallen würde.
Allerdings ist MBR so lange her, ich habe im Moment nur Systeme mit UEFI und GPT zur Verfügung.
Zur Klarstellung, der Rechner (welcher genau) hat noch kein UEFI-BIOS?
Ich könnte mir vorstellen, dass diverse Abfragen mit Diskpart am wahrscheinlichsten Aufschluss geben könnten.
Besonders interessiert mich die systemreservierte Partition.
Bei Multi-Boot ist sicher für alle 4 BS der Schnellstart unter Windows deaktiviert?

Mich wundert auch, dass auf die Partition mit Win 10 64bit nicht zugegriffen werden kann, das ist ebenfalls nicht normal.

Beitrag automatisch zusammengeführt: 19.11.2022

Ebenfalls hilfreich könnte sein, wenn man sich der Inhalt der Systempartition ansehen kann.
Wenn Du Diskpart startest und mit
List vol
die entsprechenden Nummer des Volumes anzeigen lässt, kann man dem einen Laufwerksbuchstaben verpassen.
sel vol #nummer
assign Letter=z (oder ein anderer freier Buchstabe)
Danach kannst Du per cmd von einer funktionierenden Installation auf das Laufwerk zugreifen und den Inhalt anzeigen lassen.
Rückgängig machen wieder mit sel vol und remove letter=z.
Damit machst Du nichts kaputt.

 

[IT-SK]

Hallo Mark,
nur zum besseren Verständnis,
wurden alle Vier aktiven BS auf dieser Hardware (PC) installiert
und falls nicht, wie angelegt?

Ist auf dem BS wo kein Zugriff erfolgen kann,
was anderes als der Defender installiert?

MBR System habe ich Zuhause noch einen Oldie,
werfe ich später mal an.

 

[runit]

Auf der (traditionell mit MBR eingerichteten, kein UEFI) HD sind 4 aktive Partitionen, Win10-64, Win10-32, Win7-64 und Win7-32. Das BOOT-Verzeichnis, -Manager und BOOT-Daten habe ich auf die erste Partition - Win10-64 - verpflanzt.

Das kann meines Wissens nicht funktionieren, da Win 10 64 bit auch als MBR-Installation mehr als eine Partition hat. Das hat Win mal im Laufe der vergangenen Jahre dahingehend geändert. Es kann sein, dass sich Win daher an Deiner Konfiguration "verschluckt". So wirst Du in Summe meiner Vermutung nach mehr als 4 Partitionen auf der Platte haben, was wiederum vom Bios nicht verwaltet werden kann. Ein Datenträgerabbild zu sehen wäre natürlich hilfreich.

 

[Wolf.J]

Unter anderem deswegen wollte ich Informationen aus Diskpart.
In einer erweiterten Partition lassen sich mehrere logische Partitionen anlegen, so dass mehr als 4 möglich sind.

 

[MarkF]

Hallo @MarkF
Zur Klarstellung, der Rechner (welcher genau) hat noch kein UEFI-BIOS?

Nein, kein UEFI, und darüber bin ich auch recht froh. Das ist ein älterer HP dc7900.

Ich könnte mir vorstellen, dass diverse Abfragen mit Diskpart am wahrscheinlichsten Aufschluss geben könnten.

Was soll ich tun?

Besonders interessiert mich die systemreservierte Partition.

Es gibt keine systemreservierte Partition mehr. Dann könnte ich ja nicht von vier Win-BS/Partitionen booten. Wie gesagt habe ich dies alles in die erste Partition, von der aktuell nicht mehr gebootet werden kann, verlagert. Beschrieben wurde dies u.a. in
Den Bootmanager bei MBR Installationen auf das Systemlaufwerk verlegen
Den Bootmanager auf das Systemlaufwerk verlegen???
Bootmgr einfach auf andere Festplatte verschieben?

Und nein, das ist nicht das Problem. Das habe ich bei vielen HD so gemacht und auch bei dieser hier hat das ja problemlos funktioniert, bis ich aktuell die HD wieder reaktiviert habe.

Anliegend mal Screenshots von diskmgr und der Datenträgerverwaltung und Explorer.

Bei Multi-Boot ist sicher für alle 4 BS der Schnellstart unter Windows deaktiviert?

Yep.

Mich wundert auch, dass auf die Partition mit Win 10 64bit nicht zugegriffen werden kann, das ist ebenfalls nicht normal.

Beitrag automatisch zusammengeführt: 19.11.2022

Ebenfalls hilfreich könnte sein, wenn man sich der Inhalt der Systempartition ansehen kann.

Kann ich doch - wie beschrieben mit PartitionMagic und auf Kommandozeilenebene und wenn ich mit einem der anderen drei BS im abgesicherten Modus boote auf Kommandozeilenebene.
Korrektur: Plötzlich geht es auch nach dem "normalen" Booten auf Kommandozeilenebene. Merkwürdig!

Wenn Du Diskpart startest und mit
List vol
die entsprechenden Nummer des Volumes anzeigen lässt, kann man dem einen Laufwerksbuchstaben verpassen.
sel vol #nummer
assign Letter=z (oder ein anderer freier Buchstabe)
Danach kannst Du per cmd von einer funktionierenden Installation auf das Laufwerk zugreifen und den Inhalt anzeigen lassen.

Eigentlich ist es nicht erforderlich, weil der Partition ja bereits ein Lw-Buchstabe zugewiesen wird (siehe die Bilder oben), aber wenn ich es tue (ich habe getan) und dann wieder E: zuweisen, dann kann ich auch normal gebootet auf Kommandozeilenebene darauf zugreifen. Das sieht dann so aus:

Rückgängig machen wieder mit sel vol und remove letter=z.
Damit machst Du nichts kaputt.

o.k. Getan und wieder rückgängig gemacht.

Hallo Mark,
nur zum besseren Verständnis,
wurden alle Vier aktiven BS auf dieser Hardware (PC) installiert
und falls nicht, wie angelegt?

Och, ich weiß heute nicht mehr, wie ich diese konkrete HD in dieser Konfiguration "erzeugt" habe, ob durch Kopieren einer anderen HD oder Kopieren vorhandener Partitionen von anderen HD oder gar durch manuelle Neuinstallation. Das war vor 2 Jahren ... Auf jeden Fall hat bis zum Weglegen der HD alles funktioniert, wie es sollte.

Ist auf dem BS wo kein Zugriff erfolgen kann,
was anderes als der Defender installiert?

Nein. Mit Win10 verwende ich nur den Defender.

Das kann meines Wissens nicht funktionieren, da Win 10 64 bit auch als MBR-Installation mehr als eine Partition hat. Das hat Win mal im Laufe der vergangenen Jahre dahingehend geändert. Es kann sein, dass sich Win daher an Deiner Konfiguration "verschluckt". So wirst Du in Summe meiner Vermutung nach mehr als 4 Partitionen auf der Platte haben, was wiederum vom Bios nicht verwaltet werden kann. Ein Datenträgerabbild zu sehen wäre natürlich hilfreich.

Du irrst. Siehe meine erste Antwort nebst Links und Bildern. 4 aktive und bootende Win-Installationen/Partitionen sind jedenfalls mit Win7 und Win10 (Win8 und Vista hatte ich nie) möglich und kein Problem. Funktioniert auf vielen anderer meiner HD und hat auch hier bis zu deren Weglegen funktioniert (derzeit benutze ich das Win10-64 der zweiten Partition). Der einzige Nachteil, wenn man so will, ist halt, daß bei speziellen Problemen mit der Partition, auf die man den Bootmanager gelegt hat (also solchen, die das Booten betreffen), der Bootmanager nicht mehr geht, und man diese Partition so bestehen lassen muß bzw. System/Booten andernfalls auf eine andere Partition umwsitchen muß.

Wie gesagt: Ich könnte verstehen, wenn von der HD überhaupt nicht mehr gebootet werden kann, ich könnte auch verstehen, wenn mit dieser Partition oder der gesamten HD überhaupt nichts mehr anzufangen wäre, auch wenn nur Win auf der ersten Partition nicht startet aber die Partition "normal" zugänglich wäre, aber daß der Bootmanager geht und Win die ersten paar Sekunden bootet aber der Explorer nicht auf diese Partition zugreifen kann, andere Software dagegen schon, ist mir schlechterdings nicht begreiflich.

 

[Wolf.J]

Ok, offensichtlich hat dreimaliges Lesen nicht ausgereicht.
Ich hatte wirklich nicht realisiert, dass Du den Bootmanager tatsächlich in einer der Windows-Partitionen integriert hast.
Ich habe dazu noch einmal Deinen Post dazu hier gelesen.
So gesehen war die Idee mit dem Laufwerksbuchstaben natürlich überflüssig.
Die Beschäftigung mit MBR ist auch schon so weit weg, bei GPT sind solche Kunstgriffe ja unnötig und würden auch nicht funktionieren.
Eine Erklärung für das seltsame Verhalten habe ich immer noch nicht, die BCD-Konfiguration würde mich aber interessieren.

 

[MarkF]

Ok, offensichtlich hat dreimaliges Lesen nicht ausgereicht.
Ich hatte wirklich nicht realisiert, dass Du den Bootmanager tatsächlich in einer der Windows-Partitionen integriert hast.

Was hier aber irrelevant ist - würde ich die Partitionen 2 bis 4 löschen wäre das Problem mit der ersten Partition unverändert. Denn nicht das Integrieren der Systemdaten in die erste Partition ist das Problem - wäre es so, dann würde es bei keiner anderen HD gehen und hätte auch hier nie funktioniert.

Ich habe dazu noch einmal Deinen Post dazu hier gelesen.
So gesehen war die Idee mit dem Laufwerksbuchstaben natürlich überflüssig.

Macht nichts. Versuch macht kluch ... Da ich mit diskpart kaum etwas gemacht habe und kaum Erfarung habe, hae ich so wieder etwas hinzugelernt (was ich in einem Jahr aber natürlich wieder vergessen haben werde).

Die Beschäftigung mit MBR ist auch schon so weit weg, bei GPT sind solche Kunstgriffe ja unnötig und würden auch nicht funktionieren.
Eine Erklärung für das seltsame Verhalten habe ich immer noch nicht,

Das hat aber mit GPT oder MBR doch nichts zu tun. Daß Win nicht ordentlich bootet ist doch nur die Folge der merkwürdigen Symptomatik, daß Datenträgerverwaltung, Kommandozeile, PartitionMagic usw. auf die Partition zugreifen können, das laufende "normale" Windows/Explorer aber nicht.

die BCD-Konfiguration würde mich aber interessieren.

Du meinst die Eintragungen im Bootloader wie aus EasyBCD kopiert?:

Oder welche anderen Daten möchtest Du gerne sehen?

 

[Wolf.J]

Das hat aber mit GPT oder MBR doch nichts zu tun.

Ja und nein, da GPT anders organisiert ist, hast Du da immer eine separate Partitionen mit dem Bootmanager.
Welche der Partitionen aus der BCD-Konfiguration ist das betroffene Windows 10? Eintrag 3?
Hast Du Winload.exe gepatched (Winlodp.exe)?
Was mir negativ aufgefallen ist, #3 und #4 haben die identische BCD-ID.
Das ist meiner Meinung nach der wahrscheinlichste Grund für die Bootprobleme.
Die ID muss meines Wissens eindeutig sein.
Diesen Effekt kenne ich bisher nur von geklonten Platten, die dann auch eine gemeinsame BCD-ID haben und deshalb nicht booten oder sonstwie richtig erkannt werden.

 

[MarkF]

Ja und nein, da GPT anders organisiert ist, hast Du da immer eine separate Partitionen mit dem Bootmanager.

Was aber mit diesem Problem hier nichts zu tun hat. Wie gesagt: Bis zum Weglegen der HD hat alles für längere Zeit einwandfrei funktioniert und tut es auch bei anderen, ähnlich eingerichteten HD (z.B. der, von der ich gerade gebotet habe - ich mache nämlich gerade ein backup von der betroffenen HD um bei Experimenten keinen Datenverlust zu riskieren).

Welche der Partitionen aus der BCD-Konfiguration ist das betroffene Windows 10? Eintrag 3?

Nein. Das wäre zu schön, nicht? Es ist wie gesagt die erste Partition, der hier auch der erste Eintrag ist.

Hast Du Winload.exe gepatched (Winlodp.exe)?

Ja, der 4GB-Patch für Win7 und Win10, um auch in 32Bit mehr als knapp 4GB nutzen zu können (ich habe einige externe Hardware, für die es keine 64Bit-Treiber gibt und die trotz aller Versuche und Tricks eben nur mit 32Bit-BS laufen.

Was mir negativ aufgefallen ist, #3 und #4 haben die identische BCD-ID.

Ist mir noch nicht aufgefallen und sollte natürlich nicht sein. Wenn ich Zeit habe werde ich herausfinden, wie ich das korrigieren kann - das muß dann ja bei jedem der vielen Partitions-Clone-Vorgänge der Vergangenheit der Fall gewesen und das habe ich anscheinend immer irgendwie korrigiert - nur habe ich mittlerweile leider vergessen, wie das geht, ich habe zuletzt vor über einen Jahr eine Partition/HD geclont und solche Details vergessen ich leider schnell.

Das ist meiner Meinung nach der wahrscheinlichste Grund für die Bootprobleme.

Das hat mit dem Problem aber nichts zu tun, da die erste Partition und der erste Eintrag betroffen ist - und dieser Zustand von Anfang an so war und bis jetzt zu keinem Problem geführt hat.
Die gleiche ID kann lediglich bewirken, daß

Die ID muss meines Wissens eindeutig sein.
Diesen Effekt kenne ich bisher nur von geklonten Platten, die dann auch eine gemeinsame BCD-ID haben und deshalb nicht booten oder sonstwie richtig erkannt werden.

Stimmt schon, aber mit diesem Problem hier hat das wie gesagt nichts zu tun.

Übrigens: Auch Macrium Reflect und Partition Magic können zum Clonen bzw. Datenkopieren bislang problemlos auf diese erste Partition zugreifen. Behoben - durch das Clonen - ist das Problem aber leider nicht, mit der ersten Partition is Macrium fertig und der Explorer meldet, daß nach (automatischer) Vergabe eines Lw-Buchstabens darauf nicht zugegriffen werden kann (wie auf die originale Partition). Naja, eine 1:1-Kopie ist ja auch der Sinn des Clonens .... ;-/

 

[Wolf.J]

Du schreibst ja

regelmäßig hilft, von einem Installations-Stick zu booten, die Reparaturoptionen auszuwählen, die Software werkeln zu lassen und dann klappt es mit dem Booten wieder.

Das könnte ich ja noch irgendwo nachvollziehen, aber wenn danach der Bootmanager repariert werden muss, könnte es sein, dass hier Bereiche überschrieben werden.
Der erste Sektor bzw. 512 Byte der Festplatte werden ja vom MBR belegt.
Danach folgen die 4 Partitionen.
Der Bootmanager selbst befindet sich auf der ersten Partition und die will nicht booten.
Wenn alle anderen Faktoren ausgeschlossen werden können, bleibt ja nur noch die Vermutung, dass hier Konflikte auftreten, und zwar auf der Festplatte in den ersten Sektoren.

Meist muß ich danach den Boot-Manager neu einrichten, aber dafür habe ich entsprechend Backups der Konfiguration.

Und damit überschreibst Du dann die vorherige Reparatur?

Was da allerdings wirklich Sache ist, kann man nur mit einem Low-Level-Editor auf Sektorenebene sehen.
Die kosten allerdings auch.

 

[MarkF]

Du schreibst ja

Das könnte ich ja noch irgendwo nachvollziehen, aber wenn danach der Bootmanager repariert werden muss, könnte es sein, dass hier Bereiche überschrieben werden.
Der erste Sektor bzw. 512 Byte der Festplatte werden ja vom MBR belegt.
Danach folgen die 4 Partitionen.
Der Bootmanager selbst befindet sich auf der ersten Partition und die will nicht booten.

Der Bootmanager funktioniert aber. Und daß sie nicht booten will ist so nicht richtig. Win startet ja zunächst, rödelt aber nach dem Verschwinden des Windows-Fensters auf Dauer mit dem Kreis-Symbol herum - siehe meine Beschreibung. Und die Partitionsdaten können mit EasyBCD, VisualBCD usw. gelesen werden und auch PartitionMagic, Macrium Reflect, Datenträgerverwaltung usw. können einwandfrei auf die Partition zugreifen. Das wäre nicht möglich, wenn die Partition irgendwie defekt wäre.

Wenn alle anderen Faktoren ausgeschlossen werden können, bleibt ja nur noch die Vermutung, dass hier Konflikte auftreten, und zwar auf der Festplatte in den ersten Sektoren.

Ich tappe im Dunkeln, ich weiß nicht, was ich insgesamt ausschließen kann. Jedenfalls liegt es nicht an den vier aktiven Partition, den 4 BS und der identischen ID der beiden letzten Partitionen, das dies unverändert ist.

Und damit überschreibst Du dann die vorherige Reparatur?

Was Du zitiert habe ich anfänglich zur Fehlerbeschreibung geschrieben, im Zusammenhang mit den Reparaturoptionen des Installations-Sticks, die hier aber nichts gefruchtet haben, anscheinend überhaut nichts getan haben. Das gleich gilt auch für die alternativen manuellen Befehle, die halt auch den EasyBCD-Bootmanager überschreiben.
Oder worauf willst Du hinaus?

Was da allerdings wirklich Sache ist, kann man nur mit einem Low-Level-Editor auf Sektorenebene sehen.
Die kosten allerdings auch.

Früher gab es dazu PCTools. Naja, lang ist´s her ...

Aber es geht weiter, neue Informationen:
Bin eben darüber gestolpert, daß z.B. VisualBCD das BCD-File aus dem Boot-Verzeichnis der betreffenden Partition laden konnte. Genauer gesagt: Beim Auswählen des BCD-Files konnte ich mit dem Dateiauswahl-Fenster die gesamte Partition/Laufwerk lesen. Sehr merkwürdig (PartitionMagic konnte das zwar auch, aber da habe ich mir nichts weiter dabei gedacht).
Da der Explorer das aber nicht zuläßt habe ich mal den TotalCommander ausprobiert. Der weigert sich auch, bietet aber die Option, es mit Admin-Rechten zu probieren. Und siehe da, damit läßt sich die Partition/das Lw normal lesen!
Das hat mich daran erinnert, daß der Explorer nie mit Admin-Rechten startet/läuft (man kann es auch nicht erzwingen) und wenn man ohne weitere Tricks (z.B. PowerRun) mit Admin-Rechten an den Dateien herummachen möchte, man den Editor mit Admin-Rechten starten und das Dateiauswahlfenster dazu, als Explorer-Ersatz, mißbrauchen soll.
Flugs getestet und siehe da - normal gestartet weigert sich der Editor, von der Partition/Lw zu lesen und zeigt in der Laufwerksübersicht wie der Explorer nicht die Partitions-/Lw-Daten an sondern nur "NTFS". Dann mit Admin-Rechten gestartet und - wupps - alles o.k.: Jeder Zugriff ist möglich und die Partition/Lw wird in der Übersicht normal mit allen Daten angezeigt.
Das sieht mir ganz danach aus, als ob es sich nicht um ein eigentliches/spezifisches Partitions- sondern irgendwie um eine "Rechte"-Problem handeln würde. Vielleicht erfordert, warum auch immer, der Zugriff auf die Partition (die Dateien) Admin-Rechte und Windows hat diese beim Booten nicht? Da bin ich aber völlig am Schwimmen, mit der Rechteverwaltung kenne ich mich überhaupt nicht aus, das ist für mich ein unverständliches und ständiges Ärgernis, und noch viel weniger kann ich mir vorstellen, warum Windows deswegen nicht auf die (eigene) HD/Partition zugreifen können sollte.
Das BS ist übrigens Win7-64 Pro (auch das, mit dem ich gerade arbeite).

 

[Wolf.J]

Oder worauf willst Du hinaus?

Ich will ganz konkret darauf hinaus, dass dieser Installation ein paar Byte abhanden gekommen sein könnten.
Also eine Beschädigung in einem der ersten Sektoren.
Das ist zwar nur eine Vermutung, aber die Symptome müssen ja eine Ursache haben, ebenso die Tatsache, dass dieses BS nicht vollständig starten kann.
Das kann die MFT (Master File Tablet) des NTFS sein. Das würde dazu führen, dass bestimmte Dateien nicht mehr gefunden werden, Berechtigungen für die einzelnen Dateien werden da auch gespeichert.
Du sprichst die Rechteverwaltung an, die dürfte bei Start des BS noch nicht zum Tragen kommen, da das ja alles noch vor dem Anmelden des Users passiert.
Zugegebenermaßen ist das alles im Nebel gestochert, aber wirkliche Anhaltspunkte gibt es ja nicht.
Ich würde halt auch gerne verstehen, was da schief gelaufen ist.
Bis zu einer Reparatur durch Inplace Upgrade wirst Du ja gar nicht erst kommen?
Das funktioniert nur aus einem laufenden Windows heraus.

 

[MarkF]

Sorry, war beruflich zu beschäftigt.
Also, wenn Deine Gedanken/Ideen zutreffend wären, dann dürfte es doch nicht möglich sein, daß von den anderen BS heraus mit Admin-Rechten auf alle Dateien zugegriffen werden kann. Denn wenn mit Admin-Rechten zugegriffen werden kann und das LW in der Datei-/LW-Übersicht normal angezeigt wird (wie auch z.B. in der Datenträgerverwaltung und allen anderen LW-bezogenen Programmen, de Admin-Rechte haben), ohne Admin-Rechte aber nicht und nicht einmal das LW richtig angezeigt wird, dann kann dies doch nur daran liegen, daß die Berechtigungen/Rechte "irgendwie" falsch gesetzt sind. Wären Tabellen völlig defekt, dann könnte man doch auch mit Admin-Rechten nicht zugreifen ....
Ob und wann die Rechteverwaltung beim BS-Start greift weiß ich nicht. Anfänglich, die ersten Sekunden, bootet Win10 ja auch. Es geht erst dann nicht weiter, wenn der lokale Sitzungsmanager geladen werden soll ... und der hat doch etwas mit der Rechteverwaltung zu tun, nicht? Hinzu kommt, daß mein normaler user-account bei allen BS/Installationen (natürlich) zur Gruppe der Admins zählt, also "irgendwie" Admin-Rechte hat (wenn auch anscheinend nicht so viel wie der "echte" Administrator).
Das alles führt mich zu der Vermutung, daß wenigstens das Booten erfolgen sollte, wenn es nicht mit meinem normalen user-account (und dessen "eingeschränkten" Admin-Rechten) erfolgt, sondern als "richtiger" Admin gebootet wird, so saß auch wenn der lokale Sitzungsmanager geladen werden soll das BS unbeschränkt auf alle Dateien zugreifen kann. Geht das irgendwie und läßt sich das von "außen" einstellen, z.B. durch eine entsprechende Manipulation der Registry?
Und wie das soweit gekommen sein kann ... natürlich habe ich im Laufe der früheren Benutzung mal mit dem einen und mal einem anderen der BS oder gar von einer anderen HD aus gebootet und auf diese HD bzw. Partition zugegriffen, und häufg genug kommt dann der Hinweis, daß dies mangels Rechte nicht möglich sei, und dann klicke ich eben darauf, daß die Rechte eingeräumt werden - tausendfach erfolgt, aber noch nie mit so einem Ergebnis. Und daß hierbei dann - warum auch immer - die Rechteverwaltung völlig vermurkst wurde. Etwas anderes als mögliche Ursache fällt mir nicht ein.

 

[Wolf.J]

also "irgendwie" Admin-Rechte hat (wenn auch anscheinend nicht so viel wie der "echte" Administrator).

Doch, hat er, einen echten Administrator in dem Sinne gibt es nicht, nur einen vom System angelegten.
Und der ist per Standard deaktiviert.
Allerdings gibt es über dem Administrator noch zwei weitere Berechtigungsstufen, System und trusted Installer.
Deine persönliche Berechtigung greift aber erst, nachdem Windows gestartet ist bis zum Anmeldebildschirm, oder genauer nach der Anmeldung.
Und da wäre es dann auch egal, ob der User zur Gruppe der Administratoren gehört oder nicht.
Aber so weit kommt es ja bei Dir gar nicht, wenn ich Dich nicht völlig falsch verstanden habe.
Deshalb bin ich der Meinung, dass an der gesamten Installation etwas kaputt ist.
Beim Zugriff von einer anderen lauffähigen Installation aus ist es nicht ungewöhnlich, dass zuerst Rechte für die jeweiligen Platten oder Partitionen übernommen werden müssen.
Das hat aber nichts mit dem Startproblem von dieser einen Partion zu tun.

Beitrag automatisch zusammengeführt: 01.12.2022

Um das Thema Registry noch zu ergänzen, an die kommst Du erst dann ran, wenn Windows gestartet ist, und zwar auch das "richtige" Windows.

 

[MarkF]

Wie gesagt, mit den Rechten etc. kenne ich mich nicht aus. Ich sehe nur, daß ich von den anderen BS aus als Admin-Gruppen-User nicht mal die LW-Daten sehe und auf nichts zugreifen kann, wenn ich das betreffende Programm als "Aministrator" starte aber schon. Ob das nun die Rechte des Admin-accoungs sind oder noch höhere Rechte wei ich nicht. Mag schon sein, daß hier die Bezeichnung "Administrator" nicht korrekt ist und es sich um "Systemrechte" (im Englischen heißt es wohl "elevated") handelt, aber Windows/MS spricht da ja selbst von "Administrator".
Und da der lokale Sitzungsmanager ja irgendwas mit dem angemeldeten bzw. anzumeldendende User zu tun hat und der eben auch mein "einfacher" account aus der Admin-Gruppe ist und das Problem erst dann auftritt, wenn der lokale Sitzungsmanager aufgerufen wird, spricht das alles dafür, daß warum auch immer dessen Rechte nicht ausreichen, um beim Booten auf die Dateien zugreifen zu können. Andernfalls dürfte/würde das BS doch nicht bi dahin booten.
Hinsichtlich des Zugrifs auf die fremde Registry irrst Du aber. Selbstverständlich kannst Du jedenfalls auf Teile der anderen Registry zugreifen, indem du die entsprechende Struktur in RegEdit des laufenden BS einbindest. Schon tausend Mal gemacht bzw. machen müssen.
Ich vermute, daß der "aktuelle" User, dessen account beim Booten aktiv ist, irgendwo in der Registry niedergelegt ist, weiß aber nicht, wo.

 

[Wolf.J]

Ich vermute, daß der "aktuelle" User, dessen account beim Booten aktiv ist, irgendwo in der Registry niedergelegt ist, weiß aber nicht, wo.

Ich auch nicht, beim Booten ist noch kein User aktiv.
Die Installation ist beschädigt. Eine andere Erklärung habe ich leider nicht.

 

[MarkF]

Mit "Installation" meinst Du das BS, also das konkrete Win10? Nun ja, daß da etwas nicht stimmt ist ja mittlerweile klar.
Ich habe jetzt mal versuchsweise - auf dem backup - in/aus den anderen BS die Rechte bezüglich dieser Installation (also dem problematischen Win10 der ersten Partition) geändert. Denn zumindest da stimmt ja etwas nicht. Für das LW waren unter Eigenschaftem/Sicherheit als User nur eingetragen "Administratoren" und "Sicherheit", und zwar ohne jede Berechtigung - offensichtlich nicht "richtig". Bei den anderen LW haben diese alle Rechte und außderm sind "Authentifizierte Benutzer" ohne Rechte (auf Root-Ebene) und "Benutzer" (ohne Schreib-/Änderungsrechte auf Root-Ebene) eingetragen.
Nch einigen nicht erfolgreichen Änderungen, die ich leider nicht protokolliert habe, habe ich schließlich diese User hinzugefügt, außerdem vorsorglich auch "Jeder", denn bei den anderen LW sind bei einzelnen Verzeichnissen zusätzlich auch andere User eingetragen, und habe allen Usern Vollzugriff eingeräumt. Letztlich wurden diese Änderungen akzeptiert und danach konnte ich von den anderen LW auf diese Installation zugreifen.
Jedenfalls nach diesen erfolgreichen Änderungen lief auch der Bootvorgang auf diesem LW durch. Aber:
Wie das erste Foto zeigt, fehlen bei den Icons auf dem Desktop die Beschriftungen. Achtet auf die Taskleiste: Direkt nach dem Booten wirkt sie noch normal, wie ich sie bei mir eingestellt habe, auch bei den anderen Installationen.
Wenige Sekunden darauf ändert sie sich, wie auf dem zweiten Foto erkennbar. Und es bleibt beim Fehlen der Icon-Beschriftungen.

Auch bei den Programmen fehlen die Beschriftungen, exemplarisch nachfolgend der Explorer in der "Dieser PC"-Ansicht,

beim Anklicken von LW C:

sowie Chrome.

Strange. Da keinerlei Beschriftungen zu erkennen sind, ist auch nicht möglich, die Rechteer-/verteilung zu überprüfen und ggfs. zu korrigieren. Denn ich vermute, daß es einen Unterschied darstellt, die Rechtevergabe von einem anderen BS aus zu betrachten als im laufenden System.
Was nun? Ich vermute immer noch ein Rechteprobkem. Bei den Verzeichnissen und Subverzeichnissen sind teilweise viele andere User eingetragen. Gibt es keinen User/Eintrag), der alle anderen umfaßt, so daß sichergestellt ist, daß der Zugriff auf Dateien nicht (mehr) an fehlenden Rechten scheitert?

 

[Wolf.J]

Jedenfalls nach diesen erfolgreichen Änderungen lief auch der Bootvorgang auf diesem LW durch.

Wenn das Windows ja jetzt bootet, kannst Du ein Inplace Upgrade probieren, das würde jedenfalls die Systemdateien usw. reparieren.

 

[MarkF]

Nun, das würde nicht funktionieren, weil wie gesagt überhaupt keine Texte angezeigt werden. Wenn nichts angezeigt wird, wie soll das ein Upgrade/Update erfolgen/ausgelöst werden?
Aber ich habe zwischenzeitlich das ganze nochmal mit weiteren Usern "Alle Anwendungspakete", "Ersteller-Besitzer" sowie "Erstellergruppe" durchgeführt sowie "Trusted Installer" und den Besitzer des LW wie bei den anderen LW in "Trusted Installer" geändert. Wie "immer" gibt es Fehlermeldungen bei mal diesen, mal jeden Ordnern/Dateien, wie z.B.
"Fehler beim Anwenden von Sicherheitsinformationen auf
D:\Boot
Fehler beim Aufzählen der Objekte im Container. Zugriff verweigert."
Schließlich hören ab
"d:\wi...\0002de422fdcd801b8ff010038018404.specialize.xml"
die Fehlermeldungen nicht mehr auf, hunderte, tausende, ohne Ende, und ich muß abbrechen.
Dennoch: Danach gebootet und nun werden auch die Texte angezeigt und die Taskleiste bleibt normal.
Aber: Zahlreiche Programme laufen nicht mehr "normal" sondern nur noch mit Admin-Rechten. Da gibt es kein erkennbares System, z.B. der Total Commander läuft normal, Xtree läuft nicht normal, NetAnimate läuft, WinRAR läuft nicht normal. Die Rechteeintragungen sind bei allen identisch.
Ob da dieses Inplace Upgrade hilft? Es ist offenkundig ein Rechteproblem, keine fehlenden/defekten Dateien. Außerdem ... das einzige Installationsmedium hier scheint eine andere Version zu sein, die Option des Beibehalten der Programme und Daten ist nicht möglich. Das BS ist Version 1709 und das scheint es als ISO-Downlaoad nicht mehr zu geben.

Nachtrag/Edit: habe ein passendes ISO-Image gefunden und das Update durchgeführt. Scheint funktioniert zu haben und Stichproben zeigen, daß alle Progs wieder normal laufen. Scheint also gewirkt zu haben. Die Rechteeinstellungen sind aber geblieben, wie ich sie manipuliert habe. Jenes ist also keine Lösung für eine Produktivumgebung.
Aber da ich das jetzt nur an einem backup ausprobiert habe werde ich bei einem weiteren Durchgang schauen, ob es auch weniger invasiv möglich ist.