Habe nun auch einen neuen PC und nach kurzer Zeit startete er plötzlich sehr langsam (2min). Er blieb in "Windows wird gestartet" hängen. Folgende Konfiguration: C: 256GB SSD D: 4TB HDD Hab dann eine Wiederherstellung eingespielt, keine Änderung. Hab dann die W7-OEM neu installiert, keine Änderung. Da schwante mir, daß da irgendein ganz großer Bockmist in der "System Volume Information" von Laufwerk D: stehen muß. Hab dann unter Computerschutz die Systemwiederherstellung für D: auf "Aus" gesetzt und unter "Konfigurieren" gelöscht, voilà er bootet wieder in 20s. Ich schreibs hier einfach mal, weil ich diese Lösung bisher nirgends gefunden habe.
Werde ich mir einprägen.Gibt viele Sachen die man besser vorher mal gehört ,gelesen haben sollte...
Das Verhalten kann auch auf eine defekte (Magnet)Platte hindeuten (und es könnte sein dass Du nur die Symptome abgestellt hast), sollte man unbedingt prüfen.
g457 schrieb: > defekte (Magnet)Platte hindeuten Die SMART-Werte der HD auslesen könnte Hinweise geben ob sie noch gesund ist. Es gab auch schon Viren, die sich irgendwo schön versteckt haben.
Ich hab weitere Informationen: Windows 7 mag offenbar keine großen internen HDD für Backups. Jedes Systemabbild verlängert die Bootzeit. Ich hatte nur ein Systemabbild auf D: erstellt und schon wieder waren es 1min. Unter Computerschutz war Speicherplatz belegt, obwohl für D: ausgeschaltet. Nach Löschen waren es wieder 20s. Ich hab auch was dazu bei Microsoft gefunden: http://support.microsoft.com/kb/2555428/de Hat den Hotfix schon jemand probiert?
Peter Dannegger schrieb: > Hat den Hotfix schon jemand probiert? Weshalb? Keiner außer Dir und Deinem vergurkten PC hat derzeit so ein Problem. Schmeiß das eigenartige W7-OEM das sicher schön billig war raus und nimm eine ordentliche Version dann geht das auch.
Peter Dannegger schrieb: > Windows 7 mag offenbar keine großen internen HDD für Backups. Eher, wie beschrieben, zu viel Wiederherstellungsgerödel. Verkleinere doch einfach die Größe dafür (also die SVI Größe).
@ W7 (Gast), vielen Dank, für Deine Antwort, die strotzt ja nur so vor Kompetenz. Dann weißt Du ja auch, wo ich sie mir hinstecken werde. Du hast also W7 pro 64Bit und ne 4TB HDD mit vielen Systemabbildern und die Bootzeit ist weiterhin 20s. Ich hab den PC komplett installiert gekauft. Mit Aufkleber und DVD, was ja keineswegs selbstverständlich ist. Das ist ne vollwertige teure W7-DVD und kein zwielichtiger Ramsch von Ebay.
:
Bearbeitet durch User
mhh schrieb: > Eher, wie beschrieben, zu viel Wiederherstellungsgerödel. Verkleinere > doch einfach die Größe dafür (also die SVI Größe). Die kleinste Einstellung ist 1%, also 37GB, glaube nicht, daß das was bringt. Belegt waren nach dem einen Backup 3GB (Hab mal in die SVI reingesehen). Ich denke, es ist eh sinnvoller, die Backups extern zu speichern.
Ich hab nochmal etwas geforscht: Seit ich den PC habe, erfolgt bei jedem Boot das Ereignis 46 von volmgr "Die Initialisierung des Speicherabbildes ist fehlgeschlagen." auf \Device\HarddiskVolume1, das müßte ja D: sein. Das könnte vielleicht die Ursache sein, warum er sich beim Start erstmal die 3GB SVI reinzieht, sobald sie existieren. Falls jemand wirklich helfen will, statt nur zu labern, würde ich mich freuen.
> "Die Initialisierung des Speicherabbildes ist fehlgeschlagen."
Hast Du die Platte wie schon mehrfach angesprochen inzwischen mal
geprüft?
g457 schrieb: > Hast Du die Platte wie schon mehrfach angesprochen inzwischen mal > geprüft? Die Windows-Prüfung ergab keine Fehler. Das SeaTools für Windows stürzt ab in der ATA-Suche und zerstört die TV-Stick Installation. Am "Die Initialisierung des Speicherabbildes ist fehlgeschlagen." lags leider nicht. Das geht weg durch "Auslagerungsdatei von Windows verwalten". Ich hatte sie gekürzt, wie ja oft empfohlen wird. Nun ist sie wieder 16GB. Ich hab noch 2 weitere Fehler bei jedem Boot: 1. Die Sitzung "Microsoft Security Client OOBE" wurde aufgrund des folgenden Fehlers beendet: 0xC000000D. 2. Ereignisfilter mit Abfrage "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99" konnte im Namespace "//./root/CIMV2" nicht reaktiviert werden aufgrund des Fehlers 0x80041003. Ereignisse können nicht durch diesen Filter geschickt werden, bis dieses Problem gelöst ist. Ich werd mal googlen, was die bedeuten.
> Die Windows-Prüfung ergab keine Fehler.
Das ist nicht ganz die richtige Stelle für sowas. SMART ist das, was Du
willst. Genauer erst mal die aktuellen Werte ansehen, dann einen
'ausführlichen' Test über das Medium rutschen lassen. Abschließend
Fehlerlog und die aktualisierten Werte prüfen.
Event 46 hatte ich auch schonmal: Windows konnte keine Auslagerungsdatei anlegen. In der Systemsteuerung unter System wieder auf automatisch umgestellt (eingestellt war eine Partition mit zu wenig Platz) und die Warnung war weg. Ich bezweifle allerdings, dass es was mit dem eigentlichen Problem zu tun hat ;D Nach dem lahmen Start läuft sonst aber alles normal? Keine Auffälligkeiten wie z.B. starke Ausreißer in Tools wie hdtune?
g457 schrieb: > SMART ist das, was Du > willst. Oh Gott, die ist ja (fast) hinüber (siehe Anhang). Hat wohl den Transport nicht überstanden.
bluppdidupp schrieb: > Ich bezweifle allerdings, dass es was mit dem eigentlichen Problem zu > tun hat ;D Ja, alle 3 Fehlermeldungen sind völlig unkritisch.
Peter Dannegger schrieb: > g457 schrieb: >> SMART ist das, was Du >> willst. > > Oh Gott, die ist ja (fast) hinüber (siehe Anhang). Woraus schließt du das?
> Oh Gott, die ist ja (fast) hinüber (siehe Anhang).
Wenn die Werte korrekt sind zeitnah Backup machen und baldmöglichst
tauschen.
Peter Dannegger schrieb: > Hat wohl den Transport nicht überstanden. Oder der Händler hat sie schon angeschlagen verbaut. Auf jeden Fall morgen sofort reklamieren.
Peter Dannegger schrieb: > Reinhard S. schrieb: >> Woraus schließt du das? > > Health Status: Health: 47 % (DANGEROUS!) Stimmt, das hab ich elegant übersehen. In der Tabelle selbst fallen mir außer "Raw Read Error Rate" aber keine schlechten Werte auf. Bin ich zu unwissend?
Reinhard S. schrieb: > aber keine schlechten Werte auf Schau etwas tiefer unter (5), die reallocation sector count.
Peter Dannegger (peda) schrieb: Peter Dannegger schrieb: > Ich hab den PC komplett installiert gekauft. g457 schrieb: >> SMART ist das, was Du >> willst. > Oh Gott, die ist ja (fast) hinüber (siehe Anhang). > Health Status: Health: 47 % (DANGEROUS!) Welcher Händler war's denn diesmal? Alternate (Gehäuse mit Kratzern), Mindfactory (Board mit Lötzinnresten) hatten wir schon. ;)
Anbei nochmal etwas besser lesbar. 171 Milliarden Errors in 8 Tagen klingt irgendwie nicht normal.
Tja, entweder Sea gate oder Sea gate nicht. Um die Rohwerte interpretieren zu können, müsste man wissen, wie deren Definition bei Seagate ist. Und wie diese bei einer nachweislich gesunden Platte aussehen.
mhh schrieb: > Reinhard S. schrieb: >> aber keine schlechten Werte auf > > Schau etwas tiefer unter (5), die reallocation sector count. Laut Rohwert bei 0.
So, etwas gegoogled, bei Seagate sind hohe Werte wohl normal (Schweiß von der Stirn wisch). Wird ja auch oft drauf hingewiesen, daß SMART nicht immer aussagekräftig ist. Die Festplatte hat ja auch in keinster Weise gemuckt und der Schockzähler ist auch 0. Und daß der Backup-SVI-Boot-Effekt daran liegt, glaube ich auch nicht. Muß wohl mal ne Seatools for DOS Disk brennen, um sie zu testen.
Reinhard S. schrieb: > Laut Rohwert bei 0. Verwechselt mit der Zahl davor. Ich hätte doch die Anzeige breitziehen sollen. Peter Dannegger schrieb: > 171 Milliarden Errors in 8 Tagen klingt irgendwie nicht normal. Finde ich auch recht viel. 1 TB Seagate: 94 Millionen in 4187 Betriebsstunden 500 GB Seagate: 34 Millionen in 9954 Betriebsstunden Man bräuchte Zahlen von jmd. mit 2, 3 & 4 TB. Peter Dannegger schrieb: > und der > Schockzähler ist auch 0. Ich glaube, der zählt nur unter Strom. Also während des Betriebes.
Die wahnsinnig hohen Werte für die Seek Error Rate und Raw Read Error Rate hatte ich bei meinen Seagate 2TB Platten im Server auch - und zwar direkt nach den ersten Betriebsstunden. Wenn man das verfolgt (mache ich mit den Historic System Statistics von webmin) sieht das über die Monate wie ein Sägezahn aus, da zählt was hoch und dann wird es wieder zurückgesetzt. Nach 2 Jahren Dauerbetrieb (jaja, ich weiss, dafür sind sie nicht gemacht, aber sie waren billig) zeigte Platte 'sda' (Linux Box mit RAID1) 23 reallocated Sectors und Platte 'sdb' 73 - lt. der Google Studie ist das einer der wenigen Smart Werte, die als Hinweis auf ein baldiges Ableben der Platte gelten können. Wenn man danach geht, sieht deine Platte nicht so ungesund aus, wie das Smart Programm behauptet. Meine Ersatzplatten von WD (jetzt sinds richtige NAS Platten) jedenfalls zeigen völlig andere Werte oder sogar Null für diese bei den Seagate Platten extrem hohen Zahlen.
:
Bearbeitet durch User
Du könntest mal versuchen, was das Programm "Crystal Disk Info" zu den Daten Deiner Platte sagt: http://www.chip.de/downloads/CrystalDiskInfo_32778794.html Eventuell hilft bloß noch das Glanzverzinken oder Hartverchromen... :-( MfG Paul
Peter Dannegger schrieb: > Da schwante mir, daß da irgendein ganz großer Bockmist in der "System > Volume Information" von Laufwerk D: stehen muß. Als Bockmist würde ich das nicht bezeichnen. Dort werden die Schattenkopien gespeichert, die u.a. der Systemwiederherstellung dienen und Zugriff auf frühere Versionen von Dateien und Ordnern ermöglichen. Eine an sich sehr nützliche Angelegenheit, die hier jedoch aufgrund eines Bugs zu längerer Bootzeit führt. Wenn die D: Platte nur als Datengrab dient und keine Programme drauf installiert sind, kannst du die Systemwiederherstellung auf diesem Laufwerk jedoch mit ruhigem Gewissen deaktivieren, da Wiederherstellungspunkte nur für System und Programme interessant sind.
Icke ®. schrieb: > Wenn die D: Platte nur als Datengrab dient und keine Programme drauf > installiert sind, kannst du die Systemwiederherstellung auf diesem > Laufwerk jedoch mit ruhigem Gewissen deaktivieren Ist ja aus, wird aber bei einem Backup ignoriert. Auch beim Backup auf eine externe HDD wird deren SVI aufgebläht ohne Rücksicht auf die Einstellungen. Man kann es nur nachträglich im Comperschutz wieder löschen. Das Backup läßt sich trotzdem wieder einspielen. Ich vermute mal, es sind die Wiederherstellungspunkte von C:. Sie mit im Backup abzulegen, wäre wohl zu einfach gewesen. Daß es einen Hotfix gibt, zeigt ja doch, daß es mehr als 3 Hanseln betrifft.
Peter Dannegger schrieb: > Ist ja aus, wird aber bei einem Backup ignoriert. Kein Wunder, denn das Windows-Backup arbeitet ebenfalls mit Schattenkopien. Der Vorteil dieser Technik liegt darin, daß auch Dateien gesichert werden können, die gerade im Zugriff sind. Ansonsten ließe sich bspw. die Registry im laufenden Betrieb gar nicht sichern. > Ich vermute mal, es sind die Wiederherstellungspunkte von C: Die Wiederherstellungspunkte liegen immer in SVI desselben Laufwerkes, zu dem sie gehören. Wie oben schon gesagt, machen die ohnehin nur auf Systemlaufwerken Sinn oder wo Programme installiert sind. Ich würde das Windows-Backup nur für ein Baremetal-Backup des Systems nutzen und reine Datenlaufwerke mit robocopy sichern. Das hat außerdem den Vorteil, daß man im E-Fall auch auf Fremdsystemen bequem an die Daten rankommt. Hier mal ein Beispielscript, das ich so in der Praxis auf Einzelplatzrechnern verwende: ---------------------- @echo off if not exist u:\backup1.txt goto error SET BACKUPSOURCE1=D:\ SET BACKUPTARGET1=U:\BACKUP1 robocopy %BACKUPSOURCE1% %BACKUPTARGET1% /MIR /FFT /DST /DCOPY:T /XJ /R:1 /W:1 /A-:H /XD RECYCLER RECYCLE.BIN "System Volume Information" pause exit :error cls echo. echo Ein Fehler ist aufgetreten. echo USB-Platte angesteckt? echo USB-Platte hat Laufwerkbuchstaben U: ? echo. pause ---------------------- Quelle und Ziel des Backups werden in den zugehörigen Variablen festgelegt. Sind in den Pfadangaben Leerzeichen enthalten, müssen sie in Anführungszeichen eingeschlossen werden. Daß die USB-Platte immer den gleichen Laufwerkbuchstaben bekommt, erreicht man z.B. mit dem Drive Letter Manager: http://www.uwe-sieber.de/usbdlm.html Das Ziel kann aber auch eine Netzwerkfreigabe sein, z.B. "\\NAS\Datensicherung". Der Parameter /MIR legt eine Spiegelung an, gelöschte Dateien werden auf dem Backuplaufwerk ebenfalls entfernt, d.h. der Zielordner ist nach dem Backup eine exakte Kopie des Quellordners. /DCOPY:T übernimmt auch bei Ordnern das originale Erstellungsdatum, /FFT sorgt für Zeitkorrekturen auf Nicht-NTFS-Zielen, /DST berücksichtigt die Sommerzeit, /A-:H entfernt das Hidden-Attribut, /XJ kopiert keine Verknüpfungen und /XD läßt die angegebenen Ordner aus. Damit nicht aus Versehen auf ein falsches Laufwerk gesichert bzw. dieses gelöscht wird (wegen /MIR), lege ich auf dem Backupmedium eine Textdatei an (backup1.txt) und frage diese im Script ab.
echo. echo Ein Fehler ist aufgetreten. echo Ja, was denn für einer, Du Schelm? echo. ;-) MfG Paul
Paul Baumann schrieb: > echo Ja, was denn für einer, Du Schelm? Na ein Lesefehler, deiner natürlich ;-) Icke ®. schrieb: > echo USB-Platte angesteckt? > echo USB-Platte hat Laufwerkbuchstaben U: ?
Icke schrob:
>Na ein Lesefehler, deiner natürlich ;-)
REM Oh, da bin ich drüber weg gesprungen
EXIT
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.