Win7 Startet nicht mehr. Geht sofort in die Systemrep.

[thomas49]

Seit 3 Tagen bekomme ich mein T430 nicht mehr zum laufen.
Mir ist nichts bekannt was das ausgelöst hat. Lediglich am Abend zuvor wollte ich mein Totalcomander aufrufen und habe dabei eine Cryptische Fehlermeldung (Exception … so ähnlich.) bekommen. Ich wollte mich dann am nächsten Tag darum kümmern. Ansonsten ist das Win noch normal runtergefahren.
Und am nächsten Tag dann folgendes:
Windows 7 Prof 64 Bit SP1 startet nicht mehr - Beim Starten des Computers wird automatisch die "Systemstartreparatur" aufgerufen, beim Versuch diese auszuführen erscheint die Fehlermeldung: "StartRep.exe - Fehler in Anwendung - Die Anweisung in 0xfbd7584d verweist auf Speicher 0x00000008. Der Vorgang read konnte nicht im Speicher durchgeführt werden."

Beim Versuch Windows 7 wiederherzustellen (1 Wiederherstellungspunkt ist vorhanden) erscheint die Fehlermeldung: "rstrui.exe - Fehler in Anwendung - Die Anweisung in 0xfbfc584d verweist auf Speicher 0x00000008. Der Vorgang read konnte nicht im Speicher durchgeführt werden"
Ich habe eine crucial SSD M4 CT 256 (intern) auf der das Betriebssytem installiert ist.
Auf der befinden sich 3 Partitionen. Das OS Laufwerk (Windows7_OS) sowie 2 versteckte
- System_DRV
- Lenovo_Recovery
Ich habe schon folgende probiert:
1) Memtest86- 16 GB ohne Fehler
2) Die SSD habe ich mit checkdisk/f und diversen anderen Tools untersucht. Die wird mir immer als OK angezeigt. Auch habe ich mal vom jetzigen Zustand ein True Image Backup durchgeführt. Die Daten sind lesbar. Deshalb schließe ich eigentlich ein SSD Defekt aus.
3)Avira Rescue Disk hat auch keinen Virus gefunden.
4) Die Win 7 Installations DVD zeigt mir auch die oben genannten Fehler.
Abgesicherter Modus geht ebenfalls in die Systemreperatur.

Leider ist mein letztes TrueImage backup vom Mai. Deshalb versuche ich das Problem erst mal mit anderen Maßnahmen zu lösen.
Ich habe die HRENS 15.2 Boot DVD mit etlichen Tools darauf. Inklusive dem PartedMagic Linux Rescue System.
Habt Ihr eine Idee was ich noch machen kann?
Gruß Thomas

 

[think_pad]

Ich habe schon folgende probiert: 1) Memtest86- 16 GB ohne Fehler

Das BIOS mal default setzen und den Rechner mit einem Riegel RAM booten...

 

[thomas49]

OK werde ich morgen mal testen, da momentan noch Dateien gesichert werden. Kann man das Bios eigentlich irgendwie sichern ?
Oder soll ich besser jede Seite mal abfotografieren?

Thomas

 

[think_pad]

Kann man das Bios eigentlich irgendwie sichern ?

Wozu? Ein BIOS ist ein BIOS ist ein BIOS, und kann immer default [F9] gesetzt werden.

Die Fehlermeldung...

"Die Anweisung in 0xfbd7584d verweist auf Speicher 0x00000008. Der Vorgang read konnte nicht im Speicher durchgeführt werden."

... heißt bei intaktem RAM, dass entweder das BIOS den RAM falsch bzw. gar nicht anspricht, oder aber der Speichercontroller eines der RAM-Riegel einen Schuss weg hat. Dies kann aber auch heißen: Überhitzung des RAM, verdreckte RAM-Kontakte oder falsche Ansteuerspannung z.B. aufgrund eines Netzteils, welches sich gerade aufgrund eines irrlichternden Elkos mit Schwankungen verabschiedet.

 

[der_bud]

.... Kann man das Bios eigentlich irgendwie sichern ? Oder soll ich besser jede Seite mal abfotografieren?

Wozu? Ein BIOS ist ein BIOS ist ein BIOS, und kann immer default [F9] gesetzt werden.

Ich denke thomas49 möchte vor dem Setzen auf default die derzeitigen Einstellungen sichern/speichern, um zu sehen was bei default anders ist. Und da hilft meines Wissens wirklich nur Digicam oder Zettel+Stift .
Thomas, vor Biosdefault guck mal ob im Bios die Uhrzeit+Datum stimmt oder auf seltsamen Werten sitzt...

 

[laptopheaven]

Kann man das Bios eigentlich irgendwie sichern ?
Oder soll ich besser jede Seite mal abfotografieren?

Dafür gibt es ein entsprechendes Utility welches ThinkPad Setup Settings Capture/Playback Utility (SRSETUP) heisst.
Ich war mal so frei das Readme dazu zu verlinken.
Allerdings gibt es eine Voraussetzung für das Tool: Das OS muss vernünftig und stabil laufen.

 

[thomas49]

So bin wieder zurück.
Danke erst mal für die Hilfe.
Bios habe ich abfotografiert. Dann auf Standard gesetzt. Von einzelnen RAM gebootet.
Geht leider auch nicht. Ich habe aber (wahrscheinlich wegen einem RAM) ein Dosfenster und deren Inhalt für kurze Zeit sehen können, bevor es sich wieder schließt.
Da steht was von Volume1\Boot\Bootmgr > failed attemp 12 of 60. usw. Dies Zeile läuft dann wahrscheinlich 60 mal. durch.

Noch Ideen?

 

[Mornsgrans]

Google mal nach

"Bootmgr > failed attempt"

(incl. Anführungszeichen.

Ein Treffer:
http://www.sevenforums.com/windows-...0-windows-7-sp1-fails-error-0x80004005-2.html
(läuft wohl auf "Dsik full" hinaus - habe mir den Thread nicht ganz durchgelesen.)

 

[think_pad]

läuft wohl auf "Dsik full" hinaus - habe mir den Thread nicht ganz durchgelesen

Ja, läuft wohl auch auf einen SATA-Fehler, schlimmstenfalls einen Cache-Fehler in der CPU hinaus. Man müsste zuerst mit diskpart einen neuen MBR bzw. GPT schreiben und dann weiter sehen... Oder mal die SSD/HDD wechseln, oder mal probehalber mit der compatibilty-Einstellung statt ACHI starten. Oder der SSD-Controller hat sich mittendrin verabschiedet ... oder... oder... oder...

Eine gebootete LINUX-geparted-CD würde da wohl Klarheit bringen, sowohl vom Bootverhalten her als auch mit einem Screenshot der SSD-Partitionen.

 

[mccs]

Für mich klingt das nach Festplatten-/Speicherproblem.
Die einfache Möglichkeit: Bootsektor zerschossen. Zu XP-Zeiten gab's mal fixmbr und dergleichen. Wie das bei Vista ist, müsste man google fragen. Ein Bootsektor braucht jedes Betriebssystem.
Die schwerere Möglichkeit: Die Festplatte/SSD hat Leseschwierigkeiten; mind. ein Sektor kaputt/wackelig und/oder ein Ersatzsektor steht nicht mehr zur Verfügung. Wie sehen denn die Smart-Werte aus? Gibt es die bei SSD? (Habe keine...)
Da die Win-DVD zum gleichen Fehler führt, vermute ich aber eher einen RAM-Riegel als Ursache. Schon mal eine Linux-Live-CD ausprobiert? Wenn Linux läuft, ist der PC meist OK. Linux downloaden - CD brennen - ausprobieren (von der CD starten im Bios einstellen).
Zum RAM-Riegel: einzeln in verschiedenen Steckplätzen ausprobieren. Alle Kombinatioenen. Taucht der Fehler nur bei einem Riegel in allen Steckplätzen auf, ist der Übeltäter wahrscheinlich gefunden. Taucht der Fehler nur in einem Steckplatz auf, hilft nur noch säubern der Kontakte, hoffen und Glück haben. Ein defekter Steckplatz ist schwer zu reparieren.
Zur systematischen Fehlersuche ist folgendes schnell zielführend: alles unnötige ausbauen, Bootversuch, dann jeweils ein Ding dazu. Wenn dann der Fehler auftritt, weiss man, wer schuld ist.
Eine Festplatte/SSD sollte man immer in einem anderen PC testen. Man weiss ja nie, ob der Controller OK ist.

 

[thomas49]

So hier mal ein Screenshoot erstellt über das Linux System PartedMagic.

Könnt Ihr da was erkennen?

PS Im Bios hatte ich von ACHI auf compatible umgeschaltet. Auch das nützt nichts.

Thomas

 

[think_pad]

So hier mal ein Screenshoot erstellt über das Linux System PartedMagic. Könnt Ihr da was erkennen?

Ja, sowohl der Bootsektor des System-Drives als auch der Bootsektor der Recovery-Partition sind zerschossen, die Partitionen selbst sind aber intakt. Das ist das Einzige, was sicher ist...

Das Filesystem des ersten System-Drives ist aus einem bisher nicht bekannten Grund "übergelaufen", das ist auch klar. (Das passiert normalerweise, wenn zwei systemberechtigte Prozesse zur selben Zeit etwas darin schreiben wollen. So etwas kann aber auch ein Firmware-Controller-Fehler der SSD sein.)

Normalerweise bootet man jetzt ein WINDOWS PE, öffnet eine Command-Box und weist man per diskpart dem System-Drive einen Laufwerksbuchstaben x: zu, und repariert die mit...

fsutil usn deletejournal /N /D x:

Anschließend wird neu gebootet, der Laufwerksbuchstabe wird wieder entfernt, und dann muss manchmal auch der Masterboot-Record neu geschrieben werden, (alternativ Systemstartreparatur im PE), aber ich weiß nicht, ob Du so etwas wirklich kannst.

----------------------------------------------------------------------------------

Edit: Wie ich gerade sehe, kann man auch einfacher als oben dem System_Drive einen Laufwerksbuchstaben zuweisen und es dann versuchen mit chkdsk /f zu reparieren, anschließend Systemstart-Reparatur...

---
...
---​

 

[Mornsgrans]

Auf dem Linux -Desktop müsste es auch ein Tool zum Auslesen der SMART-Werte geben. Führe das mal aus und poste den Screenshot dazu.

 

[thomas49]

Vielen dank schon mal für die vielen Tipps.
Ich muss mich heute aber etwas zurückziehen.
Muss mit meiner Holden Weihnachtsgeschenke kaufen. Sie hat auch schon ganz böse geschaut weil ich nur am pc hänge.
Melde mich dieses Wochenende etwas sporadisch. Gruß und danke vorab.

 

[think_pad]

Muss mit meiner Holden Weihnachtsgeschenke kaufen. Sie hat auch schon ganz böse geschaut weil ich nur am pc hänge.

Ja, so wie sich Leistungssportler sehr unglücklich verletzen können, so sind auch schon viele hoffnungsvolle Informatiker-Karrieren an kerzenorientierten, stromlosen Familienfesten und verständnislosen Partnerinnen gescheitert. Ein Jammer, aber das ist nun mal der Lauf der Welt...

 

[thorfdbg]

Da die Win-DVD zum gleichen Fehler führt, vermute ich aber eher einen RAM-Riegel als Ursache. Schon mal eine Linux-Live-CD ausprobiert? Wenn Linux läuft, ist der PC meist OK. Linux downloaden - CD brennen - ausprobieren (von der CD starten im Bios einstellen).
Zum RAM-Riegel: einzeln in verschiedenen Steckplätzen ausprobieren. Alle Kombinatioenen. Taucht der Fehler nur bei einem Riegel in allen Steckplätzen auf, ist der Übeltäter wahrscheinlich gefunden. Taucht der Fehler nur in einem Steckplatz auf, hilft nur noch säubern der Kontakte, hoffen und Glück haben. Ein defekter Steckplatz ist schwer zu reparieren.

Die fehlgeschlagene Operation verweist auf einen Zugriff auf Adresse 0x08 - die gehört zur Real-Mode Interrupt-Tabelle, und es gibt keinen Grund, warum ein Win -XXXX Programm da irgendwas zu suchen hätte. Will sagen, wenn ein Schreiben auf diese Adresse fehlschlägt so deshalb, weil die MMU des Systems diesen Schreibvorgang abwürgt, weil die Applikation da nichts zu suchen hat. Das sieht mir nicht nach RAM-Problem sondern eher nach Softwareproblem aus.

Bevor an dieser Stelle aber weiter versucht wird, an der Festplatte "herumzudoktorn": Erstmal Daten sichern! Also, zweie Festplatte her, das Sytem mit einem Life-Linux booten, die Systemplatte als "read-Only" mounten und alle wichtigen persönlichen Daten auf eine zweite Festplatte sichern. "ganzer" wird die Systemplatte mit jedem Rettungsversuch nämlich nicht, und die Wahrscheinlichkeit, dass man um eine Neuinstallation herumkommt, steigt auch nicht gerade.

 

[think_pad]

OK werde ich morgen mal testen, da momentan noch Dateien gesichert werden.

Bevor an dieser Stelle aber weiter versucht wird, an der Festplatte "herumzudoktorn": Erstmal Daten sichern!

Du kommst zu spät, und wer zu spät kommt, den ... Das hat er doch längst gemacht! Und wenn er die NTFS-Tabelle wieder hin bekommt oder sie gar löschen/formatieren muss, kann er das System-Drive immer noch mit der Start-Reparatur wieder herstellen...

---

---​

 

[thomas49]

Anbei erstmal die Screenshoots der SSD.

Melde mich heute sporadisch wieder. Ab morgen abend habe ich etwas mehr zeit.

Thomas

- - - Beitrag zusammengeführt - - -

Als nächstes werde ich mal das von Think_pad vorgeschlagenen Post #12 versuchen.
Dazu muss erst mal wieder das Linux runterfahren und mit der Win7 DVD und F8 in die Eingabeauforderung gehen.

dauert noch ein bisschen.

Thomas

- - - Beitrag zusammengeführt - - -

Hallo Think_pad.
Bei dem Versuch mit assign=X das system_drv zu ändern, erhalte ich folgende Fehlermeldung:

Fehler beim Dienst für virtuelle Datenträger:
Der angegebene Laufwerksbuchstabe ist nicht zur Zuweisung frei.

Wenn ich einen anderen Buchstaben z.B. Y oder Z verwende geht es.
Muss es also unbedingt das X sein, oder kann ich auch mit dem Y oder Z weitermachen

Thomas

- - - Beitrag zusammengeführt - - -

Hier der Screenshot dazu

 

[der_bud]

Beachte bitte dass Beitrag #12 editiert wurde und du zunächst die einfachere Reparaturoption per chkdsk versuchst.

Das Vorgehen von think_pad in #12 gilt für den Fall das beim Booten mit z.B. WindowsPE der zu reparierende Datenträger noch gar keinen Laufwerksbuchstaben hat, dann muss er einen kriegen (zB x: ). Bei Dir wurde die Systemplatte beim Booten von DVD (= laut Screenshot F: ) erkannt und C: genannt, dann müsste think_pads Befehl direkt 'fsutil usn deletejournal /N /D c: ' lauten. Einen neuen Buchstaben für gemountete Sytempartitione kann diskpart nicht neu vergeben.

 

[think_pad]

Beachte bitte dass Beitrag #12 editiert wurde und du zunächst die einfachere Reparaturoption per chkdsk versuchst.

Ja, vermutlich reicht es hier, die Systempartition wegen NTFS-Fehlers einfach neu zu formatieren und dann mit der Systemstartreparatur einen neuen Bootloader zu erstellen.