Win10-64: Merkwürdiges Boot-Problem

[runit]

Guckst Du, damit bekommst Du noch die 1709. Aber warum betreibst Du eine so alte Version, die schon lange (April 2019) EOL ist? Du solltest damit nicht mehr online gehen, da sie voller Sicherheitslücken ist.
Genial: So fischen Sie jede Windows-Version aus dem Netz

Grundsätzlich wirst Du ein Rechteproblem nicht mit einem Inplace Upgrade lösen können. Jedoch, wenn durch individuelle Änderungen im System ein Rechteproblem entstanden ist, kann es dadurch gelöst werden, dass das System neu geschrieben wird und auch entsprechende Registry-Einträge wieder korrekt hergestellt werden.

Zumindest aber sollte ein Inplace Upgrade ein Boot-Problem lösen. Es kommt da zum Einen darauf an, dass das Systemlaufwerk technisch einwandfrei ist, und zum Anderen, dass die Boot-Partition korrekt geschrieben werden kann. Hier solltest Du für diesen Prozess alle anderen Laufwerke abklemmen, um zu vermeiden, dass irgendwo auf anderen Laufwerken eine Boot-Partition gefunden wird und Win diese nutzen will.

So solltest Du zum Anmeldebildschirm kommen. Das Benutzer-Profil scheint ja nicht beschädigt zu sein. Wenn Du soweit bist und das System zum Desktop durchbootet. ändere den Besitzer der Problem-LW, soweit das Problem noch bestehen sollte, auf Deinen aktuell angemeldeten Admin-Benutzer.

Laufwerke dem Trusted Installer zuzuordnen halte ich für keine gute Idee, weil der Trusted Installer aus Sicherheitsgründen immer bestimmte Aktionen/Zugriffe blockiert. LW musst Du immer dem gegenwärtigen Benutzer-Admin des gegenwärtigen Systems als Besitzer zuordnen. Dann hast Du in der Regel und nach eigenen Erfahrungen uneingeschränkten Zugriff auf die Laufwerke.

Leider konnte ich nicht nachvollziehen, aufgrund welchen Zustandes betroffener LW diese nicht mehr korrekt initialisiert/gemountet wurden. Wahrscheinlich, wie ja schon zuvor vermutet, wird es an einer bestehenden Beschädigung des Systems liegen, die Du ja mit dem Inplace Upgrade beheben kannst. Ich muss nicht erwähnen, dass Du jegliche systemfremde Antiviren/Firewall-Software sowie irgendwelche Optimierungs-Tools für diesen Vorgang vorher vollständig deinstallieren solltest?

 

[Terrier]

Guckst Du, damit bekommst Du noch die 1709. Aber warum betreibst Du eine so alte Version, die schon lange (April 2019) EOL ist? Du solltest damit nicht mehr online gehen, da sie voller Sicherheitslücken ist.

Das Uralt und nicht mehr unterstütztes Windows 7 wird ja auch noch genutzt.

Den Sinn von 4 Windows Installationen im Dual Boot muss man auch nicht verstehen.
Dual Boot hat ja so gut wie kein Mensch mehr, weil ja alle älteren Windows Versionen nicht mehr unterstützt werden.
Wenn man das jetzt überhaupt macht, dann höchstens jetzt mit Windows 10 und dem neuen Windows 11

Seine Windows Partitionen bis zum letzten GB voll zuballern, (Post 6) kann auf jeden Fall auch zu Problemen führen.
Ansonsten, findet man alles, was man machen kann hier bei Deskmodder.
Windows 10 reparieren wiederherstellen mit DISM Inplace Upgrade und vielen weiteren Varianten

Windows 10 reparieren wiederherstellen mit DISM Inplace Upgrade und vielen weiteren Varianten​

DISM, Reparaturmöglichkeiten von USB-Stick oder von Windows aus usw.
Wenn es dann wirklich nicht geht dann installiert man neu.

 

[MarkF]

Guckst Du, damit bekommst Du noch die 1709.

Danke, hat sich gekreuzt, hatte es wie im Nachtrag zum 3.12. geschrieben bereits gefunden.

Grundsätzlich wirst Du ein Rechteproblem nicht mit einem Inplace Upgrade lösen können. Jedoch, wenn durch individuelle Änderungen im System ein Rechteproblem entstanden ist, kann es dadurch gelöst werden, dass das System neu geschrieben wird und auch entsprechende Registry-Einträge wieder korrekt hergestellt werden.

Tja, was soll ich sagen? Wie geschrieben lief danach alles wieder, wenngleich auch die Rechte-Einstellungen so "verbogen" geblieben sind, wie ich sie ins Blaue hinein verbiegen mußte, daß ich zumindest wieder booten konnte.

Zumindest aber sollte ein Inplace Upgrade ein Boot-Problem lösen. ...

So solltest Du zum Anmeldebildschirm kommen. Das Benutzer-Profil scheint ja nicht beschädigt zu sein. Wenn Du soweit bist und das System zum Desktop durchbootet. ändere den Besitzer der Problem-LW, soweit das Problem noch bestehen sollte, auf Deinen aktuell angemeldeten Admin-Benutzer. ...LW musst Du immer dem gegenwärtigen Benutzer-Admin des gegenwärtigen Systems als Besitzer zuordnen. Dann hast Du in der Regel und nach eigenen Erfahrungen uneingeschränkten Zugriff auf die Laufwerke.

Anscheinend hast Du meine Problembeschreibung und die Entwicklung bis 3.12. nicht gelesen.
Mit dem ursprünglichen Rechte-Problem klappte ja nicht einmal das Booten, also war so ein Inplace Upgrade nicht möglich. Und von einem anderen BS gebootet ist es nicht möglich. Ich habe das an einer weiteren Kopie der originalen, betroffenen Installation versucht, nachzuvollziehen. Bislang hatte ich noch keinen Erfolg. Je nach dem, mit welchem der anderen BS ich boote, klappt nicht einmal die Besitzübernahme und wenn es klappt ermöglicht es dennoch nicht das Booten. Leider habe ich mir nicht notiert, was ich bei der ersten Kopie alles mit den Rechten und Besitz gemacht habe, bis wenigstens das Booten wieder möglich war.

Leider konnte ich nicht nachvollziehen, aufgrund welchen Zustandes betroffener LW diese nicht mehr korrekt initialisiert/gemountet wurden. Wahrscheinlich, wie ja schon zuvor vermutet, wird es an einer bestehenden Beschädigung des Systems liegen, die Du ja mit dem Inplace Upgrade beheben kannst. Ich muss nicht erwähnen, dass Du jegliche systemfremde Antiviren/Firewall-Software sowie irgendwelche Optimierungs-Tools für diesen Vorgang vorher vollständig deinstallieren solltest?

Wieso wollt ihr unbedingt eine Sytembeschädigung herbeireden? Ziemlich offensichtlich ist es eine Frage der Rechtevergabe, denn wenn es ein von den Rechten unabhängiges Problen wäre, dann könnte ich nicht von einem anderen System mit Admin-Rechten darauf zugreifen, um die Rechte zu ändern, und dann wäre bei der ersten Kopie auch nicht nach dem Vebiegen der Rechte ein Boot möglich gewesen und dann würde auch nicht dann das Proben bestehen, daß einige Progs nur noch mit Admin-Rechten laufen.

 

[runit]

ja, was soll ich sagen? Wie geschrieben lief danach alles wieder, wenngleich auch die Rechte-Einstellungen so "verbogen" geblieben sind, wie ich sie ins Blaue hinein verbiegen mußte, daß ich zumindest wieder booten konnte.

Also funktioniert das System nun wieder samt Booten?

UND NOCHMAL! Beim Booten werden noch gar keine Rechte abgefragt. Das ist eine reine Bios- u. Systemboot-Konfigurationsangelegenheit. Die Rechte greifen erst am Anmeldebildschirm, wenn ein Benutzerprofil geladen wird, genauer, wenn eines geladen wurde. Denn darin sind die Rechte verankert. Eine Ausnahme gibt es da nur, wenn die Festplatte mit Bitlocker oder einem anderen Verschlüsselungsprogramm verschlüsselt wurde. Dann würde vor dem Booten ein Pin od. ein Passwort abgefragt.

Warum dann das Booten unabhängig von Deinem vermeintlichen Rechteproblem nicht klappte, dass muss ein Helfer abstrakt versuchen mit seinem Wissen zu Win 10/11 zu erahnen. Das ist umso schwieriger, wenn man selbst weder eine solche Mehrfach-Bootkonfiguration je hatte (bei Dual-Boot ich ja noch dabei^^), noch seit Ewigkeiten keine MBR-Installation mehr hat. Also rufe ich meine naheliegensten Wissens-Vermutungen ab. Da kann man m.E. von einer Systembeschädigung, hier näher einer Beschädigung der Bootpartition/bei Dir ja Bootdaten, die es ja nicht in einer Partition gibt, sondern offenbar in C integriert sind, darum ein beschädigter Bootsektor oder beschädigte Bootdateien, ausgehen, oder von einer sonstigen Beschädigung der Festplatte, -

- oder einer fehlerhaften Bootkonfiguration in der msconfig, was ja insbesondere bei mehreren Parallelsystemen vorkommen kann und von Bedeutung für ein Bootproblem sein könnte.

Das BOOT-Verzeichnis, -Manager und BOOT-Daten habe ich auf die erste Partition - Win10-64 - verpflanzt.

Und da könnte für mich vermutlich auch das Problem liegen, nämlich eben eine jetzt ungültige Boot-Konfiguration, wodurch auch immer die entstanden sein mag. Wenn sie vor 3 Jahren noch gültig war und funktionierte, hat sich am Gerät (vlt. am Bios) seither etwas verändert, wenn denn hier tatsächlich die Ursache läge. Mit MBR-Installationen habe ich mich seit vielleicht 10 Jahren nicht mehr beschäftigt. Was Du Tradition nennst, ist für mich technisch sehr veraltet. Wie da die Bootdaten bei Mehrfach-Boot-Systemen richtig eingebunden werden und sein müssen, weiß ich nicht (mehr). Vielleicht hätte ich auch deshalb in diesem Thema nicht antworten sollen. Mit Nutzer-Rechten hat das Boot-Problem nach all meinem Wissen und Verständnis zu Win nichts zu tun.

Was ein Nutzer alles mit seinem System gemacht hat, was zu einem Rechteproblem führen konnte, wenn es denn eines gab oder gibt, und weiter zu einem Bootproblem führen konnte, was es ja ganz offensichtlich defacto gibt - das kann man doch aus der Ferne nicht sehen und nicht wissen. Da gibt es direkte Fehlerursachen und Folgefehler. Also entschuldige bitte meine mir eigene logische und pragmatische Denkweise, mit der ich versuche, einem Nutzer zu helfen, dessen Rechner, dessen Installationen, dessen Denk- u. Arbeitsweise und dessen Kenntnisse ich nicht kenne, und dessen 4-System-Konfiguration ich ebenfalls nicht kenne.

In Einem gebe ich Dir Recht. Wenn Du das System nicht booten kannst, kannst Du natürlich auch kein Inplace Upgrade durchführen. Man sollte für einen solchen Fall ein zeitnahes Backup zur Verfügung haben und zurückspielen. Wenn ich es richtig verstehe, hast Du das als von Dir mit "Kopie" bezeichnet? Wie das aber nun bei einer 3 Jahre nicht mehr benutzten Platte helfen könnte, ist mir nicht offensichtlich. Denn die Kopie müsste ja ebenso alt sein. Aber Du schreibst ja, dass Du damit das Problem beheben konntest. Das spricht für mich, entgegen meiner vorherigen Vermutung zur msconfig, letztlich für einen Sektorenfehler im Bootbereich auf der nicht funktionierenden Platte, wodurch Bootdaten nicht richtig gelesen werden konnten. Der Fehler kann beim letzten Herunterfahren der Platte entstanden sein, sodass Deine Aussage, dass die Platte beim letzten Einsatz noch booten konnte, durchaus richtig und plausibel ist und eine Erklärung wäre, warum es nun nicht mehr funktionierte.

 

[hkdd]

Mein PC1 ist auch ein "alter" mit BIOS ohne UEFI und alle SSDs / HDDs sind MBR wegen XP, was da auch noch installiert ist. Mit XP geht GPT nicht.
Auf einer 1TB SSD (Datenträger 2) sind einige Windowse drauf, gebootet wird über Win8.1, da darf ich auch nichts dran ändern. Die beiden XP stehen auf jeweils logischen Partitionen, weil es bei MBR ja nur 4 Partitionen sein dürfen. Es gibt keine eigenen Boot-Partitionen.
Die Windowse (ausser 8.1) habe ich alle mit Acronis True Image auf diese SSD geklont, vorher waren sie auf jeweils einer eigenen Platte installiert.
Win8.1 mit Bootmanger habe ich auch einzeln installiert und später mittels Acronis auf die 1 TB SSD gebracht zusammen mit den anderen Systemen.
Diese alten Windowse benutze ich nur sehr selten für spezielle Programme und evtl. Tests und regelmäßige Updates.

Auf der anderen SSD ist nur Win10 drauf, der Rest sind die von WIn10 angelegten kleinen Partitionen (ohne Buchstaben).
Von jeder SSD kann gebootet werden.
Aber egal, von wo ich booten (das muss im BIOS eingestellt bzw. mit F12-Taste ausgewählt werden), mit dem EasyBCD-Bootmanager kann ich trotzdem jedes System starten. Die beiden XP haben nochmals einen eigenen XP-Bootmanager über den man dann auch noch den abgesicherten Modus usw. auswählen kann.

Auf meinem neuen UEFI-PC mit einer Ryzen9-CPU können die alten Windowse bis 8.1 nicht mehr laufen, erst ab Windows 10.
Da habe ich die alten als virtuelle Systeme mit VMware Workstation 16 Player installiert und Win10 und 11 parallel.

"habe ich auf die erste Partition - Win10-64 - verpflanzt."

Damit hast Du das Boot-System kaputt gemacht. Daran darf man sich nicht vergreifen, sonst klappt es nicht mehr.

Wenn Du den PC mit einem Windows booten kannst, ggf. von einer anderen SSD/HDD, dann kannst Du auf diesem mit EasyBCD einen Bootmanager so einrichten, dass Du auch die anderen auf der anderen HDD starten kannst, die müssen selbst nicht bootfähig sein.

 

[Wolf.J]

"habe ich auf die erste Partition - Win10-64 - verpflanzt."

Damit hast Du das Boot-System kaputt gemacht. Daran darf man sich nicht vergreifen, sonst klappt es nicht mehr.

Doch, das funktioniert unter MBR tatsächlich.
Wie wackelig so ein Konstrukt allerdings ist, möchte ich nicht ausprobieren.
Im Übrigen kann ich nur der Argumentation von @runit zustimmen, ähnliche Annahmen hatte ich ja in meinen vorherigen Antworten auch formuliert.
Aber eine Ferndiagnose ist bei der Gemengelage nicht möglich.