Ereignisprotokoll, Disk, Fehler-ID 34 "Der Treiber hat den Schreibcache deaktiviert"

[J.B. 10]

Hallo Members, Hallo Mods, Hallo Admins!

 

Ich habe mich in den letzten Tagen fast totgegoogelt und Myriaden von MS-Bulletins durchstöbert, nun hab ich mich hier angemeldet um euch um Hilfe zu bitten.

 

Zu mir: ich bin trotz fortgeschrittenen Alters nur ein kleiner selbsständiger Supporter für Hard- und Software-Lösungen im Gastronomie-Bereich und beschäftige mich sowohl mit diesem Kundenkreis als auch einer wilden Mischung von Speziallösungen seit den seligen CP/M-Zeiten. Seit es Windows gibt hab ich auch keine Zeit für andere Hobbys mehr... :shock:

 

 

Seit Wochen nervt mich und meine Kunden ein Problem, das nur bei vernetzten Systemen auftritt (verschweigen wir mal die Namen der beteiligten Hersteller, die können imho nix dafür):

 

Man nehme 2 über minimales TCP/IP-Protokoll vernetzte Rechner mit relativ altem VIA Nehemiah-Prozessor, beide Win2000 SP4, dekativiere den Schreibcache der Festplatten und starte die schreibintensive Software. Nicht oft, aber oft genug blockiert dann die Anwendung mitten im Betrieb (wenn zB. Hochbetrieb ist) und läuft im günstigsten Fall nach einigen Minuten von selber wieder weiter oder versagt komplett.

 

Den Schreibcache zu deaktivieren war eine der Vorgaben des Herstellers, kann ich mir auch gut vorstellen, da zustandsabhängige Scheiboperationen vom 2.Rechner sofort erkannt werden müssen.

 

Nachdem ich mir mal das Ereignisprotokoll beider Systeme angeschaut habe ist mir aufgefallen, dass die einzigen Fehler

(Quelle "disk", Fehler-ID 34 "Der Treiber hat den Schreibcache deaktiviert")

zeitnah zu den Abstürzen bzw. Blockaden liegt. Seltsam, der Scheibcache ist ja sowieso deaktiviert...

Erstaunlich ist auch, dass heute der "Absturz" um ca. 15:55 war, der Fehlereintrag aber gegen 16:02 protokolliert wurde. Sieht also eher so aus, dass die Kasse zuerst blockiert hat, dann irgendwann der Cache vom System deaktiviert wurde. Was alle Ereignis-Protokollierungen gemeinsam haben ist der nachfolgende (manuell durchgeführte) Neustart des Rechners. Das liegt daran, dass im Hochbetrieb das Bedienungspersonal nicht erst lange abwarten will, ob sich das System wieder von selbst hochschaukelt. Also bestenfalls Alt-F4, schlimmstenfalls Reset.

 

Ich hoffe ich langweile euch nicht.

 

Meine Frage:

Was sagt der oben genannte Fehler im Ereignisprotokoll aus?

Braucht ihr noch mehr Informationen zur Hardware?

[J.B. 10]

Habe hier einen Thread mit gleichem Thema gefunden. Hier wird mutmasst, dass es Controller-/Plattentechnische Probleme sein könnten.

Bei meinen Systemen ist jeweils ein IDE-Controller mit 2,5" Fujitsu MHT2030AT installiert.

Alle Systeme, die ich ausliefere haben eines gemeinsam: Eine (eigentlich) vollkommen gleiche Win2000 Installation. Der Fehler tritt aber nur bei vernetzten Systemen auf. Stand-Alone Kisten laufen einwandfrei.

Also scheint bei Remote-Zugriff auf die Master-Platte irgendetwas kritisches zu passieren.

Das zu meiner Art der Logik. Aber was nutz Logik bei MS? Ich hätte Philosoph werden sollen... :D

 

Lieben Gruß, J.B.

 

PS: Wie kommt eigentlich die Rubrik "Ähnliche Themen" unterhalb des Threads zustande? Automatisch vom System generiert oder haben sich da User erbarmt und über die Suche einige Links eingegeben? Gute Sache das!

[edv-olaf 10]

Hallo und willkommen an Board,

 

was ich an deinem Posting nicht verstehe: warum möchtest du die Meldung erklärt haben, du selber hast doch den Cache über den Treiber deaktiviert!? Du weisst also selber am Besten, warum die Meldung kommt. Oder verstehe ich da jetzt was nicht?

 

Die Abstürze kommen vermutlich durch einen Lock auf die Datenbank oder einen Datensatz. Ein Rechner schreibt, die DB wird gelockt, ein anderer will lesen und wartet, weil schon gelockt. Kommt keine Antwort aus dem Netz für das Proggi, sieht es so aus, als ob Windows hängt. Ich tippe daher auf einen Programmierfehler in den Datenbank-Zugriffsroutinen.

 

Ansonsten mal die Platte der DB mit Herstellertools auf defekte Sektoren testen, falls es ein HW-Fehler sein sollte.

 

Grüße

Olaf

[J.B. 10]

Hallo Olaf, erstmal Danke für Deine Antwort.

...was ich an deinem Posting nicht verstehe: warum möchtest du die Meldung erklärt haben, du selber hast doch den Cache über den Treiber deaktiviert!? Du weisst also selber am Besten, warum die Meldung kommt. Oder verstehe ich da jetzt was nicht?

Also: Den Cache hab ich selber deaktiviert, stimmt schon soweit. Die Frage ist, warum kommt trotzdem immer bei den Abstürzen dies Meldung im Ereignisprotokoll als Fehler angezeigt. Ist das in diesem Fall als Hinweis zu interpretieren (dass er eben abgeschaltet sei) oder steh ich jetzt auf dem Schlauch?

 

Die Abstürze kommen vermutlich durch einen Lock auf die Datenbank oder einen Datensatz. Ein Rechner schreibt, die DB wird gelockt, ein anderer will lesen und wartet, weil schon gelockt. Kommt keine Antwort aus dem Netz für das Proggi, sieht es so aus, als ob Windows hängt. Ich tippe daher auf einen Programmierfehler in den Datenbank-Zugriffsroutinen.

Glaub ich eher nicht, da das Programm auf anderer Hardware und folglich auch anderer Windows-Grundinstallation weit über 700 Mal installiert ist und diese Programmabstürze dort nicht vorkommen. Es sieht eher so aus, als sei es ein Problem mit dem Windows-Image auf unserer Hardware. Einige Händlerkollegen haben mit der gleichen Hardware die selben Probleme. Alle haben die gleiche werksseitige Grundinstalltion von W2K.

 

Ansonsten mal die Platte der DB mit Herstellertools auf defekte Sektoren testen, falls es ein HW-Fehler sein sollte.

Das werde ich auf jeden Fall machen.

[edv-olaf 10]

Es sieht eher so aus, als sei es ein Problem mit dem Windows-Image auf unserer Hardware. Einige Händlerkollegen haben mit der gleichen Hardware die selben Probleme. Alle haben die gleiche werksseitige Grundinstalltion von W2K.

Mhh, ein Image-Problem? Habt ihr die SID nach dem Aufspielen geändert? Sonst glaubt der DB-Rechner, dass 2x dieselbe Workstation etwas anfordert und ist offensichtlich irritiert. Zum Stichwort SID-Ändern gibt es schon ein paar Beiträge im Board.

 

Sind die PCs in einer Domäne? Abmelden und neu in Domäne anmelden schon probiert?

 

Grüße

Olaf

[J.B. 10]

SID (IP-Adresse, Computernahmen, Arbeitsgruppe etc) werden natürlich pro Arbeitsstation individuell geändert. Ebenso die Einstellungen innerhalb der Anwendungssoftware wie Terminalnummer, Spoolpfade etc. Mit IMAGE meine ich also die Grundinstallation, die bei allen vom Hersteller ausgelieferten Systemen identisch ist und von mir dann kundenspezifisch angepasst wird.

Diese Mininetzwerke (2-3 Rechner) arbeiten nach dem Arbeitsgruppensystem, also keine Domainverwaltung.

[J.B. 10]

Sorry wenn ich das Thema nochmal ontop setze...

Bis jetzt noch der gleiche Fehler.

 

Hat noch jemand ne Idee?

[Das Urmel 10]

Muss ich nochwas nachfragen:

ein Rechner fungiert hier als Server.

Die Software arbeitet nach dem Client/Server Prinzip?

 

Die Meldung tritt an welchem Rechner auf.

Im Netzbetrieb hat die HD dann zwei Rechner zu bedienen, also läuft die Queue eher voll,

was ja auch logisch ist. Die Anwendungen laufen im Vordergrund? also Systemtechnisch gesehen, Systemleistungsoptionen.

Auf anderer Hardware passiert das nicht, also ist der Fehler im leistungschwachen Prozessor, oder anderen Komponenten zu suchen. Die Meldung ist imho ein Irrläufer, der Hänger kommt halt vom Schreiben der Daten - stockt und die Software muss warten. Disk mal beobachten - LED oder Monitor, Performancemonitor anwerfen.

Chipsatztreiber, RAM? mal paar Werte - sicher bloß 64Mbyte Speicher drin?

[J.B. 10]

Hallo Urmel, willkommen in meinem Verzweiflungsthread... ;)

Client/Server: YES. Meldung tritt abwechselnd am "Server" und am Client auf

Vordergrundanwendungen: YES

64MB? NO: 256! Speicherauslastung ca. 120-140 MB

Chipsatztreiber? Installiert: VIA 4in1, neueste Version passend zum Board aus dem Netz.

Leistungsschwacher Prozessor? Allerdings, das will ich meinen. Ein VIA-Nehemiah mit 700 MHz, was sicherlich auch ne nicht unwesentliche Rolle dabei spielt.

Andere Komponenten? Es spitz sich nach einigen Diskussionen offensichtlich auf ein Problem mit den eingesetzten Festplatten zu. Im Einsatz ist eine Fujitsu MHT2030AT 2,5" Platte (es handelt sich bei der Hardware um ein speziell als Gastronomiekasse designtes System mit integriertem Touchscreen, allses mögliche onboard und platzsparend gebaut) die lt. Aussagen von einigen Leuten eher in den Bereich "saubillig, also nehmen wir die" fällt.

 

Ich hab mir heute mal andere 2,5"er (Samsung MP0402H) geholt, die ich in Kürze gegen die Fujitsus austauschen werde.

 

Witzig ist nur, dass eine Bedienung, der ich das nebenher mal erklärt habe, gemeint hat:

"Mein Freund ist Informatiker ( klar, das sind ja auch die besten ;) ) und er hat vor 4-5 Monaten einen Samsung Laptop mit Fujitsu-HD gekauft. Seitdem hat er massenhaft Probleme mit der Platte gehabt und die HD wurde vom Werk gegen eine Samsung ausgetauscht. Seit dem hat er keine Probleme mehr."

 

Also warten wir mal ab.

[edv-olaf 10]

Im Einsatz ist eine Fujitsu MHT2030AT 2,5" Platte

Keine pauschale Abwertung gegen Fujitsu-HDs, aber habe bisher 4 Stück verbaut, alle vier innerhalb kurzer Zeit weggeraucht, also 100% Sch(w)und. (nicht repräsentativ ;))

 

Grüße

Olaf

[J.B. 10]

Das Gegenteil von cool dürften konstant abgerauchte Platten sein...

Ich werde auf jeden Fall mal meine Ergebnisse hier posten, auch wenn japanische Produktmanager damit dann ein Problem haben könnten.

[Das Urmel 10]

Die HD's sind nicht die beste Wahl, aber sonst - sollte die Kiste es schaffen -

es sei denn, die SW ist so umständlich geschrieben - dann bei schwächerer HW passierts dann auch. ;)