Anzeige
Anzeige

Am Puls von Microsoft

Anzeige

System Extrem verzögerter Windows-Start (WIN 8.1 x64)

Q

querstand

Herzlich willkommen
Hallo allerseits,

neu in diesem Forum mit der letzten Hoffnung auf sehr wichtige Hilfe bei einem eigenartigen Problem.

Ich möchte ein tadellos laufendes Win8.1-System (x64) von einer HDD auf eine SSD kopieren.
Habe diese Operation des System-Kopierens von der HDD auf SSD bereits vor längerem einmal durchgeführt, damals funktionierte es bestens.
Das dann seit damals auf SSD laufende System bekam vor einiger Zeit (mir in der Ursache unerklärliche) Probleme, die auch per Recovery eines System-Image nicht wegzubekommen waren. Deshalb wich ich auf das als Notsystem noch existente alte HDD-Windowssystem aus, das jetzt auch auf neuesten Stand gebracht ist. Aber natürlich möchte ich zurück auf SSD.

Hier liegt das Problem: Nach Cloning des HDD-Systems auf SSD (und Eintrag der SSD als zweites System in den Windows-Bootmanager per EasyBCD) startet das SSD-Windows bestens und zunächst ruck-zuck, der Desktop erscheint und Netzwerk- u. Soundkartensymbol im Traybereich ebenso, aber dann "steht" der PC für 8-10 Minuten, führt keinerlei Befehle aus, läßt allerdings noch Fenster öffnen.

Nach Ablauf der genannten Zeitspanne wird mit einem Schlag alles "nachgeliefert", sämtliche Autostart-Programme erscheinen innerhalb einer Sekunde, ebenso werden die vorher evtl. angeclickten Kommandos sämtlich ausgeführt.
Danach ist das Windows so perfekt und problemfrei wie es auch auf der HDD läuft (nur schneller, da SSD).

Dieses Problem gilt völlig identisch für das Cloning sowohl auf meine Kingston-SSD als auch auf die andere SSD (Samsung). Auf letztere soll das System eigentlich nicht kopiert werden, aber probeweise habe ich es getan, um zu sehen, ob das Problem dort auch auftritt. Leider ja.
Und ebenfalls existiert das Problem, wenn ich nicht Cloning durchführe, sondern ein UniversalRestore-Recovery eines HDD-System-Image auf die SSD (was vom Ergebnis her dasselbe ist, aber nicht direkt aus dem laufenden HDD-System erfolgt, sondern eben über ein von diesem erstelltes Image).

Was ist da los, woher kommt diese seltsame Verzögerung auf den SSD-Platten, obwohl das "kopierte" Windows-Original die Verzögerung nicht hat?? Habe dazu bisher nichts gefunden im Netz.

Wenn jemand Abhilfe wüßte, wäre das wundervoll, denn anderenfalls müßte ich trotz perfekt laufenden kopierfähigen HDD-Systems die Sisyphos-Arbeit vornehmen, auf SSD das Windows neu aufzusetzen. Ziemlich schreckliche Vorstellung, zumal angesichts dessen, daß der Windows-Klon auf SSD ja auch perfekt läuft, wenn man von der Startverzögerung einmal absieht. Aber die ist natürlich nicht tragbar.

Herzlichen Dank schon mal an alle potentiellen Helfer!
 
Anzeige
Wenn Du Glück hast, wurde die SSD einfach nicht richtig von Windows erkannt. Dann einfach in einer Eingabeaufforderung mit Admin-Rechten den Befehl winsat formal ausführen und neu starten. Vielleicht wird der Fehler auch durch den Schnellstart verursacht. Diesen mal testweise in den Energieoptionen abschalten.

Wenn Du Pech hast, ist das ein Fehler beim Klonen oder der Windows-Installation, der sich kaum mit vertretbarem Aufwand ermitteln läßt.
 
Ein Klonen oder Umzug von HDD auf SSD ist nicht empfehlenswert,allein schon wegen
der SSD TRIM-Unterstützung.
Diese kann man zwar mit dem Befehl "fsutil behavior set Disable DeleteNotify 0" aktivieren,
es sind aber weitere Maßnahmen erforderlich um die volle SSD Performance zu nutzen.
-Defragmentierung deaktivieren
-Ruhezustand deaktivieren
-Readyboot deaktivieren
-Prefetch und Superfetch deaktivieren
Dieses ganze gewerkle erspart man sich bei einer sauberen Cleaninstallation auf einer SSD.
 
Wird die SSD im AHCI Modus betrieben ?

Nicht das dein Windows vorher auf der HDD im IDE Modus lief,dann wird nämlich jetzt auf der SSd kein Native Command Queuing und ich glaube auch kein Trim unterstützt.
 
Schon mal gleich herzlichen Dank an alle Kommentatoren!

In meinem vorherigen Post habe ich mich übrigens vertan und muß korrigieren, daß der damalige Windows-Klon von der HDD erfolgt sein soll.
Jetzt ja, aber damals nicht, sondern damals war das Original-System auf der anderen SSD (Samsung 850) und ging dann auf die Kingston NVMe herüber, die neu dazukam. Damals wie gesagt ohne Problem gelaufen, aber halt von einer SSD auf eine andere.
Vermutlich hätte ich bei Klonen von der HDD damals schon das jetzige Problem gehabt... (?)
Dann übernahm damals die Samsung 850 die Partitionen D: und E:, die vorher auf der HDD waren. Und letztere bekam das Reserve-Windows-System für Notfälle. Soweit zur Korrektur, für den Fall, daß daraus noch Erkenntnisse zu gewinnen sind.

@bezelbube:
Ja, danke für den Hinweis, ich weiß, daß da ein paar Dinge zu tweaken sind für eine SSD, aber diese Viertelstunde oder so zieht man doch gern einer Neuinstallation von Windows vor. Letztere schlägt mit bestimmt 80-100 Stunden zu Buche, ehe ich all' die himmelvielen Treiber, Einstellungen und Hilfs- und Hauptprogramme wieder so habe wie vorher (selbst wenn ich für derlei Desaster inzwischen schon so viel Zeug wie möglich portabel auf D: betreibe).
Also wenn Klonen erfolgreich möglich ist, dann ist dessen Vorzugswürdigkeit für mich keine Frage.

@build10240:
Danke für diese Hinweise. Habe beides ausprobiert, leider ohne Erfolg.

@Andreas996:
Hatte daran nicht gedacht, auch insoweit also lieben Dank.
Im BIOS sehe ich, daß beide SATA-Controller (für die HDD relevant ist SATA, nicht das beim GA X99-UD4 auch vorhandene sSATA, das einfach nur andere Anschlüsse am Board bedient) auf AHCI stehen. Reicht sicher schon, oder?

Den Registry-Schlüssel "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msahci", von dem ich in diesem Zusammenhang im Web lese, gibt es bei mir in der Registry gar nicht.
Soll ich ihn noch extra anlegen und auf Wert 0 setzen?

Nochmal ganz herzlichen Dank!!
 
Am Ende meines letzten Posts, so fiel mir auf, klingt es möglicherweise etwas mißverständlich, nämlich irgendwie nach Problemlösung oder so.

Wie auch immer, vorsorglich hier nochmal klargestellt:
Die Tips sind für mich quasi lehrreich gewesen, aber leider erfolglos.

"Reicht sicher schon" am Ende meint nicht -leider!- "reicht, um das Problem zu beseitigen", sondern "reicht, um die HDD in AHCI zu haben (ebenso wie die SSD)", so daß ein Klonen zwischen IDE und AHCI --Hinweis von Andreas996-- leider nicht die Ursache des Problems sein kann. Wäre wunderbar gewesen, wenn's anders wäre.

Der oben erwähnte Registry-Schlüssel (im HDD-Windows) müßte also wohl schon auf 0 (=AHCI) stehen, wie gesagt existiert er aber bei mir gar nicht. Aber das ändert doch nichts daran, daß das HDD-Windows also ein AHCI-Windows ist, oder?

Sofern sich nicht noch Neues ergibt, sieht es also danach aus, daß ich die so gern vermiedene Neuinstallation auf der NVMe-SSD vornehmen muß.

Erneut: Herzlichen Dank für Eure Zeit!
 
@querstand,

Du könntest noch eines versuchen, um die Neuinstallation mit Einrichten aller Programme letztlich zu umgehen:

Mach ein Backup Deiner HDD mit einem der gängigen Backup-Programme (AOMEI Backupper, Acronis TrueImage, EaseUS ToDoBackup ...) mit Booten vom Rettungsmedium des jeweiligen Backup-Programms auf eine externe Festplatte. Dabei werden alle Partitionen incl. der C-Partition mit Windows und allen installierten Programmen in eine Backup-Datei geschrieben.

Danach installierst Du Windows8.1 Clean auf die SSD (alle Partitionen löschen zu Beginn der Installation, in den nicht zugewiesenen Speicherplatz installieren), eine ausfürliche Anpassung braucht es nicht, das wird im nächsten Schritt überschrieben.

Jetzt bootest Du erneut das Rettungsmedium und spielst die C-Partition des Backups (und nur die C-Partition) zurück auf die C-Partition des vorher neu installierten Windows8.1.

Wenn das abgeschlossen ist, sollte Dein Rechner mit Deinem alten Windows-Inhalt auf der SSD laufen.

PS: Wenn Du vor diesem Versuch ein Backup Deiner SSD machst, kannst Du das auch wieder zurückspielen, falls der Versuch nicht zufriedenstellend funktioniert. Dann bist Du wieder beim jetzigen Zustand.
 
querstand schrieb:
@Andreas996:
Hatte daran nicht gedacht, auch insoweit also lieben Dank.
Im BIOS sehe ich, daß beide SATA-Controller (für die HDD relevant ist SATA, nicht das beim GA X99-UD4 auch vorhandene sSATA, das einfach nur andere Anschlüsse am Board bedient) auf AHCI stehen. Reicht sicher schon, oder?

Den Registry-Schlüssel "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msahci", von dem ich in diesem Zusammenhang im Web lese, gibt es bei mir in der Registry gar nicht.
Soll ich ihn noch extra anlegen und auf Wert 0 setzen?
Zum Vergrößern anklicken....

Dein System sollte auf AHCI laufen,wenn bei den Bios Einstellungen so Windows installiert wurde,ist dieses automatisch im AHCI.

Der Registry Schlüssel ist bei Windows 8, 10 anders gespeichert.Schau mal hier,

AHCI nachträglich aktivieren unter Windows 8, 8.1 und Windows 10
 
Lieben Dank für die neuerlichen Antworten!!

@Andreas996:
Ja, tatsächlich, da habe ich offenbar nach dem falschen Schlüssel (msahci) gesucht. "storahci" existiert bei mir und steht erwartungsgemäß auf 0.


@PeteM92:
Das ist immerhin eine verbliebene Hoffnung und eine gute Idee.
AOMEI macht bei mir jeden Tag ein Image des Windows-Systems auf eine externe USB-Festplatte, u. AOMEI war auch jetzt mit dem Cloning bzw. dem Rückspielen eines Images der HDD auf die SSD befaßt.
Recovery der HDD-C-Partition auf ein neuinstalliertes Windows auf der NVMe-SSD ist also ruck-zuck gemacht und einen Versuch wert. Wäre herrlich, wenn dann nicht wieder der Verzögerungsfehler auf der SSD aufträte. Und wenn doch, dann kann/muß ich halt zurück auf das neuinstallierte Windows, von dem ich vorher ein Image anlege (danke für diesen Hinweis, das vergißt man sonst am Ende allzuleicht, solange man das SSD-Windows immer nur als unfertig-provisorisch betrachtet!).

Aber eine Frage habe ich noch zur Neuinstallation.
Aus der Zeit, als das Windows auf der NVMe als Hauptsystem problemfrei lief, hat sich ein Zustand ergeben derart, daß der Bootmanager und die Wiederherstellungspartition auf der NVMe liegen, und zwar (auch) für das Windows-System auf der HDD.
Also wenn ich jetzt in den Freiraum (223GB) hinter diesen zwei kleinen Systempartitionen (EFI 97MB u. Systemwiederherstellung 297MB) ein neues Windows-System installiere, überschreibt mir diese Installation eigentlich die beiden kleinen Partitionen?

Cloning per AOMEI in diesen Freiraum legte immer für das geklonte Neusystem auch wieder zusätzlich eine EFI und eine Systemwiederherstellung am Ende der Platte an (ich hatte also 2x EFI und 2x Wiederherstellung). Aber die Windows-Installations-DVD, tut die das auch?
Denn wenn sie die vordere EFI u. Systemwiederherstellung überschreibt, kann ich die HDD nicht mehr booten.
Ich kann in der neuen EFI allerdings die HDD per EasyBCD eintragen, aber das allein wird sie wohl nicht zum Booten bringen, oder? Denn sie braucht vermutlich ihre 297MB-Systemwiederherstellung, oder?, die wäre dann ja auch vom neu installierten Windows "kaputtgemacht".

Wenn das so stimmt, müßte ich mit EFI u. Wiederherstellung vor der Windows-Neuinstallation auf die HDD "umziehen", nicht wahr? EasyBCD gibt, glaube ich, eine "Umzugs"-Möglichkeit. Habe dies aber noch nie durchgeführt. Zieht EasyBCD dann auch die Systemwiederherstellungspartition mit an den neuen Platz, oder nur die EFI?

Man könnte beide Klein-Partitionen vermutlich auch mit einem Partitions-Manager verschieben, aber findet das BIOS den Bootmanager überhaupt am neuen Platz?
Oder kann ich das BIOS direkt auf den Bootloader der HDD (also \Windows\system32\winload.efi) zugreifen lassen, damit er das HDD-Windows bootet?

Im Rahmen einer Neuinstallation von Windows ist es jedenfalls wichtig, daß ich immer wieder das alte HDD-Windows aufsuchen kann, als "Muster" und eine Zeit lang auch zum Arbeiten.

Warum macht es MS uns eigentlich so schwer und verteilt Windows auf drei Partitionen, anstatt sich auf eine Partition zu beschränken und das (Multi-) Bootmanagen komplett dem BIOS zu überlassen? Wäre doch viel einfacher...
 
Also mit Dual-Boot Systemen habe ich jetzt nicht die große aktuelle Erfahrung. Ich weiß nur, wenn Du ein bootendes Windows 7 System hast und danach ein Windows 10 installierst, legt Windows 10 einen Bootmanager an, mit dem man beides starten kann. Installiert man Win10 zuerst und dann Win7, funktioniert das nicht.

Ich habe eine zeitlang mit Dual-Boot gearbeitet, das war Win7 und Win8. Danach bin ich völlig von diesem Dual-Boot abgekommen. ich habe mir zu oft Dateien beschädigt oder konnte nicht darauf zugreifen, weil ich das jeweils andere System nicht ordentlich heruntergefahren habe. Seither installiere ich andere Betriebssysteme ausschließlich in virtuellen Maschinen (ich benutze den kostenlosen VMware Workstation Player). Da funktioniert so ziemlich alles inclusive an USB angeschlossenen Geräten, und das ganze läuft nur unwesentlich langsamer. Ich habe auch schon einen kompletten alten Computer mit Windows XP in eine virtuelle Maschine eingebunden. Der Vorteil dabei ist auch, ich habe Host-Betriebssystem und Gast-Betriebssystem gleichzeitig - ohne umbooten - zur Verfügung und kann immer nachschauen, wie sich das andere Betriebssystem verhält.
 
@PeteM92:
Danke für die Infos und insbesondere den Hinweis auf VMs.
Habe damit auch schon mal geliebäugelt, vor längerem, bisher aber nicht damit gearbeitet; und weiß auch nicht allzuviel davon.

Aber wenn ich das Konzept richtig verstehe, ist es ein quasi abgeschlossener Bereich (der ein bestimmtes OS simuliert) innerhalb des Träger-Systems.
Also wenn das Host-System nicht mehr läuft, ist es mit der VM auch vorbei, nicht wahr?

Wenn das richtig ist, bringt die VM eine Möglichkeit zum Betreiben anderer OS oder auch zum gefahrlosen Ausprobieren von Software, aber der von mir verfolgte Zweck des Dual-Boot wird nicht erreicht, nämlich ein Zweitsystem zu haben für den Fall des Desasters im Hauptsystem.
Also VM könnte demnach das Zweit-Windows nur ergänzen, aber nicht ersetzen.

Wie auch immer: Der Umzug der EFI-Partition auf die HDD (also "nebenan" von der zugehörigen Windows-Bootpartition) lief ganz simpel per Cloning der EFI auf der Kingston-SSD auf die HDD.

Dann habe ich Booten probiert, und das BIOS hat den neuen Bootmanager auf der HDD automatisch erkannt und im (BIOS-)Bootmenü angeboten. Habe ihn vorerst dort nach oben gerückt, er startet also jetzt automatisch.
Da die HDD in diesem (Windows-)Bootmanager ja bereits als Bootloader-Zielverzeichnis eingetragen war, war insoweit nichts zu ändern. Das HDD-Windows startete problemfrei, woraus sich auch ergibt, daß die noch nicht auf die HDD "umgezogene" Systemwiederherstellungspartition (die hatte ich noch probeweise auf der SSD gelassen) zum Betrieb von Windows nicht essentiell ist.
Ich habe in all' meinen Windows-OS immer Systemwiederherstellung abgeschaltet, hat mich ohnehin mehrfach früher im Stich gelassen. Wer darauf baut, hat schon gleich verloren, um ein externes System-Image kommt man nicht herum, und selbst das kann einen im Stich lassen, wie ich mehrfach erfuhr.
Also mag sein, daß infolge der Abschaltung der Wiederherstellung bei mir jene 297MB Wiederherstellungspartition nicht nötig sind; weiß ich nicht.

Die HDD bootet also jetzt von einer EFI, die auf ihr selbst liegt. Und die gesamte Kingston-SSD ist jetzt gelöscht und frei für eine Neuinstallation von WIN 8.1, über deren Bootpartition (also C-Partition) ich dann probeweise die alte HDD-C: aufspiele.
Vielleicht taucht die Startverzögerung dann nicht mehr auf, ansonsten muß ich halt weiter mein SSD-Windows neu aufbauen.

Melde mich dann nochmal abschließend , ob das Restoring der alten HDD-C: ins neue Windows hinein geklappt hat oder auch leider wieder die Verzögerung bringt.
Bis dahin..............
 
Nur ein kurzer Einwurf von mir zu.
aber der von mir verfolgte Zweck des Dual-Boot wird nicht erreicht, nämlich ein Zweitsystem zu haben für den Fall des Desasters im Hauptsystem.
Zum Vergrößern anklicken....
Eigentlich brauchst Du da einen zweiten Rechner. Es gibt ja nicht nur Softwareprobleme, sondern auch Hardwaredefekte. Stell Dir nur mal vor, das Netzteil Deines Rechners gibt den Geist auf, da nützt dann Dualboot nichts.
 
Ich hätte gern berichtet, ob eine WIN-Neuinstallation auf der Kingston-SSD (NVMe) mit anschließendem Recovery der C-Partition von der HDD in die neue Installation hinein die Startverzögerung beseitigt oder nicht.

LEIDER aber läßt mich die Installations-DVD Windows 8.1 erst gar nicht installieren!
Nach Auswahl des Ziels der Installation startet die Installation für ca. 3 Sekunden (Anzeige "Windows-Dateien werden kopiert 0%"), und dann kommt Fehlermeldung bzgl. irgendwie nicht bereitstehender Installationsdaten. Fehlercode: 0xC0000005.

Das gilt gleichermaßen, wenn ich nicht auf die Kingston-SSD, sondern auf die Samsung-SSD installieren möchte. Die trägt Partitionen D: und E:, hat aber momentan noch gut 120GB unzugeordneten Freiraums, in den hinein ich eine alternative Installation versuchte.
Ich hätte dann dort das Überspielen mit der HDD-C: versuchen können, und wäre die Startverzögerung dann beseitigt gewesen, hätte ich das Samsung-Windows auf die Kingston-SSD geklont. So ist es ja seinerzeit gelaufen, als die Kingston neu hinzukam und ich das System von der Samsung auf die Kingston "übersiedelte".

Also: Installation nicht möglich. Die DVD legt zwar jeweils die Systempartitionen "Wiederherstellung", EFI und Hauptpartition im Installationsziel-Freiraum an, wie ich hinterher sehe (und tut dies obendrein auch noch auf der HDD, die doch überhaupt nichts damit zu tun hat!). Aber dann kommt eben die besagte Fehlermeldung, wenn es daran gehen soll, daß die Windows-Installationsdateien kopiert werden sollen.

Kann irgendjemand sich einen Reim darauf machen, oder kennt den Fehlercode?
Ich muß letzteren jetzt mal im Netz googlen...

Einstweilen Dank in die Runde potentieller Leser!
 
Hallo querstand,

hast Du Dir schon einmal ein neues Installationsmedium erstellt und es damit versucht?
 
Hallo Felix,

nein, bei früheren Neuinstallationen hat es mit dieser DVD immer geklappt.
Aber gut, warum nicht, eine neue DVD zu erstellen und damit zu installieren kann ich versuchen.
Danke für den Tip!

Ich melde mich dann wieder............
 
Neuer Stand:

Kopie der WIN-Installations-DVD auf USB-Stick habe ich gemacht und dann damit Installation versucht. Gleiches Problem, Installation verweigert mit o.g. Fehlercode.

Im Netz fand ich den Tip, alle Festplatten zu trennen außer der einen, auf die die Installation erfolgen soll. Das hat's gebracht, damit lief die Installation zügig durch. Welcher Krampf mit Problemen hier und endlosen Kautelen da, den uns MS da vorsetzt...!

Ok, und dann direkt in die frisch installierte C-Partition der Kingston-SSD ein Recovery durchgeführt per AOMEI-Rescue-CD, ein Recovery von der C-Partition der HDD; mit der Hoffnung, daß nun endlich die Sache ohne Startverzögerung läuft.
Vergebens, wieder der Verzögerungs-Mist.

Also gut, immerhin ist das auch noch probiert worden.
Dann habe ich die drei anderen Festplatten wieder angehängt und bin jetzt wieder im HDD-Windows.

Das SSD-Windows muß also mühsam neu aufgebaut werden, sind einige Tage Arbeit, aber natürlich gibt es Schlimmeres.

Wem noch was zur Start-Verzögerung einfällt: Vorschläge nach wie vor hochwillkommen!
Ansonsten nochmals ein dickes Danke an alle Helfer!!
 
Nach dem Clonen können die Datenträger-IDs der SSD und HDD identisch sein. Das mag Windows gar nicht. Vergleiche die mal mit diskpart:

sel disk 0
detail disk
sel disk 1
detail disk

Bei Übereinstimmung eine der beiden ändern, ein Zeichen reicht.
 
Hallo Porky,

vielen Dank für diesen Hinweis, den ich mir für etwa zukünftige Problemfälle notiere.
Aktuell habe ich zwar Deine Kommandos durchlaufen lassen, sehe allerdings für sämtliche Laufwerke verschiedene IDs.

Wie man aus dem Thread entnehmen kann, habe ich allerdings Windows auf der Kingston-SSD notgedrungen neu installiert, möglicherweise hat dieser Vorgang eine etwaige ID-Problematik gelöst?
Was ich immerhin mal testen könnte, wäre ein erneutes probeweises Cloning von HDD auf die Samsung-SSD; auch dieser Vorgang machte damals ja die gleichen Probleme. Dann könnte ich die IDs vergleichen.
Wäre positivenfalls ein Bug in der Cloning-Software, nicht wahr, denn die müßte ja für eine differente ID sorgen.

Nochmal besten Dank!
 
Eine Neuinstallation schreibt auch eine neue ID (Zeitstempel). Warum noch probieren wenn jetzt alles funktioniert? Und der Cloning-Software kann man nichts vorwerfen. Klonen = 1 : 1 Kopie.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Anzeige
Oben