XP: Checkdisk beim Boot

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.

mhh schrieb:
> Was steht dort unter:
> WaitToKillServiceTimeout.

20000

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.

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 
:-)

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.

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.

Hast du irgendwann mal schreibend mit einem anderen OS als Windows auf 
die Partition zugegriffen? Zum Beispiel mit einer Linux Live-CD?

HD-Tune meint, alles sei OK. Ich hab mal einen Error Scan gestartet.

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.

Unter General ist Normal Startup ausgewählt.

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.

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...

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.

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.

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.

./. 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. ;-)

A. K. schrieb:
> Aber bitte keinen Image-Restore. ;-)

Ach, wieso denn nicht? ;-)

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.

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...

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.

> 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.

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.

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.

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.

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.

Dann schreibt die Chip Mist. Auch die aktuelle VMware Workstation läuft 
noch unter XP.

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.

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 ;-)

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.

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.