Wo merkt sich WIN dass CHKDSK nötig wäre?

[cumulonimbus8]

Ich glaube ich gebe diesen Thread auf…


Ich habe in keiner Weise vor CHKDSK per Scheduler (und ich weiß was das ist) zu starten, hatte es nicht vor und werde es nicht vor haben.
Ein Task ist für mich das was ich im Taskmanager betrachten kann. Deswegen frage ich so blöd. Wäre das Stichwort geplanter Task gefallen wäre alles klar gewesen.

Wenn es "Aussetzer" gibt, dann hat dies eine Ursache.

Hitze. Schlicht die Hitze die an den betreffenden Tagen herrschte.
Den Dateisystemen an sich geht es Prima. Durch Plattenabstürze verursachte Dateiverluste oder Tabellenfehler haben nichts mit dem Dateisystem selbst zu tun… Selbige sind mir zugestoßen.

Nun noch mal zur Klarheit: Wir haben es hier mit Computern zu tun. Mit Bits und Byte, Null und Eins. Demnach müsste es konsequent logisch sein, dass jegliches Betriebssystem Fehlerzustände auf Platten (DirtyBits) immer identisch erkennt und drauf reagiert.
Genau das aber ist nicht passiert! Warum? Wo ist die Logik? Das würde ich gerne wissen!

Keine Ahnung, was dieser Satz bedeuten soll.

Kein Scheduler, und ich nur nach konkreten Anlässen, lösen CHKDSK aus - oder eben von WIN selbst.

Zwei Kommas ergänzt, ein ch rausgeworfen und e und n neu sortiert. Besser so?
Mit dem Scheduler hatte ich ja richtig geraten.

Sorry, aber wenn du meinst, dass dich Rumbölken weiter bringt als das Finden der Fehlerursache...

Ich grummele nur weil meinw Frage nicht beantwortet wird…

Nochmal: Du hast ein Problem. chkdsk versucht es zu lösen.

Ich habe keine Probleme, mehr die Platten und noch mehr WIN(s) damit zu erkennen wann CHKDSK erforderlich ist.
Würden beide involvierten WINs die selben Fehler angehen und lösen wollen hätte ich kein Wort hier verloren. Aber das passiert nicht. Jedes WIN fuhrwerkt willkürlich herum, will CHKDSk auf vom anderen für korrekt befundene oder gar mit CHKDSK geprüften LWs auslösen.
Das hat überhaupt nichts damit zu tun was CHKDSK selbst betreibt wenn es aufgerufen wird - das Problem ist, dass es völlig planlos und willkürlich aufgerufen wird (beim Booten)

Du siehst dir nicht das Ergebnis (Protokoll) an, sondern willst über Sinn/Unsinn/technische Hintergründe von chkdsk diskutieren. Den Gedanken, dass das Dateisystem und/oder die Platte defekt sind, willst du nicht wahrhaben.

Selten so was erlebt was am Ziel vorbeigeht. Das Ziel ist einen Absatz weiter oben beschreiben.
Wenn, falls du wirklich den Thread verfolgt hättest, ein beschädigtes Dateisystem einer Platte vorliegt und jedes WIN dieses, und nur und genau dieses, geprüft hätte wärest du im Recht…
→ eben ist eine andere,mir als kritisch bekannte, Platte (an USB) zu heiß geworden und hat blockiert. Da ist jetzt CHKDSK fällig. Und nur dort. Ich plane die Platte auszunutzen bis sie endgültig tot ist.
…aber genau dieser wichtige Punkt , der Einigkeit, dass ein Schaden vorliegt, ist nicht gegeben. Dafür wurden LWs (nicht: Platten!) geprüft bei denen kein Grund dafür erkennbar wäre, z.B. mitlaufende Backupplatten ohne jeden aktuellen Zugriff.

Wenn die Platten 4-8 Jahre alt, gönne dir 1 oder 2 neue (S-ATA-)Platten, dann tauschst du etwas Geld gegen viel Zeit, Datensicherheit, mehr Geschwindigkeit usw. ein:

Tja… Das ist im Kern schon richtig… Allerdings geht es hier mehr um ein redundantes Backup (mehrfaches Backup) und nicht ums Tempo, die OS-Platte ist SATA und neu [obwohl genau deren Vorgänger in der Garantiezeit die Grätsche machte während alles Ältere noch brav läuft..!]
Da es ein wenig im Beutel kneift werde ich eine solche Aktion vor mir herschieben bis es nicht anders geht. Kann halt nichts was noch ordentlich arbeitet einfach so wegwerfen

Ein gutes Geschäft. Das Herumfuhrwerken mit alten, angeschlagenen Platten ist sinnlos.

Wüsste ich, dass »die Kuh nur noch auf 3 Zitzen läuft« käme sie zum Abdecker. Im Moment sagt sie immer noch brav Muh und futtert ihr Gras. Also lassen wir sie.
Warum der Tierarzt aber mal die Kuh und dee nächste Doc ein anderes Rind gegen irgendwelche Bazillen impft - das ist das große Rätsel… Sind die Doktores am Ende selbst Rindviehcher?

CN8

 

[Ernst@at]

Ich hab mir jetzt nicht das ganze Gesülze durchgelesen, aber an der Zeile blieb mein Blick hängen und die Haare haben sich gesträubt...

Allerdings setze ich dieses Betriebssystem #1 in den Ruhezustand um #2 über BIOS-Bootmenü zu starten.

Mpffff. Und noch wundern Dich musst? dirty-Bit ist nicht alles, es reicht, wenn #2 die $Logfile Einträge beim Filesystem-Mount verraten, dass von #1 das Filesystem nicht korrekt abgeschlossen wurde...

 

[areiland]

Ist mir auch aufgefallen, es ist immer schön vom Ruhezustand die Rede. Aber den Zusammenhang autochk - Ruhezustand hat der TE in der ganzen Zeit nicht erkannt.

 

[bu1137]

Eins vorweg: Habe nicht den ganzen Thread durchgelesen.

Hast du mal mit Autoruns beim Reiter "Boot Execute" geschaut? Dort dürfte der Aufruf vom chkdsk sein. Einfach mal löschen und freuen.

Edit: hier die genauere Anleitung. Du musst nicht einfach etwas löschen, sondern den autochk eintrag etwas abändern:

http://ask-leo.com/how_do_i_keep_chkdsk_from_running_on_every_start_up.html

 

[cumulonimbus8]

Den werde ich mir mal merken, für den Fall.

Allerdings ist die Frage immer noch die nach dem Warum. 4 WIN die 4 unterschiedliche Checks wollen - aus welchen Fingern saugen die sich das..?


Zwischenbemerkung: Ich habe gerade Zicken hier; aber der Eintrag ist auf »Neutral«. Seltsam.

CN8

 

[bu1137]

Der Punkt ist: Der Check wird vermutlich bedingungslos durchgeführt. Normalerweise wird der Boot Execute Eintrag nach erfolgreichem chkdsk wieder abgeändert. Ich hatte es jedoch auch schon mal so, dass dieser trotz keinerlei Probleme so blieb, und damit jedes mal ein chkdsk ausgelöst wurde.

 

[areiland]

Trotzdem Du die Festplatten per Bootmenü des Mainboards auswählst, Windows schaut sich alle Festplatten an und sieht dann natürlich, dass ein System nicht abgeschlossen wurde. Also geht es von einem inkonsistenten Dateisystem auf den Platten aus und stösst einen Autocheck an. Wenn Du die Festplatten dann vielleicht auch noch mounten lässt, sowieso.

 

[cumulonimbus8]

Ich kann dir nur sagen: so ist es nicht.

Klingt unlogisch, ist aber so. 2 abwechselnd gebootete WIN von 2 Platten im selben System benannten gleiche und andere logische LW als beschädigt.

Warum soll #2 das eben von #1 geprüfte Laufwerk XY als zu prüfend führen? Es war so!

CN8

 

[Ernst@at]

omg. Bist Du so selbstverliebt in Deine Ideen und felsenfest von Deiner Unfehlbarkeit überzeugt, dass Du jeden noch so zielführenden Hinweis wie ein nasser Hund abschüttelst, ohne darüber nachzudenken und ohne Deine Handlungen anzuzweifeln?

Ich versuchs bloss noch ein Mal:

Du bist auf die glorreiche Idee gekommen, mehrere XP-Systeme am gleichen Rechner als Multiboot-Variante anzulegen. Dann hattest Du die Erleuchtung, zur Zeitersparnis, um nicht jedesmal ein System runter- und ein anderes hochfahren zu müssen, an allen Systemen den Hibernate-Mode einzusetzen.
So genial die Idee klingt, das ist Schwachsinn.

Der Hibernate-Mode ist dazu ersonnen worden, um zur Energieeinsparung und sofortiger Wiederaufnahme der Arbeit aus dem Vorzustand EIN System einzufrieren und dann später dieses EINE System wiederzuerwecken.
Aber nicht dazu, das mit mehreren Systemen abwechselnd mit gleicher Peripherie(bzw gemeinsam genutzer Partitions) am selben Rechner zu veranstalten!
Beim Hibernate bleiben alle Filesystem-Handles offen und die im RAM residenten Filesystem-Teile(um nicht immer wieder drauf zugreifen zu müssen) werden wie auch sämtlicher anderer RAM-Inhalt im Hibernate-File abgebildet.

Auf den Platten ist auf jeder Partition, der ein Laufwerksbuchstabe zugeordnet wurde, im Filesystem die Information abgelegt, dass diese geöffnet und "in use" ist. Im Falle eines plötzlichen Stromausfalles oder Systemabsturzes muss beim Neustart überprüft werden, ob eine derartige Situation eingetreten ist.

Wenn das Filesystem nicht ordnungsgemäß abgeschlossen wurde, wird autochk angeleiert, um eventuell dadurch entstandene Inkonsistenzen zu beheben.
Zitat aus der XP-Literatur:
Windows XP can detect whether an incorrect shutdown or reset has occurred. If Windows XP detects an incorrect shutdown or reset, it starts the Autochk.exe file to correct any file system problems during the startup process.

Und genau das passiert, wenn Du System A in den Hibernate schickst und System B hochfährst. A hat das Filesystem nicht ordnungsgemäß geschlossen(und es ist scheissegal, ob da beim Starten von A ein chkdsk gelaufen ist), daher macht B autochk.
Darin liegt noch weiterer Sprengstoff - wenn Du später A wiedererweckst, hat B vielleicht auf dem Filesystem was geändert, was bei A im RAM aufgehoben wurde, womit dies dann die lustigsten Fehler im Dateisystem bis hin zum Totalverlust verursachen kann.

Tu mir bitte den Gefallen, und paste nicht gleich wieder die obigen Zeilen und schmier zeilenweise Deinen Senf dazu, sondern lies sie so lange immer und immer wieder, bis Du den Sinn erfasst hast und (vielleicht zum erstem Mal) Selbstzweifel verspürst.
Dann steht dem AHA-Effekt nichts mehr im Wege.

Wenn Du trotzdem nicht von dieser völlig ungeeigneten Methode, mehrere Systeme am Rechner zu betreiben, abzuhalten bist, dann mach einfach überall ein
chkntfs d: e: f: (...) /x
und sei glücklich, bis Dir irgendwelche Teile des Filesystemes um die Ohren fliegen.

zur Info:
Using the /x parameter to exclude volumes

Use the /x parameter to prevent Autochk from running on known dirty volumes. Use this parameter only as a temporary measure. For example, when you know the volume is dirty, use the /x parameter to postpone running Autochk until a period of low computer activity, such as nights or weekends.

The /x parameter is not cumulative. Each time you use the /x parameter, you override the previous entry. For example, typing chkntfs e: /x, followed by chkntfs f: /x, excludes only the F volume from being checked.

To exclude multiple volumes, list them all in one command. For example, to exclude both the E and F volumes, type:

chkntfs e: f: /x

(Nachtrag, aus einem anderen Thema des TE hiezu) "Und lehrreich, aber das kommt nicht an: 4 WIN die 4 unterschiedliche Dirty-Bit-Zustände kennen lassen nur den Schluss zu, dass da ganz anderswo was faul ist, nur nicht an den Platten."
Lehrreich? Bloss die Frage, für wen. Faul? Vollig richtig. Vor dem Bildschirm.

 

[cumulonimbus8]

omg. Bist Du so selbstverliebt in Deine Ideen und felsenfest von Deiner Unfehlbarkeit überzeugt, dass Du jeden noch so zielführenden Hinweis wie ein nasser Hund abschüttelst, ohne darüber nachzudenken und ohne Deine Handlungen anzuzweifeln?
Wenn man den Thread gelesen hätte würde man einem TO nicht so eine Klatsche verpassen.

Du bist auf die glorreiche Idee gekommen, mehrere XP-Systeme am gleichen Rechner als Multiboot-Variante anzulegen.
Was ist deiner Meinung nach Multiboot? Für mich: ein Bootmanager ist nötig.
Tatsächlich sind das 4 völlig autarke XPs auf 4 völlig autarken Platten. Wenn ich auch die Boot.Ini's verwenden kann - ich wähle das BIOS-Bootmenü.

Dann hattest Du die Erleuchtung, zur Zeitersparnis, um nicht jedesmal ein System runter- und ein anderes hochfahren zu müssen, an allen Systemen den Hibernate-Mode einzusetzen.
:O Wo hast du das bitte her? Davon war nie die Rede.

So genial die Idee klingt, das ist Schwachsinn.
Aha. Aber dazu nach dem kommenden Absatz mehr.

Der Hibernate-Mode ist dazu ersonnen worden, um zur Energieeinsparung und sofortiger Wiederaufnahme der Arbeit aus dem Vorzustand EIN System einzufrieren und dann später dieses EINE System wiederzuerwecken.
Jedem anderen XP geht es am A. vorbei was das andere macht, ob es runtergefahren wurde oder Winterschlaf hält. Es muss dies sogar - oder warum sollte das eine das andere beeinflussen?

Aber nicht dazu, das mit mehreren Systemen abwechselnd mit gleicher Peripherie(bzw gemeinsam genutzer Partitions) am selben Rechner zu veranstalten!
Tat ich nie. Und dmait du beruhigt bist: als ich 1 XP in Winterschalf versetze und ein andere per BIOS startete tat sich nichts. Mehrmals. Zwischen heruntergefahrenen hingegne passierte es…

Beim Hibernate bleiben alle Filesystem-Handles offen und die im RAM residenten Filesystem-Teile(um nicht immer wieder drauf zugreifen zu müssen) werden wie auch sämtlicher anderer RAM-Inhalt im Hibernate-File abgebildet.
Von was ist hier die Rede - Caching im RAM? Des FileTables? Dann wäre es wenigsten eine Erklärung.

Auf den Platten ist auf jeder Partition, der ein Laufwerksbuchstabe zugeordnet wurde, im Filesystem die Information abgelegt, dass diese geöffnet und "in use" ist. Im Falle eines plötzlichen Stromausfalles oder Systemabsturzes muss beim Neustart überprüft werden, ob eine derartige Situation eingetreten ist.
OK. Ist ja sinnvoll so. Und völlig neu…

Wenn das Filesystem nicht ordnungsgemäß abgeschlossen wurde, wird autochk angeleiert, um eventuell dadurch entstandene Inkonsistenzen zu beheben.
Zitat aus der XP-Literatur:
Windows XP can detect whether an incorrect shutdown or reset has occurred. If Windows XP detects an incorrect shutdown or reset, it starts the Autochk.exe file to correct any file system problems during the startup process.
Welche Literatur, wo?

Und genau das passiert, wenn Du System A in den Hibernate schickst und System B hochfährst. A hat das Filesystem nicht ordnungsgemäß geschlossen(und es ist scheissegal, ob da beim Starten von A ein chkdsk gelaufen ist), daher macht B autochk.
Darin liegt noch weiterer Sprengstoff - wenn Du später A wiedererweckst, hat B vielleicht auf dem Filesystem was geändert, was bei A im RAM aufgehoben wurde, womit dies dann die lustigsten Fehler im Dateisystem bis hin zum Totalverlust verursachen kann.
Die Verteilung von A und B da oben erscheint mir eigenartig.
Und was ein InUse hieße oder nicht… Es gibt Laufwerke auf die alle 4 WIN zugreifen um sich bestimmte Ressourcen zu holen. Also müsstne explizit immer diese ›gemeinsamen‹ Laufwerke negativ auffallen. Wäre dem so hätte ich diese Regle erkannt. Aber es war durcheinander. Wie erklärst du nun das?

Tu mir bitte den Gefallen, und paste nicht gleich wieder die obigen Zeilen und schmier zeilenweise Deinen Senf dazu,
Ohne dies kann keiner mitlesen und geriete aus dem Zusammenhang.
Außerdem bin ich glaub' ich der TO - also muss ich wohl meinen Senf zu Antworten zugeben, oder nicht? Wenn nein hätte du genauso handeln sollen.

sondern lies sie so lange immer und immer wieder, bis Du den Sinn erfasst hast und (vielleicht zum erstem Mal) Selbstzweifel verspürst.
Dann steht dem AHA-Effekt nichts mehr im Wege.
Ich will nicht streiten… Ich habe ein Problem, stelle Fragen dazu ein und werde gebügelt satt aufgeklärt. Wie nett.

Wenn Du trotzdem nicht von dieser völlig ungeeigneten Methode, mehrere Systeme am Rechner zu betreiben, abzuhalten bist, dann mach einfach überall ein
chkntfs d: e: f: (...) /x
und sei glücklich, bis Dir irgendwelche Teile des Filesystemes um die Ohren fliegen.
Stell dir vor - ich weiß was das tut. Erkläre mal andere was ich mir damit ins Knie schießen würde und warum das die Lösung ist

Und nun extra für dich ganz laut:
Ich würde nicht so eine Frage vom Stapel treten wenn dieses Problem mich seit 4 Jahren, seit es diese Konstellation gibt, verfolgte. Es ist erst Monate alt!
Also verzichte bitte darauf mich hier als Volltrottel hinzustellen.

(Nachtrag, aus einem anderen Thema des TE hiezu) "Und lehrreich, aber das kommt nicht an: 4 WIN die 4 unterschiedliche Dirty-Bit-Zustände kennen lassen nur den Schluss zu, dass da ganz anderswo was faul ist, nur nicht an den Platten."
Lehrreich? Bloss die Frage, für wen. Faul? Vollig richtig. Vor dem Bildschirm.

Was hat das alles da oben mit DirtyBits zu tun?
Offenbar ist nach o.g. Erklärung wo anders was faul. Oder könnte es sein. Das kürzliche Auftreten erklärt es nicht…

CN8

 

[Ernst@at]

Wenn man den Thread gelesen hätte würde man einem TO nicht so eine Klatsche verpassen.
Das hab ich vor meiner zweiten Wortmeldung genauer als Dir lieb sein wird. Nachdem Du anderen Postern gegenüber auch nicht zimperlich bist, agiere ich da nach dem Grundsatz "Wie es aus dem Wald schallt, klatscht es zurück".

Ohne dies kann keiner mitlesen und geriete aus dem Zusammenhang.
Außerdem bin ich glaub' ich der TO - also muss ich wohl meinen Senf zu Antworten zugeben, oder nicht? Wenn nein hätte du genauso handeln sollen.
Es geht nicht darum, sondern um Deine Eigenart, alles und jedes zu zerpflücken und ad absurdum führen zu wollen, nur weil Du anscheinend glaubst, es besser zu wissen.
Da stellt man sich dann die Frage, wozu Du überhaupt hier postest, wenn Du ohnehin keine anderen Meinungen akzeptieren willst. Nicht nur mir kommt dies zumindest so vor.
Wenn Du was nicht verstehst, wäre hinterfragen die richtige Taktik, nicht Abwehr. Damit ist keine Problemlösung zu finden.
Im Gegenteil, das macht es für Andere mit guten Ideen so mühsam, dass sie es lieber bleiben lassen.

Beispiel 1:
Ich: Dann hattest Du die Erleuchtung, zur Zeitersparnis, um nicht jedesmal ein System runter- und ein anderes hochfahren zu müssen, an allen Systemen den Hibernate-Mode einzusetzen.
Du: :O Wo hast du das bitte her? Davon war nie die Rede.
Ich: Der Hibernate-Mode ist dazu ersonnen worden, um zur Energieeinsparung und sofortiger Wiederaufnahme der Arbeit aus dem Vorzustand EIN System einzufrieren und dann später dieses EINE System wiederzuerwecken.
Du: Jedem anderen XP geht es am A. vorbei was das andere macht, ob es runtergefahren wurde oder Winterschlaf hält. Es muss dies sogar - oder warum sollte das eine das andere beeinflussen?

Mit ein bisschen konstruktiver Intelligenz würdest Du erst mal nachdenken, was da steht, und vielleicht Deine falschen Vorstellungen in Zweifel ziehen.
Wenn ich 4 XP Systeme an 4 Rechnern laufen lasse, dann kann ich problemlos die Partition eines Systemen von den anderen benutzen, soferne das Sharing dafür freigegeben ist. Dann hat aber das System, welches die Resource für andere freigibt, trotzdem die Hoheit über die Zugriffe auf dieses Filesystem und kann mit Lock-Mechanismen ausschließen, dass da Unsinn passiert, wenn mehrere Systeme gleichzeitig auf irgendeinen Teil davon zugreifen.
Wenn ich aber an einem Rechner mit 4 Systempartitions ein System in den Schlaf schicke und ein anderes System starte oder fortsetze, weiß keines vom Anderen, weil jedes diese Ressoursen als exklusiv im Zugriff meint.
Das einzige, was hier am A. vorbei geht, sind Dir anderslautende Antworten, die nicht in Dein höchst mangelhaftes IT-Verständnis passen.

Es mag zwar meine globale Vermutung "an allen Systemen" nicht zutreffen, aber selbst unter der Einschränkung "auf mindestens einem" geht es lustig weiter
Ich: Aber nicht dazu, das mit mehreren Systemen abwechselnd mit gleicher Peripherie(bzw gemeinsam genutzer Partitions) am selben Rechner zu veranstalten!
Du: Tat ich nie.

wo Du aber im Post #1 bekanntgibst:
Normalerweise nutze ich die Boot.Ini der Platte an BIOS-Position #1, nichtsdestoweniger sind alle Platten autark und ich kann sie übers BIOS-BootMenü anwählen. Das nutze ich allgemein dann, wenn #1 in den Ruhezustand versetzt wurde und mir deswegen das Menü der Boot.Ini nicht angeboten wird (F8 muss nicht sein).
und im Post #13
Vom ersten Windows aus, nun wieder DityBits sind gesetzt (aus Ruhezustand),
und im Post #15
Allerdings setze ich dieses Betriebssystem #1 in den Ruhezustand um #2 über BIOS-Bootmenü zu starten.
Das hätte jetzt schon Erklärungsbedarf, finde ich...

Beispiel 2:
Ich: Zitat aus der XP-Literatur:
Windows XP can detect whether an incorrect shutdown or reset has occurred. If Windows XP detects an incorrect shutdown or reset, it starts the Autochk.exe file to correct any file system problems during the startup process.
Du: Welche Literatur, wo?
Wenn du so taff wärst, wie Du Dich selbst einschätzt, hätte ein Google nach diesem Zitat(unter " gesetzt) genau 2 Hits gebracht - beide aus Microsoft Quellen...

Was ist deiner Meinung nach Multiboot? Für mich: ein Bootmanager ist nötig.
Tatsächlich sind das 4 völlig autarke XPs auf 4 völlig autarken Platten. Wenn ich auch die Boot.Ini's verwenden kann - ich wähle das BIOS-Bootmenü.
Ich kaue da bloss das Glossar von MS, und habe dazu keine Meinung.
Dort wird das vorhandensein von zwei Systemen an einem Rechner als "dual-boot" und von mehreren als "multi(ple)-boot Konfiguration bezeichnet.
Völlig egal, ob das per BIOS von der aktiven Partition oder per Bootmanager, der ohnehin immer (auch bei nur einem System) abläuft.

Es gibt Laufwerke auf die alle 4 WIN zugreifen um sich bestimmte Ressourcen zu holen. Also müsstne explizit immer diese ›gemeinsamen‹ Laufwerke negativ auffallen. Wäre dem so hätte ich diese Regle erkannt. Aber es war durcheinander. Wie erklärst du nun das?
Wie willst Du eine Regel erkennen, wenn Du keine Ahnung hast, was jeweils nach dem Filesystem-mount auf jeder Partition genau abgelaufen ist und dann zu Inkonsistenz geführt haben könnte? AUch andere Software(AV, Backup, Defrag, ...) kann eine Datenträgerüberprüfung nach reboot triggern.

(zu chkntfs /x) Stell dir vor - ich weiß was das tut. Erkläre mal andere was ich mir damit ins Knie schießen würde und warum das die Lösung ist
Auf dieser grammatikalische Missgeburt lässt sich keine Antwort formulieren.

Ich würde nicht so eine Frage vom Stapel treten wenn dieses Problem mich seit 4 Jahren, seit es diese Konstellation gibt, verfolgte. Es ist erst Monate alt!
Also verzichte bitte darauf mich hier als Volltrottel hinzustellen.
Erst nachdem man die derzeitige Ursache eindeutig festgestellt hat, kann man vielleicht auch Vermutungen darüber anstellen, warum das plötzlich aus dem Gleichgewicht geraten ist und
wodurch das Ringelspiel sich zu drehen begonnen hat: Ein MS-Update? Eine Applikationsänderung, wodurch sich die Art der Filezugriffe geändert hat? Ein Hardwarefehler, der eine Inkonsistenz hervorrief, die einen MS-Fehler aktiviert hat?

Ich würde an Deiner Stelle (als selbsternannter IT-Experte ) ohne dieses endlose Gelaber folgendermaßen vorgehen, um dem seltsamen Problem auf die Schliche zu kommen:
- alle 4 Systeme (ohne auch nur an Hibernate zu denken) 1x hoch- und wieder ordnungsgemäß runterfahren
- an jedem System alle mit einem Laufwerksbuchstaben oder Mountpoint beglückten Partitions feststellen
nach jedem Shutdown eines Systemes
- an allen Partitions offline den Status des dirty-flags im $Volume Metafile der $MFT feststellen
- an allen Partitions offline Pointer des ersten und zweiten Eintrags des $Logfile auf Gleichheit überprüfen(= Filesystem ordnungsgemäß abgeschlossen)
- an jeder Systempartition offline die Registry-Einträge für autochk unter BootExecute erheben.
(offline= durch ein 5. System, welches nur die 4 Systempartitions mit Laufwerksbuchstaben zuordnet und daher auch zum Inspizieren der fremden Registry öffnet, alle anderen Partitions nicht zugeordnet!)

Damit wäre ein Grundstein gelegt, um das Problem als Eigenverschulden oder MS-Fehler einordnen zu können, wenn danach irgendeines der Systeme bei hochfahren wieder chkdsk-Allüren zeigt (und wieder ordnungsgemäß runtergefahren wird, bevor ein anderes gestartet wird)

 

[Roderic]

Kriegt euch mal alle wieder ein!
Wie wärs mal zur Beruhigung mit der eigentlichen Frage:

1. dirtyBit im MBR
2. Registry RunOnce
3. in der MasterFileTable des NTFS werden Sektoren als BAD markiert, wenn der Platte die Reservesektoren ausgegangen sind und deswegen die Plattenelektronik Schreibfehler nicht mehr abfangen kann
4. S.M.A.R.T. Werte jenseits der zulässigen Werte.
5. wenn Windows feststellt, daß seine Systempartition plötzlich eine andere SID hat. z.B. nach einem Vertauschen der Buskabel
6. Fehler im IDE Treiber
7. ...
8. ..
9. .

 

[cumulonimbus8]

• dirtyBit im MBR
2 WIN, 2 Meinungen. Wäre ja zu schön wenn Einigkeit bestünde.

• Registry RunOnce
Was lasse ich da bitte einmalig runnen? CheckDisk?

• in der MasterFileTable des NTFS werden Sektoren als BAD markiert, wenn der Platte die Reservesektoren ausgegangen sind und deswegen die Plattenelektronik Schreibfehler nicht mehr abfangen kann
Yepp. Aber keine Information würde darauf hindeuten, dass dies in Frage käme; und dann bei 4 Platten gleichzeitig?
• S.M.A.R.T. Werte jenseits der zulässigen Werte.
Eine Platte ist nicht mehr die Frischeste, das weiß ich auch. Aber noch hats keine Rauchzeichen gegeben.
• wenn Windows feststellt, daß seine Systempartition plötzlich eine andere SID hat. z.B. nach einem Vertauschen der Buskabel
Hatte ich nicht dran rumgespielt.
•Fehler im IDE Treiber
Gleich2 bis4 Mal?

• ... | .. | .
Gäbe es eine Regel(mäßigkeit) würde ich 3 † machen.



@ Ernst@at
Ich möchte dir einfach nur 2 Zitate aus meien Postings anbieten:

Aber: Die To-Check-Listen bieder waren z.T. unterschiedlich. Selbst als ich im Haupt-XP für eine bestimmte Partition CHKDSK /R /F auslöste (was selbst direkt durchgeführt werden konnte) wurde dieses logische LW vom Spezial-XP als behandlungswürdig deklariert.

Nun noch mal zur Klarheit: Wir haben es hier mit Computern zu tun. Mit Bits und Byte, Null und Eins. Demnach müsste es konsequent logisch sein, dass jegliches Betriebssystem Fehlerzustände auf Platten (DirtyBits) immer identisch erkennt und drauf reagiert.
Genau das aber ist nicht passiert! Warum? Wo ist die Logik? Das würde ich gerne wissen!


Auf diese bescheidene Kernelemente geht du nicht ein. Und auch nicht auf…
Ich würde nicht so eine Frage vom Stapel treten wenn dieses Problem mich seit 4 Jahren, seit es diese Konstellation gibt, verfolgte. Es ist erst Monate alt!

Auf deine netten Titulierungen wie…
•«"Wie es aus dem Wald schallt, klatscht es zurück"»
• «Da stellt man sich dann die Frage, wozu Du überhaupt hier postest, wenn Du ohnehin keine anderen Meinungen akzeptieren willst. »
• «Mit ein bisschen konstruktiver Intelligenz würdest Du erst mal nachdenken, was da steht, und vielleicht Deine falschen Vorstellungen in Zweifel ziehen.»
• «Auf dieser grammatikalische Missgeburt lässt sich keine Antwort formulieren.»
• «Ich würde an Deiner Stelle (als selbsternannter IT-Experte )»
…kann ich verzichten.
Du bist schlauer als alle hier die posten, dir ist egal was man gelernt hat und wie viele Erfahrungen (mit seinem eigenen System) hat.

«Ich hab mir jetzt nicht das ganze Gesülze durchgelesen, aber an der Zeile blieb mein Blick hängen und die Haare haben sich gesträubt...»
Ich steh nicht auf Beleidigungen und noch weniger drauf Breitseiten zu bekommen wenn man nicht mal meint alle nötigen Infos zu holen… Vielen Dank.

CN8

 

[Ernst@at]

@ Ernst@at
Ich möchte dir einfach nur 2 Zitate aus meien Postings anbieten:
(1)
(2)
Auf diese bescheidene Kernelemente geht du nicht ein. Und auch nicht auf…
(3)

Würdest Du statt abzuwägen, was Du per copy&paste zusammentragen sollst, weil es an Deinem Ego kratzt, lieber die restlichen dazwischenstehenden 95% an Information versuchen zu verstehen, dann hättest Du das Problem vielleicht schon lösen oder zumindest eingrenzen können.

zu (1) "Aber: Die To-Check-Listen bieder waren z.T. unterschiedlich. Selbst als ich im Haupt-XP für eine bestimmte Partition CHKDSK /R /F auslöste (was selbst direkt durchgeführt werden konnte) wurde dieses logische LW vom Spezial-XP als behandlungswürdig deklariert."
hab ich geschrieben
Post#22: "dirty-Bit ist nicht alles, es reicht, wenn #2 die $Logfile Einträge beim Filesystem-Mount verraten, dass von #1 das Filesystem nicht korrekt abgeschlossen wurde..."
Post#31: "Wenn ich aber an einem Rechner mit 4 Systempartitions ein System in den Schlaf schicke und ein anderes System starte oder fortsetze, weiß keines vom Anderen, weil jedes diese Ressourcen als exklusiv im Zugriff meint."
Post#29: "Wenn das Filesystem nicht ordnungsgemäß abgeschlossen wurde, wird autochk angeleiert, um eventuell dadurch entstandene Inkonsistenzen zu beheben."
Post#31: "Und genau das passiert, wenn Du System A in den Hibernate schickst und System B hochfährst. A hat das Filesystem nicht ordnungsgemäß geschlossen(und es ist scheissegal, ob da beim Starten von A ein chkdsk gelaufen ist), daher macht B autochk."
Post#31: "Wie willst Du eine Regel erkennen, wenn Du keine Ahnung hast, was jeweils nach dem Filesystem-mount auf jeder Partition genau abgelaufen ist und dann zu Inkonsistenz geführt haben könnte? AUch andere Software(AV, Backup, Defrag, ...) kann eine Datenträgerüberprüfung nach reboot triggern."

zu (3) "Ich würde nicht so eine Frage vom Stapel treten wenn dieses Problem mich seit 4 Jahren, seit es diese Konstellation gibt, verfolgte. Es ist erst Monate alt!"
Post#31: "Erst nachdem man die derzeitige Ursache eindeutig festgestellt hat, kann man vielleicht auch Vermutungen darüber anstellen, warum das plötzlich aus dem Gleichgewicht geraten ist und wodurch das Ringelspiel sich zu drehen begonnen hat: Ein MS-Update? Eine Applikationsänderung, wodurch sich die Art der Filezugriffe geändert hat? Ein Hardwarefehler, der eine Inkonsistenz hervorrief, die einen MS-Fehler aktiviert hat?"

zu (2) "Nun noch mal zur Klarheit: Wir haben es hier mit Computern zu tun. Mit Bits und Byte, Null und Eins. Demnach müsste es konsequent logisch sein, dass jegliches Betriebssystem Fehlerzustände auf Platten (DirtyBits) immer identisch erkennt und drauf reagiert.
Genau das aber ist nicht passiert! Warum? Wo ist die Logik? Das würde ich gerne wissen!"
Wenn Du nach so vielen Jahren IT-Erfahrung noch nicht mitgekriegt haben solltest, dass es außer einem Bit an irgendeiner Stelle, noch was Anderes gibt, was überhaupt nicht logisch und fehlerfrei agieren muss, dann tust Du mir leid:
Ein Programm kann in Abhängigkeit von vielen anderen Faktoren oder Zufällen machen, was es will - egal ob das Bit jetzt gesetzt ist oder nicht.

Ein chkdsk eines Volumes wird zum Windows-Start dann ausgeführt

• wenn es explizit(zB von einer Applikation) per Registry /RunOnce angegeben wurde

• wenn in der Registry unter BootExecute autochk angeführt ist
  UND das Volume in der Registry /MountedDevices einen Buchstaben zugewiesen hat und in der Hardware-Konfiguration enthalten ist
  UND
  - Dieses Volume nicht in der Exclude/Skip Liste angeführt ist UND das Dirty-flag im $Volume gesetzt hat
  oder
  - Dieses Volume in der Liste der unbedingt zu Überprüfenden angeführt ist
  oder
  - Filesystemoperationen dieses Volumes nicht ordnungsgemäß abgeschlossen wurden ($Logfile Inkonsistenz)

Statt nun einfach an den richtigen Stellen nach der tatsächlichen Ursache zu forschen(deren Anleitung auch im Post#31 zu finden ist), werden lieber teils sehr unsinnige Gedanken gewälzt:
dirty Bit im MBR? Im MBR befinden sich bloß Einträge für primäre Partitions, wo wäre das dann für die Logischen? Außerdem stehen je Partition nur 16 Bytes zur Verfügung, und da ist nirgendwo Platz dafür.
in der MasterFileTable des NTFS werden Sektoren als BAD markiert, wenn der Platte die Reservesektoren ausgegangen sind Ob die als BAD aus dem Verkehr gezogen wurden, hat mit Reservesektoren nichts zu tun.
S.M.A.R.T. Werte jenseits der zulässigen Werte. Inkonsistenz des Filesystems wegen Plattenfehler hat nichts mit den SMART-Werten zu tun.
Vertauschen der Buskabel hat keinen Einfluss, weil Win sich an den in der Registry vergebenen GUIDs für jede Partition orientiert.
Fehler im IDE Treiber ja klar, oder des Controllers, des RAM, der CPU, des Netzteils...

 

[cumulonimbus8]

Ich verzichte nunmehr auf deine Antworten.

Du sitzt nicht davor, du erlebst es nicht und du stellst mich für zu blöd hin nach so ungefähr 30 Jahren mit Computern nicht zu wissen was ich an Realitäten sehe und was ich nicht sehe.
Wenn du die Infos die ich nach bestem Gewissen gebe nicht wahrnehmen und darauf reagieren willst lasse es doch bitte ganz bleiben.

CN8

 

[Ernst@at]

Die spärlichen Informationen, die Du hier zum Besten gabst, enden ja alle im hilflosen Schlusssatz: "Ich kann keine Regel erkennen"
Nachdem ich hier alle Möglichkeiten aufgezeigt habe, welche eine Überprüfung anleiern könnten, wäre damit jeder Dummkopf in der Lage, die alle abzuprüfen um die Ursache rauszufinden.
Das aber tust Du nicht, sondern forderst, dass jeder in Deine krause Logik einsteigt, welche bisher bloss in eine Sackgasse geführt hat.

Ich bin leider auch nicht die geeignete Person, Deine fragwürdigen Erfahrungen anzuhimmeln.
Liegt wahrscheinlich daran, dass ich 10 Jahre länger im IT-Geschäft unterwegs bin und mich fast ausschließlich mit der Suche nach Fehlern Anderer und Lösung von Problemen beschäftigt habe...
Dass Du die Realität mindestens doppelt sehen kannst - da kann und will ich nicht mithalten.
Die Erkenntnis, wo in Deinem Fall der Wurm steckt, hätte meinen Erfahrungsschatz nur unwesentlich bereichert, damit kann ich weiterleben. Du musst es aber mit Deinem Problem.

 

[cumulonimbus8]

Die spärlichen Informationen, die Du hier zum Besten gabst, enden ja alle im hilflosen Schlusssatz: "Ich kann keine Regel erkennen"

Beachte doch bitte dein Posting #22. Ich kann leider nichts dafür, dass du nicht mitliest um dich aller Informationen zu bedienen.

Nachdem ich hier alle Möglichkeiten aufgezeigt habe, welche eine Überprüfung anleiern könnten, wäre damit jeder Dummkopf in der Lage, die alle abzuprüfen um die Ursache rauszufinden.

Vielen Dank.

Du hast immer noch nicht verstanden, dass alle deine Vorschläge beim besten Willen deshalb nicht umsetzbar sind weil du das einfache Faktum ignorierst, dass eben keine Regel zu erkennen ist. Ich kann 100 Möglichkeiten ausschließen die nicht reproduzierbar sind / die sich nicht reproduzieren - und mein Problem bleibt doch.

Ich bin leider auch nicht die geeignete Person, Deine fragwürdigen Erfahrungen anzuhimmeln.
Liegt wahrscheinlich daran, dass ich 10 Jahre länger im IT-Geschäft unterwegs bin und mich fast ausschließlich mit der Suche nach Fehlern Anderer und Lösung von Problemen beschäftigt habe. […]
Du musst es aber mit Deinem Problem.

Lies dir dies bitte selbst noch mal durch.
Würdest du einen Klempner bei einem tropfenden Boiler um Hilfe bitten der so denkt?


Alle weiteren Leser sind gerne eingeladen Vorschläge zu machen.
Sind Erfahrungen zur Hardware (Controller, Kabel…) bekannt die solche Nebenwirkungen haben?

CN8

 

[fischi1305]

Glaube nicht, das sich hier einer noch ein klinkt,denn Ernst@at hat es dir doch ausführlich beschrieben,so das ich es auch verstanden habe-

Und solche langen Texte schreiben hält auch viele zurück diese zu lesen -

 

[cumulonimbus8]

Für die Längen (ich hätte ja nicht alles ausführlich erklärt) kann ich nichts.

Weiterhin habe ich Möglichkeiten gelesen, aber keinen konkreten Treffer der - das ist eben das Problem - meine Merkwürdigkeiten abbildet.
Wäre das direkt reproduzierbar wäre das zu schön…

CN8

 

[Ernst@at]

Inzwischen ist man auch noch bei Win8 auf den gleichartigen Fehler aufmerksam geworden, den ich hier ausführlichst, aber ohne Erfolg, breitgetreten habe. Beim Mounten einer Partition in einem anderen System wird in jedem Fall auf den Logfile geschrieben, was dann ein anderes System irritiert und eine Überprüfung zur Folge haben kann.
Zitat daraus:

Fährt der Rechner mit aktiviertem FastBoot in den Schlafmodus, wird auch ein Abbild des aktuellen Zustands des Dateisystems in der Datei hiberfil.sys festgehalten. NTFS-3G sieht aber nur bei Zugriff auf die Systempartition, dass Windows nicht komplett heruntergefahren ist. Bei Datenpartitionen wird der Zustand nicht erkannt und der Treiber greift unter Umständen schreibend auf das Dateisystem zu. Windows 8 sieht aber später beim Aufwachen die veränderten Daten nicht und arbeitet mit dem vorher gespeicherten Zustand des Dateisystems. Hier ist Datenverlust vorprogrammiert. Nach einem vollständigen Neustart des Systems werden die veränderten Daten dann sichtbar, sind aber meist beschädigt.