Seit ein paar Tagen hat meine alte XP-Kiste eine Marotte: Bei jedem Boot macht sie ein Checkdisk auf D:, findet nichts und bootet dann normal. Beim nächsten Boot wiederholt sich das Spiel. Was steckt da dahinter?
Uhu Uhuhu schrieb: > Was steckt da dahinter? Außerirdische? Mache das mal im Windows, den Scandisk auf D. Dann sollte sich das geben.
mhh schrieb: > Mache das mal im Windows, den Scandisk auf D. Dann sollte sich das > geben. Leider nicht. Ich habe chkdsk d:/f ausgeführt. Weil auf d: der Swapfile liegt, wurde ein chkdsk beim nächsten Boot angefordert. Der wurde - zusätzlich zu dem komischen Check, der der Stein des Anstoßes ist - ausgeführt und beim nächsten Boot ging das Spielchen weiter, wie gehabt.
Regedit HKEY_LOCAL_MACHINE\SYSTEM\CurrrentControlSet\Control Was steht dort unter: WaitToKillServiceTimeout. ?
Gut, Wert stimmt. Weiter gehts. Nächste mgl. Ursache beseitigen: Auslagerungsdatei muß neu erstellt werden. Am einfachsten auf C aktivieren und auf D deaktivieren, dann wieder zurück nach Neustart.
Ich habe zuerst den Swapfile von d: nach c: verlegt und gleich wieder zurück. Es wurde ein Boot angefordert, den ich ausführen ließ. Während des Bootes wiederholte sich das Spielchen. Dann habe ich Swapping einfach komplett abgeschaltet und gebootet - dasselbe Spielchen. Es scheint also mit dem Swapfile nichts zu tun zu haben.
Start-Ausführen-cmd chkdsk D: /r Wenn es nicht hilft, dann: Start-Ausführen-cmd chkntfs /d (Sag aber bitte nicht, daß im s.m.a.r.t. seit einiger Zeit defekte Sektoren angezeigt werden. Ein Uhu Kopf geht auch weiter als 360° zu drehen...)
mhh schrieb: > Sag aber bitte nicht, daß im s.m.a.r.t. seit einiger Zeit defekte > Sektoren angezeigt werden. Ein Uhu Kopf geht auch weiter als 360° zu > drehen...) Smart hab ich nicht kontrolliert - gibts da irgend ein XP-eigenes Tool dafür? - und chkdsk findet 0 bad sectors. Der chkdsk D: /r dauert seine Zeit... > Ein Uhu Kopf geht auch weiter als 360° zu drehen... Wenn dir deine Finger und Augen lieb sind, probierst du das besser nicht :-)
Uhu Uhuhu schrieb: > gibts da irgend ein XP-eigenes Tool > dafür? Leider nicht. Everest (nun wieder Aida), HDTune, Ultimative BootCD - sowas in der Art bietet das Auslesen an. Bei SATA spielen allerdings einige AHCI/ RAID Treiber leider nicht mit. Im Bios dann umstellen auf IDE Modus und die UBCD verwenden (falls keine HDD gefunden wird wegen Chipsatz). Vorm Windowsstart dann wieder zurückstellen.
Es ist eine IDE-Platte. Der chkdsk D: /r ist jetzt bei 92% von Stage 5. Gefunden hat er bisher nix. Nachtrag: Eben ist er fertig geworden - 0 bad sectors. Jetzt fängt er wieder von vorne an - wieso denn das? OK, das war die Kurzversion ohne Totalscan - wieder ohne Fehler. Beim Boot hat er wieder diese Aufwärmübung gemacht... Das chkntfs /d ist vorher drüber gelaufen.
Uhu Uhuhu schrieb: > Es ist eine IDE-Platte. Dann ist sie wohl nicht mehr gaaanz neu. Ein kpl. Backup wäre nützlich. Entweder ist diese HD krank oder Dein System ist krank. chkdsk /F /R (F=force R=repair) von ANDEREM System aus wäre noch ein Versuch.
Ein DVD-Brenner steckt in der Kiste. Da lag eine CD drin. USB-Speicher ist keiner dran. Ich probier mal einen Boot ohne CD im LW. -- Ändert nichts. C: und D: sind auf derselben Platte. Bei C: meckert er nicht.
Lade mal die gratis Version von HD-Tune runter und checke die S.M.A.R.T. Daten (unter Health). Sind dort Warnings aufgelistet, oder alles OKs? WebSeite: http://www.hdtune.com/download.html Download: http://www.hdtune.com/files/hdtune_255.exe
Dann mach das Standardprogramm: - Bereinigen - Defragmentieren - Datenträger prüfen-- hast du schon gemacht - In die Datenträgerverwaltung schauen, Laufwerke neu einlesen - Einmal im abgesicherten Modus hochfahren
Hast du irgendwann mal schreibend mit einem anderen OS als Windows auf die Partition zugegriffen? Zum Beispiel mit einer Linux Live-CD?
Und wenn alles nichts hilft, dann mach die Swap auf C: und schaufele deine Daten von D: auf eine ext. HD. Dann neu formatieren und die Daten wieder zurück. Dabei gleich ausmisten. In einer halben Stunde ist das erledigt!
Die C: hat nur noch 2 GB frei - da wirds eng. Zuerst ist mal ein Backup angesagt, anschließend werd ich mal eine Runde Kontakmassage in der Kiste machen. Vielleicht hilfts was.
Start Ausführen - msconfig Ist der normale Systemstart aktiv? Wenn ja, würde ich mangels weiterer einfacher und sinnvoller Optionen eine Neuinstallation machen. Geht i.A. schneller als das weitersuchen.
>Die C: hat nur noch 2 GB frei - da wirds eng.
So oder so, du mußt nun handeln. Entweder dein D: ist groß genug um C:
zu vergrößern oder eine neue HD ist fällig.
Aber wenn du für die Swap 1GB auf C: zuweist, geht das schon für den
Transfer.
Und schalte die Datenwiederherstellung auf D: ab. Das bringt sowieso
nichts.
Und schalte in der Energieverwaltung den Ruhezustand ab. Vor allem, wenn
du ihn nicht benutzt.
Natürlich danach Neustart.
Und lösche im Win-Verzeichnis die Update-Wiederherstellung und deren
.log Dateien. Geschätzt 1GB.
Wenn ich das so lese, wird es langsam Zeit für eine passende, größere, schnellere HD. Bleibt nur die Frage ob es noch wirtschaftlich ist seinem PC. Bei ALternate ist eine schöne Liste mit HD-Daten.
Michael_ schrieb: > Und schalte in der Energieverwaltung den Ruhezustand ab. Das ist immer das Erste, was ich nach der Systeminstallation abstelle ;-) oszi40 schrieb: > Wenn ich das so lese, wird es langsam Zeit für eine passende, größere, > schnellere HD. Das ist eine 400 GB-Platte - die ist groß- und schnell genug. Zudem habe ich noch eine vom selben Typ, auf der auch ein einigermaßen aus dem Ruder gelaufenes XP ist. Das Einzige, was mir fehlt, ist eine XP-Pro-Installations-CD. Die Systeme stammen noch vom MSDN-Abo - da ist nix mehr mit neu installieren. Der Hobel ist nicht mehr der neuste und ich benutze ihn nur noch für das Wenige, was ich nicht unter Linux mache.
So, auch der Scan mit HD-Tune hat keine Defekte gefunden. Die Platte hat knapp 3500 Stunden auf dem Buckel.
Uhu Uhuhu schrieb: > Das Einzige, was mir fehlt, ist eine > XP-Pro-Installations-CD. Eine borgen. Ansonsten: Die ungute, aber einfache Lösung: Start - Ausführen - cmd chkntfs /X d: exit
Uhu Uhuhu schrieb: > Die Platte hat > knapp 3500 Stunden auf dem Buckel. Dann hat sie gerade 25% ihres geplanten Lebens hinter sich. Aber der Rechner läuft ansonsten stabil? Nicht das was ganz anderes Probleme verursacht...
mhh schrieb: > Aber der Rechner läuft ansonsten stabil? Ja, das tut er. Ist zwar nicht gerade der Schnellste, aber das ist egal. Was gegen Neuinstallation spricht, ist die Unmenge an Zeug, die da drauf ist, teilweise mit Lizenzen, die ich nicht so einfach erneuern kann. Kann man eigentlich den IE7 entsorgen, oder kann das zu Problemen führen? Datensicherung mache ich regelmäßig und die ganz wichtigen Sachen werde ich auf dem Netbook bereit halten, falls die Mühle doch noch irgendwann am Dünnschiß stirbt. Mit dem chkdsk beim Boot kann man leben, auch wenns nicht das Optimum ist...
Uhu Uhuhu schrieb: > Kann man eigentlich den IE7 entsorgen, oder kann das zu Problemen > führen? Einfach nicht benutzen. Das operative Entfernen kann neue Probleme bringen. Uhu Uhuhu schrieb: > Was gegen Neuinstallation spricht, ist die Unmenge an Zeug, die da drauf > ist, teilweise mit Lizenzen, die ich nicht so einfach erneuern kann. Everest/ Aida zeigt diese stellenweise an. Es ist natürlich das Installationsmedium notwendig für das Neuaufsetzen. Ein Image der Platte sollte man zur Verfügung haben für den Ernstfall...
mhh schrieb: > Einfach nicht benutzen. Das operative Entfernen kann neue Probleme > bringen. Wegen dem Plattenplatz... Der Müll liegt auf C: und IE8 ist auch installiert.
Michael_ schrieb: > - Bereinigen > - Defragmentieren > - Datenträger prüfen-- hast du schon gemacht > - In die Datenträgerverwaltung schauen, Laufwerke neu einlesen > - Einmal im abgesicherten Modus hochfahren Müll behindert die Funktion des Filesysteme nicht, Fragmentierung ebenso wenig - nur die Performance. Und wenn man schon Probleme hat, dann sollte man Putzaktionen und ganz besonders Defragmentierung erst recht nicht durchführen. Schon gar nicht vor der Prüfung des Datenträgers. Defragmentierung sollte man erst dann durchführen, wenn von der Funktion her definitiv alles sauber ist und nur noch die Performance stört.
Hast Du schon mal geschaut, ob im Bios Datum und Systemzeit noch stimmen? Wenn nicht, könnte Deine CMOS-Batterie leer sein. Könnte schon sein, dass Windows eine defekte HD vermutet, wenn die ihm sagt, sie hätte Daten vom 21.03.2012, laut Systemzeit ist aber der 01.01.2000...
Uhu Uhuhu schrieb: > Seit ein paar Tagen hat meine alte XP-Kiste eine Marotte: Bei jedem Boot > macht sie ein Checkdisk auf D:, findet nichts und bootet dann normal. > Beim nächsten Boot wiederholt sich das Spiel. Klingt ein wenig widersprüchlich. Wenn sich beim Reboot nach dem chkdsk erneut ein Reboot mit chkdsk anschlösse, dann wäre das eine Totschleife und das System nicht mehr konfigurierbar. Was es nicht zu Aussagen im Rest des Threads passt. Tritt das Problem also nur dann auf, wenn der Rechner frisch eingeschaltet wird, nicht aber bei Reboots ohne zwischenzeitlichem Powerdown? Wenn ja, dann schalte mal versuchsweise im BIOS alles ab, was dem Betriebssystem die Kontrolle der Stromversorgung gibt, wie ACPI und APM. Sollte dazu führen, dass er nach dem Shutdown auf "Sie können jetzt abschalten" läuft.
Michael_ schrieb: > Und wenn alles nichts hilft, dann mach die Swap auf C: und schaufele > deine Daten von D: auf eine ext. HD. > Dann neu formatieren und die Daten wieder zurück. Dabei gleich > ausmisten. > In einer halben Stunde ist das erledigt! Richtig. Funktioniert nur dann nicht, wenn auf D: Programme installiert sind. Die müßten vorher de- und anschließend wieder installiert werden. Ich habe oben gefragt, ob evtl. mit Linux auf die Platte zugegriffen wurde. In seltenen Fällen kann es dabei nämlich zu nicht behebbaren Fehlern im NFTS-Dateisystem kommen, die man nur durch Neuformatieren los wird. Die Symptomatik ist exakt die beschriebene. Ich hatte diesen Fall schon mehrfach und nachvollziehbar beim Restore ausgewählter Daten mit Acronis Trueimage, welches ebenfalls einen Linux-Unterbau besitzt.
Na, wer unter WIN Programme auf D: .. installiert, dem ist sowieso nicht zu helfen. Ich bin davon ausgegangen, das dies hier nicht zutrifft. >Müll behindert die Funktion des Filesysteme nicht, Fragmentierung ebenso >wenig - nur die Performance. Nein, ich hatte schon einen Fall, wo es beim hochfahren zu lange gedauert hat, die Programmteile zu finden. Es kam ein timeout. Und schau mal über msconfig in den Systemstart, ob dort was eingetragen ist. Und hoffentlich machst du nicht chkdsk von der Kommandozeile aus! Ich glaube, das gibt Ärger, wenn eine FAT32 größer als 32 GB ist.
Michael_ schrieb: > Nein, ich hatte schon einen Fall, wo es beim hochfahren zu lange > gedauert hat, die Programmteile zu finden. Es kam ein timeout. Ein Service-Timeout nehme ich an. Der ist in diesem Zusammenhang allerdings ein Luxusproblem.
Im allgemeinen reicht ein: chkdsk /f C: um solchen Spuk ein Ende zu machen. Befehl eintippen und ein Reboot. Hat hier bei gleichen Symptomen auch schon geholfen.
./. schrieb: > Im allgemeinen reicht ein: chkdsk /f C: um solchen Spuk ein Ende zu > machen. Hast Du eigentlich auch nur einen Beitrag in diesem Thread gelesen?
A. K. schrieb: > Müll behindert die Funktion des Filesysteme nicht Außer, wenn der Platz auf der Systempartition knapp ist - das ist der Fall. > Klingt ein wenig widersprüchlich. Wenn sich beim Reboot nach dem chkdsk > erneut ein Reboot mit chkdsk anschlösse, dann wäre das eine Totschleife > und das System nicht mehr konfigurierbar. Ja, das war etwas mißverständlich ausgedrückt. Der Boot läuft folgendermaßen ab, wenn ein chkdsk "bestellt" war: - Bios-Ausgaben auf dem Schirm - 1. Windows-Banner - blauer Bildschirm mit chkdsk und Möglichkeit, den Scan abzubrechen - 1. (ausführlicher) chkdsk-Scan, ggf. mit Oberflächenscan - Meldung, daß nichts gefunden wurde. - 2. chkdsk-Kurzscan (das ist wohl der, den er immer macht) - Meldung, daß nichts gefunden wurde. - Windows startet normal > Tritt das Problem also nur dann auf, wenn der Rechner frisch > eingeschaltet wird, nicht aber bei Reboots ohne zwischenzeitlichem > Powerdown? Es passiert bei jedem Boot, egal, ob Power down, oder Reboot. Komisch ist halt, daß das Problem nur auf D: der mit 2 Partitionen belegten Platte auftritt. Matt schrieb: > Hast Du schon mal geschaut, ob im Bios Datum und Systemzeit noch > stimmen? Die Pufferbatterie ist noch kein Jahr alt und Probleme mit der Zeit habe ich keine beobachtet. Icke ®. schrieb: > Ich habe oben gefragt, ob evtl. mit Linux auf die Platte zugegriffen > wurde. Nein. Michael_ schrieb: > Na, wer unter WIN Programme auf D: .. installiert, dem ist sowieso nicht > zu helfen. So, so... Natürlich installiere ich dort Anwendungen, zumal auf C: der Platz knapp ist.
Uhu Uhuhu schrieb: > Außer, wenn der Platz auf der Systempartition knapp ist - das ist der > Fall. Bei 2GB freiem Platz ist die Systemfunktion definitiv in keiner Weise eingeschränkt. Allenfalls die Performance. Bei Updates kanns auch mal eng werden, insbesondere wenn sämtlich Dotnet-Versionen dabei sind.
A. K. schrieb: > Bei 2GB freiem Platz ist die Systemfunktion definitiv in keiner Weise > eingeschränkt. Allenfalls die Performance. Der Swap ist schon auf D: ausgelagert und die Low-Disksapce-Warnungen kommen trotzdem immer mal wieder. Dann hau ich erst mal die Reste von Updates weg, die sich unter C:\windows angesammelt haben. Ein schöner Brocken, an den ich mich bisher noch nicht getraut habe, ist IE7. Kann man den entsorgen, ohne Angst haben zu müssen, daß die ganze Schüssel hinterher klemmt? (IE8 liegt parallel dazu auf der Platte.)
Die üblichen Löschkandidaten jenseits dessen was cleanmgr abräumt oder komprimiert: \windows\$....$ (hidden, Rollbacks für installierte Fixes) \windows\temp\* (manche sind locked) \windows\PCHealth\ErrorRep\UserDumps\* (Crash-Dumps) \windows\ie8updates\* (Downloads von installierten Fixes) \windows\SoftwareDistribution\Download\* (ebenso) Sowie manches in den Verzeichnissen der User. Treesize hilft. Aber wie gesagt, wenn 2G frei sind, dann ist die Funktion definitiv nicht behindert, allenfalls die Performance. Und auch die nur bei sowas wie 2G von 400G, weils dann Ostereiersuche nach freien Blöcken ist. 2G von 8G sind völlig problemlos (zig Win2003 Server mit 4G Systemdisk...). Ich hatte auch noch keinen einzigen Server, der aufgrund von Platzmangel ein Checkdisk-Problem geliefert hätte. Aber schon öfter welche, die bei Updates (insbesondere Dotnet) an die Kante liefen.
A. K. schrieb: > Ich hatte auch noch keinen einzigen Server, der aufgrund von Platzmangel > ein Checkdisk-Problem geliefert hätte. Da sehe ich auch keinen Zusammenhang. Das Bindeglied ist der Swapfile, der auf D: ausgelagert ist, weil sonst die C: knackevoll ist. C: ist 17 GB groß, D: hat den Rest der 400 GB - keine günstige Aufteilung, aber auch schon uralt. Das XP ist mit den Jahren und Updates auch nicht schlanker geworden.
Uhu Uhuhu schrieb: > Da sehe ich auch keinen Zusammenhang. Das Bindeglied ist der Swapfile, > der auf D: ausgelagert ist, weil sonst die C: knackevoll ist. Dann wirf das Swapfile testweise von D: runter. Zum Test vom System selbst reichen auch einige Hundert MB aus, es sei denn du hast dutzendweise Monsterprogramme im Autostart.
A. K. schrieb: > Dann wirf das Swapfile testweise von D: runter. Hab ich schon probiert - ändert an dem Luxusproblem mit D: beim Boot nichts.
Dann bleibt wohl nichts, als sich an den Gedanken zu gewöhnen, dass es NTFS-Probleme gibt, die vom Check nicht behoben werden. Backup/Restore von D wäre dann angesagt. Aber bitte keinen Image-Restore. ;-)
Um ein gesundes komplettes Image zu bekommen, braucht man eine GESUNDE Platte. Wenn das Image in der Mitte der Partition hängt, wird es evtl. nie fertig oder beim Restore bringst Du evtl. die gleichen Fehler an den gleichen Ort. Ich würde aber trotzdem je Partition eins machen schon um zu prüfen, ob es hängenbleibt beim Sichern. Löschen kannst Du es später immer noch wenn alles wieder in Ordnung ist.
Den Diskscan hat er doch schon durch. Was braucht ist eben grad keinen Image-Backup, sondern einen Backup vom Inhalt. Einen File-Backup.
Ich sichere regelmäßig mit rdiff-backup übers LAN auf einen 1,5 TB - Topf auf meinem Linuxrechner. Zusätzlich werde ich jetzt noch zur Sicherheit eins mit ntbackup machen und dann laß ich die Dinge einfach auf mich zukommen. Bei Reparaturversuchen besteht die Gefahr, daß das ganze System aus dem Ruder läuft und dann muß ich eh neu aufsetzen. A. K. schrieb: > Ein Service-Timeout nehme ich an. Ich hab jetzt mal versuchsweise den Wert HKEY_LOCAL_MACHINE\SYSTEM\CurrrentControlSet\Control\WaitToKillServiceTi meout von 20000 auf 30000 hochgesetzt. Mal sehen, obs was hilft. > Der ist in diesem Zusammenhang allerdings ein Luxusproblem. Genau... Also keine Panik.
ntbackup ist ein Mistding: Der erste Versuch brach nach 27 GB wegen eines behebbaren Fehlers auf dem Quellmedium ab. Was ist das für ein Backupprogramm, das wegen so einer Kleinigkeit den Löffel wirft?
> Was ist das für ein Backupprogramm, das wegen so einer Kleinigkeit den > Löffel wirft? Ein Verwandter vom von mir deswegen "Dreckup Exec" getauften Programmes, das durch so viele Hände ging, daß ich schlichtweg vergessen habe, wer es ursprünglich verbrochen hatte. Wozu aber ntbackup verwenden? Wenn Du als Zielmedium nicht ausgerechnet ein Bandlaufwerk verwendest, sollte eine rein dateiorientierte Sicherung z.B. mit robocopy doch ausreichen, oder habe ich irgendwas essentielles übersehen? xcopy neigt bei komplexen Dateibäumen zu Aussetzern ("zu wenig Arbeitsspeicher", was kompletter Blödsinn ist), sonst ließe sich auch das mit dem Kommandozeilenparameter /kreisch verwenden.
habe gute Erfahrung mit der Freeware Cobian Boletus... Ich mache damit beim Programmieren Quellcode Backups (Schnappschüsse) und konnte schon einige Male erfolgreich einen zu spät bemerkten Schusselfehler beheben. Lässt sich gut konfigurieren, was auch immer das Problem mit den anderen Programmen zu sein scheint. Aber na ja, Backups sind immer zu alt. GIT/SVN ist mir zu aufwändig. Cobian läuft als Dienst und macht einfach stündlich Schnappschüsse von geänderten Codefiles. Das genügt mir. Zum Thema Checkdisk, Systemwiederherstellung de- und reaktivieren könnte einen Versuch wert sein.
>So, so... Natürlich installiere ich dort Anwendungen, zumal auf C: der >Platz knapp ist. Merkst du nun endlich, das das Probleme macht. Versuche, die gesamte Platte auf einer anderen HD lauffähig zu kopieren. Danach vergrößerst du dein C: auf 100GB o.ä. Ich nehme dazu Paragon. Interessieren würde mich noch wie dein C: und D: partitioniert und formatiert sind. Wenn dein D: primär ist und sich darauf Systemteile installiert haben, dann hast du wirklich Probleme.
Das Dirty-Bit kann man via "fsutil" abfragen und setzen:
1 | fsutil dirty query c: |
1 | fsutil dirty set c: |
...zeigt fsutil an dass das Dirty-Bit gesetzt ist? Falls nicht: Setz es einfach mal und lass chkdsk beim booten nochmal durchlaufen, vllt. ist es danach dann weg ;D (k.A. ab wann fsutil verfügbar ist, denke aber XP wird das schon haben. Muss in einer Konsole mit Admin-Rechten gestartet werden)
Joe Redfish schrieb: > GIT/SVN ist mir zu aufwändig. Ich benutze rdiff-backup für die normalen Backups - das läuft auf was ähnliches hinaus. Michael_ schrieb: > Merkst du nun endlich, das das Probleme macht. Oh, oh, du bist ein kluges Bürschchen... > Wenn dein D: primär ist und sich darauf Systemteile installiert haben, Sind normale Applikationen etwa Systemteile? Im Übrigen: lesen hilft, poltern nicht.
Ich denke es gefunden zu haben:
c:\WINDOWS\system32>chkntfs /?
Zeigt die Überprüfung des Laufwerks beim Start an bzw. verändert sie.
CHKNTFS Volume [...]
CHKNTFS /D
CHKNTFS /T[:Zeit]
CHKNTFS /X Volume [...]
CHKNTFS /C Volume [...]
Volume Gibt den Laufwerkbuchstaben (gefolgt von einem
Doppelpunkt),
den Bereitstellungspunkt oder den Volumenamen an.
/D Stellt die Standardkonfiguration des Computers wieder
her,
d.h. alle Laufwerke werden beim Start überprüft und auf
den
fehlerhaften wird CHKDSK ausgeführt.
/T:Zeit Weist dem Initiierungscountdown von AUTOCHK die
angegebene
Zeit in Sekunden als Wert zu. Fehlt die Zeitangabe,
wird die aktuelle Einstellung angezeigt.
/X Schließt ein Laufwerk von der Standardüberprüfung beim
Start aus. Diese Informationen werden beim erneuten
Aufruf
des Befehls zurückgesetzt.
/C Plant die Überprüfung des Laufwerks beim nächsten
Neustart;
CHKDSK wird ausgeführt, wenn das Laufwerk fehlerhaft
ist.
Beim Aufruf ohne Optionen zeigt CHKNTFS an, ob das angegebene Laufwerk
fehlerhaft oder beim nächsten Neustart für die Überprüfung vorgesehen
ist.
chkntfs d:/d habe ich gestern schon ausgeführt - ohne Erfolg. chkntfs d: sagt jetzt - bei noch laufendem ntbackup -, das LW sei dirty. Im Eventlog sehe ich auch immer wieder mal solche Meldungen:
1 | The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume D:. |
Aber das glaubt Windows selbst nicht so recht...
Magnus Verde schrieb: > Vielleicht hilft das? > > http://www.winfuture-forum.de/index.php?showtopic=7676 Das automatische chkdsk ganz abzustellen, ist keine gute Idee. > oder das > > http://www.wintotal.de/tipparchiv/?id=1646 CHKNTFS /X d: hab ich noch nicht probiert - werde ich tun, wenn ntbackup fertig ist. Es handelte sich - wie A.K. oben anmerkte, um ein Luxusproblem, dessen Lösung nicht dringlich ist. Zudem habe ich HKEY_LOCAL_MACHINE\SYSTEM\CurrrentControlSet\Control\WaitToKillServiceTi meout von 20000 auf 30000 hochgesetzt. Mal sehen, obs was hilft, der Bootversuch steht noch aus.
Aha, da ist vermutlich ein Programm was das "Dirty" verursacht. Vielleicht mit msconfig mal alle NICH-MS-Dienste und Autostarts abschalten und schauen was passiert...
Uhu Uhuhu schrieb: > chkntfs d: sagt jetzt - bei noch laufendem ntbackup -, das LW sei dirty Sind die Chipsatz-Treiber aktuell? Kabel mal ausgetauscht?
bluppdidupp schrieb: > Sind die Chipsatz-Treiber aktuell? Kabel mal ausgetauscht? Das XP kriegt regelmäßig seine Updates. Die Kabel will ich noch durchwackeln. Das Mainboard - ein Asus P4B266 ist nicht gerade taufrisch, der Typ kam 2001 raus und dürfte bald seine 10 Jahre auf dem Buckel haben - und hat bisher keine Probleme gemacht. Eine Notwendigkeit, da irgendwelche Lowlevel-Treiber auszutauschen bestand nicht. Wäre es ein Treiberproblem, würde es sich wohl nicht gerade auf 2 Bits von 400 GB für die 2. Partition beschränken.
Uhu Uhuhu schrieb: > CHKNTFS /X d: hab ich noch nicht probiert - werde ich tun, wenn ntbackup > fertig ist. Das habe ich jetzt gemacht: direkt nach dem Aufruf war die Partition immer noch dirty.
>> Wenn dein D: primär ist und sich darauf Systemteile installiert haben, >Sind normale Applikationen etwa Systemteile? Da du noch nicht gesagt hast, ob dein D: eine primäre Partition ist, nehme ich das nun an. Bitte sei so lieb und schaue nach, ob du darauf WIN-Systemdateien findest. WIN kann das selbst gemacht haben, Dateien dorthin zu schreiben. Wenn dein D: eine primäre Partition ist, dann mach folgendes: - Starte die WIN-CD - Gehe in die Konsole - gebe bitte bootcfg / rebuild ein und füge die richtige WIN-Installation hinzu, die du dann auch startest. Laut MS-Hilfe sollte man mit bootcfg / copy eine Kopie der boot.ini anlegen. Das mit dem Problem-chkdsk hatte ich auch schon, als ich mehrere XP auf einer HD installieren wollte. Es kommt mir sehr bekannt vor. Mit dem chkdsk kommst du hier nicht weiter. Evtl. könnte auch das hier helfen: http://www.boot-us.de/tips_w06.htm Wie gesagt, wenn dein D: primär ist. Wie hast du es eigentlich geschafft, IE7 und IE8 parallel zu installieren?
> Bitte sei so lieb und ... Kann es sein, daß du ein bischen was verwechselst? Ich habe strikt darauf geachtet, daß alles, was Systembezug hat, auf C: installiert wird. Auf D: sind Anwendungen und Daten und ein System wurde dort nie installiert. Lediglich der Swap ging von C: nach D:, als es auf C: eng wurde. > Wie hast du es eigentlich geschafft, IE7 und IE8 parallel zu > installieren? Das hat der M$-Update gemacht. Der IE7 ist über Menüs nicht zugänglich, aber der Code liegt noch unter c:\windows. Das System hat sicher schon 5 Jahre auf dem Buckel - nach so langer Zeit sind die einfach nicht mehr jugendlich... Und: das Problem ist ein Luxusproblem - wenn es nicht zu lösen ist, ohne riesige Klimmzüge zu veranstalten und alles mögliche zu gefährden, dann bleibt es eben.
So, das Problem scheint gelöst zu sein: Uhu Uhuhu schrieb: > Zudem habe ich > HKEY_LOCAL_MACHINE\SYSTEM\CurrrentControlSet\Control\WaitToKillServiceTi meout > von 20000 auf 30000 hochgesetzt.
Uhu Uhuhu schrieb: >> Zudem habe ich >> HKEY_LOCAL_MACHINE\SYSTEM\CurrrentControlSet\Control\WaitToKillServiceTi meout >> von 20000 auf 30000 hochgesetzt. Was bedeutet das eigentlich? Kann ich mir das so erklären: Die Kiste ist durch "zumüllen" so langsam geworden, so dass beim Runterfahren (immer Hintergrund laufende) Programme nicht ordentlich beendet werden können. Windows killt diese Prozesse, damit Runtergefahren werden kann und diese markieren einen Fehler? Der Timeout auf 30000 verhindert diesen Effekt? Wenn das so wäre, müsste man dann in einem Jahr den Timeout noch höher setzen? Würde mich interessieren.
Hans schrieb: > Die Kiste ist durch "zumüllen" so langsam geworden, so dass beim > Runterfahren (immer Hintergrund laufende) Programme nicht ordentlich > beendet werden können. Das wirds wohl sein. Zudem bin ich mit defrag sehr zurückhaltend, weil mir damit - trotz vorherigem chkdsk - schon einige Dateien ganz, oder teilweise abhanden gekommen sind. Ich werds jetzt aber notgedrungen nochmal riskieren. > Wenn das so wäre, müsste man dann in einem Jahr den Timeout noch höher > setzen? Das System ist uralt und der Timeout jetzt um 50% erhöht - sollte also nach Adam Riese ungefähr uralt / 2 so funktionieren. Womöglich fällt die Möhre aus anderen Gründen vorher auseinander...
Die Fragmentierung auf D: hält sich sehr in Grenzen - da liegen viele große Dateien drauf, die nicht verändert werden. Der Defrag wird also nicht viel bringen. C: sieht nicht so schön aus und ich weiß im Moment nicht, ob defrag die Partition überhaupt in Angriff nimmt - der freie Platz ist knapp über 10%.
Uhu Uhuhu schrieb: > Die Fragmentierung auf D: hält sich sehr in Grenzen - da liegen viele > große Dateien drauf, die nicht verändert werden. Der Defrag wird also > nicht viel bringen. > > C: sieht nicht so schön aus und ich weiß im Moment nicht, ob defrag die > Partition überhaupt in Angriff nimmt - der freie Platz ist knapp über > 10%. defrag wird sehr lange brauchen, wenn die Platte so voll ist. Kannst du einige dicke Brocken auf D rüberschieben und dann defrag starten? so hab ich es öfters mit meiner outlook.pst gemacht, danach war outlook auch immer wieder etwas flotter. 20% freier Platz wären schon gut zum aufräumen.
Michael K-punkt schrieb: > defrag wird sehr lange brauchen, wenn die Platte so voll ist. Es gibt eine Untergrenze für freien Platz, wenn die unterschritten ist, dann geht überhaupt nichts. Auf meinem C: sind 12% frei - defrag warnt, daß es unterhalb 15% nicht effizient ist und fragt, ob es trotzdem weiter machen soll.
Lager ein paar große Dateien aus und dann kannste defragen. Ich würde allerdings ne neue Platte einbauen und die nie mehr als 80% volllaufen lassen! Was wohl passiert, wenn Defrag einen Stromausfall erlebt? Genau deswegen benutze ich das schon seit Jahren nicht mehr. Lohnt nicht.
Abdul K. schrieb: > Lager ein paar große Dateien aus und dann kannste defragen. Ich hab einen größeren Brocken, der auf C: liegen muß, komprimiert - dann gings problemlos. > Was wohl passiert, wenn Defrag einen Stromausfall erlebt? Nix. ntfs ist ein Jounal-Dateisystem. Gefährlich sind Defekte am Filesystem und ich verstehe nicht, warum defrag die Integrität nicht selbst prüft, bevor es loslegt. Aber ungefährlich ist es trotzdem nicht...
Alles was ich über Journal-Filesystems las, ist immer dahinführend das sie nicht so sicher sind wie sie vortun. Ich vertraue dem nicht! Die offensichtlichen Fehler sind ja auch weniger das Problem. Die die irgendwann erst in Erscheinung treten und dann nichtbehebare Historie erzeugen, das sind die Hämmer! Das Defraggen war in der Urzeit der EDV deutlich zu spüren. Bei den neueren Systemen kann ich den Vorteil nicht mehr sehen. Es erübrigt sich auch, wenn man die Platte eben nicht zu voll macht. Das hat zwei Vorteile: 1. Files werden eher linear angelegt, denn es ist genug Platz da. 2. Plattenköpfe wird weniger bewegt, wa die Mechanik schont. (und 3. im Falle des Falles gibt es mehr Sektoren, die noch nicht überschrieben wurden) Aber ich bin EDV-Laie und du bist eine Eule. Du mußt nichts machen was ich dir vorschlage. Der Rat ist kostenlos <daher doch wirklich "wertvoll", oder?>. Es gab mal ein Update von Windoof, wo diese Zeit schon erhöht wurde. War noch zu Win98 Zeiten. Das Problem scheint grundsätzlich <ungelöst>.
Abdul K. schrieb: > Das Defraggen war in der Urzeit der EDV deutlich zu spüren. Bei den > neueren Systemen kann ich den Vorteil nicht mehr sehen. Bei Windows schon. > Es erübrigt sich auch, wenn man die Platte eben nicht zu voll macht. Die C:-Partition hatte ich vor Jahren, als ich das System aufsetzte mit 19 GB für meine damaligen Begriffe eher üppig ausgelegt. Trotzdem wurde der freie Platz mit jedem Update aus Redmond immer kleiner. > War noch zu Win98 Zeiten. Die 9x-Systeme waren nur notdürftig getarnte DOS-Extender und FAT ist als primäres Dateisystem für ein richtiges OS völlig ungeeignet.
Uhu Uhuhu schrieb: > Abdul K. schrieb: >> Das Defraggen war in der Urzeit der EDV deutlich zu spüren. Bei den >> neueren Systemen kann ich den Vorteil nicht mehr sehen. > > Bei Windows schon. > Ich redete von Windoof. Meine Frau will auch immer Defraggen wenn was nicht geht. Meist kann ich es verhindern. >> Es erübrigt sich auch, wenn man die Platte eben nicht zu voll macht. > > Die C:-Partition hatte ich vor Jahren, als ich das System aufsetzte mit > 19 GB für meine damaligen Begriffe eher üppig ausgelegt. Trotzdem wurde > der freie Platz mit jedem Update aus Redmond immer kleiner. > Wie erwähnt, lasse am besten 30% frei!!!!!!!!!! >> War noch zu Win98 Zeiten. > > Die 9x-Systeme waren nur notdürftig getarnte DOS-Extender und FAT ist > als primäres Dateisystem für ein richtiges OS völlig ungeeignet. Was ich nicht verstehe: Wenn ich jetzt schreibe: Mein Linux anno 1999 zeigt ein merkwürdiges Verhalten im vi. Dann wird hier kaum einer meckern, mein vi wäre zu alt. Sobald man sowas bei Windoof bringt, wird sofort gebasht! Gegenbeweis: Vor 1-2 Jahren hat der Autor von LTspice dieses Programm auch geändert, damit irgendein time-out von Windoof nicht zu einem Fehler führt. Müßte jetzt nachsehen, was das genau war. Es klang aber genauso wie dein obiges Problem. Ist LTspice nun auch veraltet? Es wird alle paar Tage aktualisiert. Oder ist das Frühjahr und die Mauser einfach dran?
Abdul K. schrieb: > Sobald man sowas bei Windoof bringt, wird sofort gebasht! Die 9x-Windows waren einfach unsicher, weil eine Menge DOS-Code im Kernel steckte, der uralt war. Z.T. noch in asm geschrieben. Es war einfach nicht ganz stabil zu bekommen, deswegen haben sie es letztlich auch weggeschmissen.
Du hast immernoch nicht gemerkt, daß M$ altes alle zwei Jahre neu verkaufen will. Man könnte es auch durch den offensichtlichen Vorsatz als Betrug bezeichnen. Assembler kann genauso stabil laufen wie eine "Hochsprache". Meist ist es auch eher umgekehrt. Vom Taschenrechner über die Heizungssteuerung usw. Wann stürzt da mal was ab? Und Assembler wird meist von Profis geschrieben, die ihr Handwerk verstehen. Im Endeffekt läuft die Kiste dann deutlich schneller. Mein WinME läuft durchaus stabil. Würde den Win7 Rechner hier als nur als merklich stabiler und langsamer bezeichnen. Mehr nicht. Meist sind es halt irgendwelche einzelne Treiber oder Programme, die das ganze System instabil machen. Hat man die gefunden oder durch Zufall deaktiviert, laufen dann beide Systeme deutlich besser. Der Effekt ist universell. Seit ich KernelEx entdeckt habe, wundert mich sowieso nix mehr. Das macht die Geschäftspolitik von M$ so richtig deutlich! Man beachte wie klein KernelEx ist!
Abdul K. schrieb: > Du hast immernoch nicht gemerkt, daß M$ altes alle zwei Jahre neu > verkaufen will. Ich habe lange genug mit den 9x-Systemen gearbeitet, um zu wissen, daß die Entscheidung, 9x zugunsten der NT-Linie ganz aufzugeben, keine Marketingentscheidung war. ASM ist nicht per se schlecht - es zeigt nur in diesem Fall, wie uralt die betreffenden Kernel-Module waren. Die waren für DOS entworfen und mit den Notwendigkeiten eines "richtigen" Betriebsystemes einfach überfordert. Da ewig dran rum zu flicken, hätte das Projekt Windows nicht voran gebracht, zumal M$ mit dem Entwurf von OS/2 gezeigt hatte, daß sie durchaus was besseres können, als DOS aufzumotzen. > Und Assembler wird meist von Profis geschrieben, die ihr Handwerk > verstehen. Im Endeffekt läuft die Kiste dann deutlich schneller. Ein modernes OS in ASM zu schreiben ist unbezahlbar - selbst für einen Riesen, wie M$. Für einen winzigen Bruchteil dieses Geldes baut man besser einen hoch optimierenden C- oder was-auch-immer-Compiler und man erhält Code, der gutem ASM-Code nicht viel nachsteht. Die fallenden Hardwarepreise tun den Rest, ASM-Programmierung überflüssig zu machen.
Deine selektive Wahrnehmung arbeitet hervorragend. Natürlich wurde bei Assembler-Code auch mehr auf Leistung geachtet. Das wird heute einfach eingespart. Soll der Anwender doch einfach noch mehr kaufen. Also ich habe beides zuhause und arbeite lieber mit WinME.
Abdul K. schrieb: > Deine selektive Wahrnehmung arbeitet hervorragend. Wie kommst du darauf? > Also ich habe beides zuhause und arbeite lieber mit WinME. Das darfst du ;-) Nur für heutige Anforderungen an Datenvolumen und Sicherheit ist die 9x-Linie überfordert und auch nicht anpaßbar. Die Entscheidung, sie einzustellen, war unumgänglich.
Uhu Uhuhu schrieb: > Ein modernes OS in ASM zu schreiben ist unbezahlbar - selbst für einen > Riesen, wie M$. Für einen winzigen Bruchteil dieses Geldes baut man > besser einen hoch optimierenden C- oder was-auch-immer-Compiler und man > erhält Code, der gutem ASM-Code nicht viel nachsteht. Nicht nur das. Als die Entwicklung von NT anfing war der Siegeszug von x86 nicht so eindeutig, wie er heute wirkt. Microsoft hatte NT nicht rein zufällig portabel gestaltet, immerhin gab es früher auch Versionen für MIPS, Alpha und PowerPC, später dann für IA64. Und neuerdings hat Microsoft ja auch ARM auf der Rechnung.
wenn ich mir die Assemblerlistings anschaue die der M$ Compiler aus meinem C-Coder erzeugt bekomme ich einen dicken Hals. Da ist nicht optimal, es funktioniert halt. Der Intel-Compiler hat die Macke Nicht-Intel-Prozessoren einfach nicht zu optimieren oder im Programmverlauf einfach auszusteigen. Das musste Intel im Kartellverfahren zugeben. Bleibt GCC wo die Inline-Assembler-Einbindung meiner Meinung nach völlig vermurkst ist wegen der komplizierten Eingabe.
>Die Kiste ist durch "zumüllen" so langsam geworden, so dass beim >Runterfahren (immer Hintergrund laufende) Programme nicht ordentlich >beendet werden können. Windows killt diese Prozesse, damit >Runtergefahren werden kann und diese markieren einen Fehler? Killen einzelner Prozesse ruiniert kein Filesystem, sondern höchstens eine gerade offene Datei. Schließlich hat der Filesystemtreiber die Kontrolle über die Konsistenz des Filesystems. Da isses egal, ob ein einzelner Prozess noch seine Dateien irgendwie abschließen konnte, oder nicht. So betrachtet wurde mit dem Timeout vermutlich was anderes indirekt gelöst.
Jens G. schrieb: > Killen einzelner Prozesse ruiniert kein Filesystem, sondern höchstens > eine gerade offene Datei. Nu ja. Der Chkdsk findet ja auch beim Uhu nach dem Durchlauf keine Fehler. Aber irgendwie wird ja markiert, das beim nächsten Start ein chkdsk gemacht werden soll. Jens G. schrieb: > So betrachtet wurde mit dem Timeout vermutlich was anderes > indirekt gelöst. Gute Frage, falls Du recht hast. Was denn dann?
Vielleicht läuft chhdsk mittlerweile wegen Zumüllung zu lang und löst damit selbst das Verhalten aus?
Hans schrieb: > Gute Frage, falls Du recht hast. Was denn dann? Hochsetzen des Timeout hat das Problem verschwinden lassen, was natürlich im Zweifelsfall die Dauer eines Shutdown verlängert. Der Timeout gilt für alle Services und hat eigentlich wohl den Sinn, einen Shutdown nicht zu verhindern, wenn sich ein einzelner Sevice aufgehängt hat. Riecht nach Flickschusterei.
Das ist ein grundsätzliches Problem in Richtung Turing. Woher soll das BS wissen ob ein Programm noch das erfüllt was es soll? Im Allgemeinen wird einfach periodisch die Event-Loop angetriggert und ein erfahrungsgemäß ausreichender Zeitlimit benutzt. Eigentlich genau das was du am PC auch machst. Mag sein, daß man etwas intelligentere Ansätze findet, aber das Problem bleibt grundsätzlich vorhanden.
Es ist vermutlich ein Fremd-Dienst oder Treiber, wie schon gesagt einfach mal alle deaktivieren mit MSConfig und testen. Kann doch nicht so schwer sein. Manchmal aber habe ich M$ im Verdacht, ältere BS kaputt zu patchen. Stück für Stück, mit jedem Patch.
@Uhu Uhuhu >Der Timeout gilt für alle Services und hat eigentlich wohl den Sinn, >einen Shutdown nicht zu verhindern, wenn sich ein einzelner Sevice >aufgehängt hat. Riecht nach Flickschusterei. Wieso Flickschusterei? Wie würdest Du denn vorgehen, wenn irgendein ein Prozess beim runterfahren hängt - ewig warten? Oder vielleicht doch irgendwann mal den Prozess killen? Ich glaube nicht, daß Du einen Tag auf das Runterfahren warten willst, bis Dir der Geduldsfaden reist. Wird chkdsk auch von diesem Timeout gesteuert? Wenn ja, dann ist der Fall ja klar, nämlich das chkdisk vorzeitig gekillt wird, und es somit zur Endlosschleife wird. @Joe Redfish (joer) >Manchmal aber habe ich M$ im Verdacht, ältere BS kaputt zu patchen. >Stück für Stück, mit jedem Patch. Ja sicher - irgendwann wird auch mal die Welt untergehen .... Vielleicht installiest Du ständig irgendwelchen Datenmüll von komischen Quellen.
Jens G. schrieb: > Wird chkdsk auch von diesem Timeout gesteuert? Das wäre absurd, denn dann könnten Leute mit immens vielen Files auf der Platte ihr Maschinchen gleich einpacken und wegschmeissen. Nicht alle Files auf einen Platte, die nicht zur Grundinstallation gehören, sind Müll.
Jens G. schrieb: > Wieso Flickschusterei? Wie würdest Du denn vorgehen, wenn irgendein ein > Prozess beim runterfahren hängt - ewig warten? Ganz einfach: weil am Symptom kuriert wird, statt die Ursache zu beheben. Es ist nicht völlig undenkbar, daß auf diese Weise auch mal irreparabler Schaden angerichtet wird. Das Mindeste wäre, daß man einen Service, der beim Shutdown wegen Timeout abgeschossen wird, im Event-Log vermerkt. Nur wenn der externe Speicher in das Problem verwickelt ist, wird das etwas schwierig. Gemacht wird es, um Lieschen Müller vorzugaukeln, alles wäre in bester Ordnung.
Abdul K. (ehydra) schrieb: > Du hast immernoch nicht gemerkt, daß M$ altes alle zwei Jahre neu > verkaufen will. Man könnte es auch durch den offensichtlichen Vorsatz > als Betrug bezeichnen. Man könnte es auch einfach mal ein Angebot an die Kunden nennen, dasdem technischen Fortschritt Rechnung trägt. Man muss nicht immer hinter allem eine Verschwörung vermuten. Über Vista und W7 gab es mecker, weil MS vergessen hatte, dass auch Tablett PCs sich bedienen lassen sollten. Also wird folgerichtig ein W8 kommen, dass dieses Problem löst. > Assembler kann genauso stabil laufen wie eine "Hochsprache". Meist ist > es auch eher umgekehrt. Vom Taschenrechner über die Heizungssteuerung > usw. Wann stürzt da mal was ab? Nix gegen ASM, bin selber Fan davon (leider zu wenig Übung, aber Grundkenntnisse sind vorhanden). Nur mal ehrlich, welches OS kennst, dass in ASM geschrieben ist und an Windows herankommt? Wieviel Mannjahre sollte so eine Entwicklung verschlingen? Die nächsten beiden Absätze fasse ich mal zusammen ;) > Und Assembler wird meist von Profis geschrieben, die ihr Handwerk > verstehen. Im Endeffekt läuft die Kiste dann deutlich schneller. > Mein WinME läuft durchaus stabil. Würde den Win7 Rechner hier als nur > als merklich stabiler und langsamer bezeichnen. Mehr nicht. Lass mich mal raten, um ein WinMe noch betreiben zu können hast du ein ziemlich überholtes Mainboard laufen. Denn auf auch nur halbwegs aktuellen MBs läuft kein Windows OS mehr unter XP! Mit viel Glück hatte ich vor geraumer Zeit (vor der Finanzkrise) noch eines, auf dem W2k lief mit einem Athlon 3500 noch ein W2k. Ich wette dein MB mit WinMe liegt dort vom Prozessor her noch deutlich darunter und vom Chipsatz (ja Abdul, auch der Chipsatz macht SEHR VIEL aus, z.B. beim Speicherdurchsatz) sowieso. Und nein, es ist nicht so, dass W2k allein soviel mehr Leistung verschlingt, dass der Geschindigkeitszuwachs gegenüber deinem WinMe aufgezehrt wird. Du gurkst schlicht noch mit einer total überholten HW herum und wunderst dich warum dein Rechner nicht wirklich schnell genug ist (sonst hättest du das Thema "Geschwindigkeit" ja nicht angesprochen).
W7 schrieb: > Denn auf auch nur halbwegs > aktuellen MBs läuft kein Windows OS mehr unter XP! Irrtum. Unter VMware läuft sogar Windows 3.11 auf aktuellen Mainboards.
Uhu Uhuhu (uhu) schrieb: W7 schrieb: >> Denn auf auch nur halbwegs >> aktuellen MBs läuft kein Windows OS mehr unter XP! > Irrtum. Unter VMware läuft sogar Windows 3.11 auf aktuellen Mainboards. Und VMware Player braucht mindestens Windows Vista, was wiederum nicht auf seinem MB läuft. Klong! Ach du meinst die große Geschwindigkeitszunahme bricht für Abdul aus, wenn er ein Linux auf seinem MB startet, darauf dann den VMware Player und damit dann ein modernes Windows oder ein ganz altes Win 3.11 bootet? Eher bekommt die FDP noch mal ihre 18 Prozent! :)
W7 schrieb: > Und VMware Player braucht mindestens Windows Vista Sagt wer? VMware meint naturgemäss, dass als Host für den Player auch XP ausreicht.
A. K. (prx) schrieb: W7 schrieb: >> Und VMware Player braucht mindestens Windows Vista > Sagt wer? VMware meint naturgemäss, dass als Host für den Player auch XP > ausreicht. Sagen die hier http://www.chip.de/downloads/VMware-Player_12994646.html
Dann schreibt die Chip Mist. Auch die aktuelle VMware Workstation läuft noch unter XP.
A. K. (prx) schrieb: > Dann schreibt die Chip Mist. Auch die aktuelle VMware Workstation läuft > noch unter XP. 4.0 erfordert bereits einen 64-Bit Prozessor. Ob Abdul den hat bzw. falls ja, läuft darauf WinMe? Wohl eher nicht ...
W7 schrieb: > Ob Abdul den hat bzw. falls ja, läuft darauf WinMe? Weshalb sollte ein Gastsystem unter VMware sich daran stören? Ein 64-Bit Prozessor erzwingt kein 64-Bit Betriebssystem, sondern macht den Einsatz davon nur möglich. Wenn ein 64-Bit Prozessor vorausgesetzt wird, dann heisst das auch nicht, dass ein 64-Bit Host-Betriebssystem vorausgesetzt wird.
A. K. (prx) schrieb: W7 schrieb: >> Ob Abdul den hat bzw. falls ja, läuft darauf WinMe? > Weshalb sollte ein Gastsystem unter VMware sich daran stören? Nur kommt er gar nicht so weit, weil das Wirt nicht auf seinem WinMe läuft. > Ein 64-Bit > Prozessor erzwingt kein 64-Bit Betriebssystem, sondern macht den Einsatz > davon nur möglich. Habe ich auch nicht behauptet. Nur hat er womöglich noch einen 32-Bitter für sein WinMe im Einsatz. Ist aber auch egal, weil es sowie so nicht läuft auf seinem Millenium. Wobei da auch noch ein bisschen RAM dazugehört.
W7 schrieb: > Und VMware Player braucht mindestens Windows Vista, was wiederum nicht > auf seinem MB läuft. Bei mir läuft er auch unter XP > Ob Abdul den hat bzw. falls ja, läuft darauf WinMe? > > Wohl eher nicht ... Ich habe hier alle möglichen 32-Bit Betriebssysteme unter VMware auf einem 64-Bit Linux-System laufen. Aber wahrscheinlich habe ich nur noch nicht gemerkt, daß das unmöglich ist ;-)
Uhu Uhuhu (uhu) schrieb: W7 schrieb: >> Und VMware Player braucht mindestens Windows Vista, was wiederum nicht >> auf seinem MB läuft. > Bei mir läuft er auch unter XP Hat die Chip wohl falsch ausgewiesen. >> Ob Abdul den hat bzw. falls ja, läuft darauf WinMe? >> >> Wohl eher nicht ... > Ich habe hier alle möglichen 32-Bit Betriebssysteme unter VMware auf > einem 64-Bit Linux-System laufen. Aber wahrscheinlich habe ich nur noch > nicht gemerkt, daß das unmöglich ist ;-) Ja auf einem 64-Bit Linuxsystem ... Abdul hat aber ein 32-Bit WinMe und daraus wird auch so schnell kein 64-Bit Linux bei vermutlich einem 32-Bit Proz. Aber das kann Abdul (wenn er möchte) ja selber aufklären. Ich vermute mal das deine HW verehrter Uhu etwas moderner ist als das was Abdul da noch für den "aktuellen" Stand der Zeit hält. ;-)
W7 schrieb: > Ja auf einem 64-Bit Linuxsystem ... Fassen wir zusammen: - Du hattest behauptet, WinME würde auf aktuellen Mainboards nicht laufen - Ich setzte dagegen, daß das mit VMware sehr wohl geht - Dann ziehst du 64-Bit-Systeme aus dem Ärmel und behauptest, darauf würde unter VMware kein WinME laufen und schon gar nicht schnell und nur unter Linux - Nun trittst du den Rückzug an und beharrst darauf, daß auf WinME keine 64-Bit-Emulation unter VMware möglich ist. Außer dir kam aber niemand auf diese absonderliche Idee... Ich kann nur feststellen, daß z.B. die Kombination W98 auf VMware unter 64-Bit Linux deutlich schneller läuft, als auf einem 10 Jahre alten Rechner - und das übrigens auch auf VMware unter Windows. Fazit: Es ist leichter, einen Pudding an die Wand zu nageln, als mit dir eine einigermaßen strukturierte Diskussion zu führen.
Uhu Uhuhu (uhu) schrieb: > Fassen wir zusammen: > - Du hattest behauptet, WinME würde auf aktuellen Mainboards nicht > laufen Richtig. Genau so ist es. Ich sehe nämlich absolut keinen Sinn darin eine VM einzusetzen, die auf einem leistunsfähigerem System als WinMe es selber ist laufen muss, um anschließend zu einem WinMe downzugraden. Das ist höchstens was für Nostalgiker. > - Ich setzte dagegen, daß das mit VMware sehr wohl geht Siehe oben! > - Dann ziehst du 64-Bit-Systeme aus dem Ärmel Das war DEIN System. Du phantasierst! > und behauptest, darauf > würde unter VMware kein WinME laufen Du phantasierst schon wieder. Ich schrieb, der VMware Player ab 4.0 benötigt einen 64-Bit Prozessor und den wird Abdul nicht haben, weil sein Sytem, das WinMe, mit Sicherheit noch auf einem älteren 32-Bit Proz. läuft. > und schon gar nicht schnell und > nur unter Linux Ich schrieb, dass es Abdul nichts bringen würde ein Linux einzusetzen. Welchen Vorteil sollte er damit haben? Schneller wird sein REchner damit nicht. Einfacher wird es auch nicht (für ihn). > - Nun trittst du den Rückzug an Ich habe nirgendwo den Rückzug angetreten (schon wieder phatasierst du, muss wohl am guten Wetter liegen). Die Information eingangs stammt von der Chip Seite. Wenn die falsch ist, so what? Beschwere dich bei der Chip. > und beharrst darauf, daß auf WinME > keine 64-Bit-Emulation unter VMware möglich ist. Auf einem 32-Bit WinMe mit einem 32-Bit Prozessor wirst du wohl schwerlich eine 64-Bit Emulation hinbekommen. Woher soll der Proz. plötzlich 64-bit breite Register haben und die Virtualisierung fehlt ebenfalls. Bei AMD wird das ab Sockel AM2 unterstüzt (bestimmte Turion-64, Opteron und Sockel F), aber unter dem ist nix drin (Intel weiß ich nicht genau, hatte immer AMD). Da bleibt höchstens Bochs mit seiner x86 Emulation für ein anderes 32-Bit OS. Nur welchen Sinn sollte das haben auf dieser HW? Geschwindigkeitsrausch? Was wird auf seiner HW schneller sein als sein WinMe jetzt? Vielleicht ein Puppy Linux. Das kann er aber nativ noch schneller haben, das ist nämlich flott vom Stick gebootet. > Außer dir kam aber niemand auf diese absonderliche Idee... Ich kann nur bei dir sonderliche Bemerkungen feststellen. > Ich kann nur feststellen, daß z.B. die Kombination W98 auf VMware unter > 64-Bit Linux deutlich schneller läuft, als auf einem 10 Jahre alten > Rechner - und das übrigens auch auf VMware unter Windows. Ja natürlich, weil dein 64-Bit Linux auf einer leistungsfähigeren HW läuft als Abduls altes WinMe auf seiner alten 32-Bit Hardware. Wenn ich bei mir (> 3 Ghz, Mehrkern) eine virtuelle Maschine (es gibt ja noch andere) laufen lasse und darauf ein altes Win9x starte (wenn es denn fehlerfrei funktioniert; ausprobiert habe ich es nämlich noch nicht, aber den Spass werde ich mir bei Gelegenheit mal gönnen) ist es möglicheweise schneller als ich es noch in vergangenen Zeiten im nativen Betrieb mit meinem Vor-Vor..gänger Mainboard hatte. Diese Aussage ist aber fast schon Trivial bei x-facher mehr Rechenleistung. Nur hat das nix mit Abdul zu tun und das weißt du auch. > Fazit: Es ist leichter, einen Pudding an die Wand zu nageln, als mit dir > eine einigermaßen strukturierte Diskussion zu führen. Wenn du meinst.
W7 schrieb: > Abdul K. (ehydra) schrieb: > >> Du hast immernoch nicht gemerkt, daß M$ altes alle zwei Jahre neu >> verkaufen will. Man könnte es auch durch den offensichtlichen Vorsatz >> als Betrug bezeichnen. > > Man könnte es auch einfach mal ein Angebot an die Kunden nennen, dasdem > technischen Fortschritt Rechnung trägt. Man muss nicht immer hinter > allem eine Verschwörung vermuten. Über Vista und W7 gab es mecker, weil > MS vergessen hatte, dass auch Tablett PCs sich bedienen lassen sollten. > Also wird folgerichtig ein W8 kommen, dass dieses Problem löst. > Und wie bezeichnest du dann Ordner, die DRM oder so heißen, auf unsichtbar stehen und von der normalen Suche auch nicht gefunden werden? >> Assembler kann genauso stabil laufen wie eine "Hochsprache". Meist ist >> es auch eher umgekehrt. Vom Taschenrechner über die Heizungssteuerung >> usw. Wann stürzt da mal was ab? > > Nix gegen ASM, bin selber Fan davon (leider zu wenig Übung, aber > Grundkenntnisse sind vorhanden). Nur mal ehrlich, welches OS kennst, > dass in ASM geschrieben ist und an Windows herankommt? Wieviel Mannjahre > sollte so eine Entwicklung verschlingen? > Ein vergleichbares zu Windoof gibt es nicht. Deswegen benutze ich ja Win - eben weil es nur für dieses BS ausreichend Softwareangebot gibt. >> Mein WinME läuft durchaus stabil. Würde den Win7 Rechner hier als nur >> als merklich stabiler und langsamer bezeichnen. Mehr nicht. > > Lass mich mal raten, um ein WinMe noch betreiben zu können hast du ein > ziemlich überholtes Mainboard laufen. Denn auf auch nur halbwegs Ich kaufe immer nur Restposten oder überhole Schrott. Die Zeiten wo ich für ne Maus 250DM hinlegte, sind vorbei. > aktuellen MBs läuft kein Windows OS mehr unter XP! Mit viel Glück hatte > ich vor geraumer Zeit (vor der Finanzkrise) noch eines, auf dem W2k lief > mit einem Athlon 3500 noch ein W2k. Ich wette dein MB mit WinMe liegt > dort vom Prozessor her noch deutlich darunter und vom Chipsatz (ja > Abdul, auch der Chipsatz macht SEHR VIEL aus, z.B. beim > Speicherdurchsatz) sowieso. Und nein, es ist nicht so, dass W2k allein > soviel mehr Leistung verschlingt, dass der Geschindigkeitszuwachs > gegenüber deinem WinMe aufgezehrt wird. Du gurkst schlicht noch mit > einer total überholten HW herum und wunderst dich warum dein Rechner > nicht wirklich schnell genug ist (sonst hättest du das Thema > "Geschwindigkeit" ja nicht angesprochen). Ich habe hier mehrere Rechner mit unterschiedlichen BS - auch einen mit deinem Namen. Speziell LTspice läuft auf dem ach so alten Mainboard gute 50% schneller. Ich wäre sofort der Erste, der auf ein wirklich modernes BS umsteigen würde. So habe ich z.B. SkyOS unterstützt, aber das wurde durch die Spieler kaputtgemacht. Aber das nur so am Rande.
W7 schrieb: > A. K. (prx) schrieb: > >> Dann schreibt die Chip Mist. Auch die aktuelle VMware Workstation läuft >> noch unter XP. > > 4.0 erfordert bereits einen 64-Bit Prozessor. > > Ob Abdul den hat bzw. falls ja, läuft darauf WinMe? > > Wohl eher nicht ... "Ob" ist hier nicht die Frage! Fakten bitte! Hier ein NX1750+ 256MB RAM. Also der Rechner, wo ich mit Abstand die meiste Zeit verbringe.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.