Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Rant] Warum redet Windows nicht Klartext?
627 views
Skip to first unread message
Michael Landenberger
Dec 30, 2011, 7:36:15 PM12/30/11
to
Hallo,
letztens fielen mir im Eventlog diverse Disk-Fehlermeldungen auf. Sie
lauteten alle wie folgt:
| Ereignistyp: Fehler
| Ereignisquelle: Disk
| Ereigniskategorie: Keine
| Ereigniskennung: 7
| Datum: 30.12.2011
| Zeit: 03:17:22
| Benutzer: Nicht zutreffend
| Computer: ATHLON64
| Beschreibung:
| Fehlerhafter Block bei Gerät \Device\Harddisk0\D.
| (...)
Ok, da haucht also ein Datenträger sein Leben aus. Aber welcher? Laufwerk D
ist ein DVD-ROM-Laufwerk. Dieses ist IDE-Master am 1. Onboard-IDE-Kanal (der
zweite ist im BIOS deaktiviert). "\Device\Harddisk0" interpretierte ich als
diesen ersten IDE-Kanal, wie sich später herausstellen sollte, lag ich damit
falsch. Weiterhin gibt es noch eine SATA-Festplatte (Laufwerk C:) als Master
am 1. Onboard-SATA-Controller, diese Platte ist die einzige Festplatte im
Rechner. Am gleichen Controller hängt als Slave ein SATA-DVD-Brenner
(Laufwerk E:). Der 2. Onboard-SATA-Controller ist ebenfalls deaktiviert.
Weiterhin ist noch ein USB-Cardreader im Rechner verbaut, dessen 4 Slots als
Laufwerke F: - I: eingerichtet sind. Mehr Datenträger gibt es in dem Rechner
nicht.
Was also ist \Device\Harddisk0\D? Ich hatte zuerst das DVD ROM-Laufwerk in
Verdacht, denn das war ja als Laufwerk D am ersten IDE-Controller
angeschlossen. Das war es aber nicht, denn nach Abklemmen des Laufwerks
tauchten die Fehlermeldungen immer noch im Eventlog auf. Dann fiel mir auf,
dass der USB-Cardreader zeitweise nicht von Windows erkannt wurde. Außerdem
fand ich im Netz Berichte, dass defekte Cardreader schon Ursache für die
erwähnte Fehlermeldung gewesen sein sollen. Also klemmte ich den Cardreader
ab, aber auch das hatte keinen Erfolg. Schließlich prüfte ich mit einem
Hersteller-Tool die Festplatte, und da waren sie, die kaputten Blocks.
Sehr ärgerlich finde ich es nun, dass im Eventlog-Eintrag ein irreführender
Hinweis auf die kaputte Platte auftaucht. Warum um alles in der Welt kann
Windows den Namen der Platte nicht im Klartext oder wenigstens den korrekten
Laufwerksbuchstaben dort eintragen?
Nachdem ich eine neue Platte eingebaut hatte, wollte ich Daten von der
defekten Platte auf die neue Platte kopieren. Die neue Platte schloss ich an
denselben SATA-Port an wie die alte. Zwecks Anschluss der alten Platte
aktivierte ich im BIOS den 2. Onboard-SATA-Controller und schloss die
Platte dort als Master an. Nun wurde sie als Laufwerk J: in das System
eingebunden (J war der erste freie Laufwerksbuchstabe). Natürlich tauchten
danach immer noch Fehlermeldungen im Eventlog auf, denn die Platte wies ja
immer noch defekte Blocks auf. Unsinnigerweise wurde in den Fehlermeldungen
aber immer noch hartnäckig auf \Device\Harddisk0\D hingewiesen, obwohl die
defekte Platte jetzt an einem ganz anderen Controller angeschlossen war. Ich
zweifelte schon am Erfolg des Festplattentauschs, aber das Hersteller-Tool
fand nach wie vor jede Menge Fehler auf der alten Platte, während die
(fabrik-)neue Ersatzplatte fehlerfrei war. Nachdem die alte Platte endgültig
aus dem Rechner ausgebaut war, gab es keine Fehlermeldungen mehr.
Wer sich diese blödsinnige Art ausgedacht hat, Fehler zu loggen, gehört IMHO
augenblicklich zum Sanitär-Reinigungspersonal strafversetzt.
Es wäre schön, wenn hier jemand eine Antwort auf die Frage wüsste, wie man
aus kryptischen Angaben wie "\Device\Harddisk0\D" das physikalische Gerät
bzw. die physikalische Partition ermitteln kann, auf die sich der
Eventlog-Eintrag bezieht, so dass ich derartige Fehler in Zukunft schneller
lokalisieren kann. Auch dazu habe ich im Netz keine brauchbaren
Informationen gefunden. Wie der vorliegende Fall zeigt, kann sich ein und
derselbe Eintrag "\Device\Harddisk0\D" auf Laufwerke mit unterschiedlichen
Laufwerksbuchstaben und an unterschiedlichen Controllern beziehen.
Gruß
Michael
letztens fielen mir im Eventlog diverse Disk-Fehlermeldungen auf. Sie
lauteten alle wie folgt:
| Ereignistyp: Fehler
| Ereignisquelle: Disk
| Ereigniskategorie: Keine
| Ereigniskennung: 7
| Datum: 30.12.2011
| Zeit: 03:17:22
| Benutzer: Nicht zutreffend
| Computer: ATHLON64
| Beschreibung:
| Fehlerhafter Block bei Gerät \Device\Harddisk0\D.
| (...)
Ok, da haucht also ein Datenträger sein Leben aus. Aber welcher? Laufwerk D
ist ein DVD-ROM-Laufwerk. Dieses ist IDE-Master am 1. Onboard-IDE-Kanal (der
zweite ist im BIOS deaktiviert). "\Device\Harddisk0" interpretierte ich als
diesen ersten IDE-Kanal, wie sich später herausstellen sollte, lag ich damit
falsch. Weiterhin gibt es noch eine SATA-Festplatte (Laufwerk C:) als Master
am 1. Onboard-SATA-Controller, diese Platte ist die einzige Festplatte im
Rechner. Am gleichen Controller hängt als Slave ein SATA-DVD-Brenner
(Laufwerk E:). Der 2. Onboard-SATA-Controller ist ebenfalls deaktiviert.
Weiterhin ist noch ein USB-Cardreader im Rechner verbaut, dessen 4 Slots als
Laufwerke F: - I: eingerichtet sind. Mehr Datenträger gibt es in dem Rechner
nicht.
Was also ist \Device\Harddisk0\D? Ich hatte zuerst das DVD ROM-Laufwerk in
Verdacht, denn das war ja als Laufwerk D am ersten IDE-Controller
angeschlossen. Das war es aber nicht, denn nach Abklemmen des Laufwerks
tauchten die Fehlermeldungen immer noch im Eventlog auf. Dann fiel mir auf,
dass der USB-Cardreader zeitweise nicht von Windows erkannt wurde. Außerdem
fand ich im Netz Berichte, dass defekte Cardreader schon Ursache für die
erwähnte Fehlermeldung gewesen sein sollen. Also klemmte ich den Cardreader
ab, aber auch das hatte keinen Erfolg. Schließlich prüfte ich mit einem
Hersteller-Tool die Festplatte, und da waren sie, die kaputten Blocks.
Sehr ärgerlich finde ich es nun, dass im Eventlog-Eintrag ein irreführender
Hinweis auf die kaputte Platte auftaucht. Warum um alles in der Welt kann
Windows den Namen der Platte nicht im Klartext oder wenigstens den korrekten
Laufwerksbuchstaben dort eintragen?
Nachdem ich eine neue Platte eingebaut hatte, wollte ich Daten von der
defekten Platte auf die neue Platte kopieren. Die neue Platte schloss ich an
denselben SATA-Port an wie die alte. Zwecks Anschluss der alten Platte
aktivierte ich im BIOS den 2. Onboard-SATA-Controller und schloss die
Platte dort als Master an. Nun wurde sie als Laufwerk J: in das System
eingebunden (J war der erste freie Laufwerksbuchstabe). Natürlich tauchten
danach immer noch Fehlermeldungen im Eventlog auf, denn die Platte wies ja
immer noch defekte Blocks auf. Unsinnigerweise wurde in den Fehlermeldungen
aber immer noch hartnäckig auf \Device\Harddisk0\D hingewiesen, obwohl die
defekte Platte jetzt an einem ganz anderen Controller angeschlossen war. Ich
zweifelte schon am Erfolg des Festplattentauschs, aber das Hersteller-Tool
fand nach wie vor jede Menge Fehler auf der alten Platte, während die
(fabrik-)neue Ersatzplatte fehlerfrei war. Nachdem die alte Platte endgültig
aus dem Rechner ausgebaut war, gab es keine Fehlermeldungen mehr.
Wer sich diese blödsinnige Art ausgedacht hat, Fehler zu loggen, gehört IMHO
augenblicklich zum Sanitär-Reinigungspersonal strafversetzt.
Es wäre schön, wenn hier jemand eine Antwort auf die Frage wüsste, wie man
aus kryptischen Angaben wie "\Device\Harddisk0\D" das physikalische Gerät
bzw. die physikalische Partition ermitteln kann, auf die sich der
Eventlog-Eintrag bezieht, so dass ich derartige Fehler in Zukunft schneller
lokalisieren kann. Auch dazu habe ich im Netz keine brauchbaren
Informationen gefunden. Wie der vorliegende Fall zeigt, kann sich ein und
derselbe Eintrag "\Device\Harddisk0\D" auf Laufwerke mit unterschiedlichen
Laufwerksbuchstaben und an unterschiedlichen Controllern beziehen.
Gruß
Michael
Heiko Rost
Dec 30, 2011, 9:18:43 PM12/30/11
to
Am Sat, 31 Dec 2011 01:36:15 +0100 schrieb Michael Landenberger:
> | Fehlerhafter Block bei Gerät \Device\Harddisk0\D.
...
> | Fehlerhafter Block bei Gerät \Device\Harddisk0\D.
> Sehr ärgerlich finde ich es nun, dass im Eventlog-Eintrag ein irreführender
> Hinweis auf die kaputte Platte auftaucht. Warum um alles in der Welt kann
> Windows den Namen der Platte nicht im Klartext oder wenigstens den korrekten
> Laufwerksbuchstaben dort eintragen?
Das habe ich mich auch schon gefragt. Möglicherweise passiert der Fehler
> Hinweis auf die kaputte Platte auftaucht. Warum um alles in der Welt kann
> Windows den Namen der Platte nicht im Klartext oder wenigstens den korrekten
> Laufwerksbuchstaben dort eintragen?
auf einer Ebene des Systems, auf der so etwas wie Laufwerksbuchstaben
noch gar keine Rolle spielen.
> Es wäre schön, wenn hier jemand eine Antwort auf die Frage wüsste, wie man
> aus kryptischen Angaben wie "\Device\Harddisk0\D" das physikalische Gerät
> bzw. die physikalische Partition ermitteln kann, auf die sich der
> Eventlog-Eintrag bezieht, so dass ich derartige Fehler in Zukunft schneller
> lokalisieren kann.
Wahrscheinlichkeit dem "Datenträger 0" in der Datenträgerverwaltung, die
Bedeutung des D kann ich Dir nicht sagen. Mit dem Laufwerksbuchstaben
scheint das allerdings nichts zu tun zu haben. Ich habe hier bei
USB-Sticks (sic!) manchmal Einträge mit DR0, DR1, DR2 usw., obwohl die
nur einen LW-Buchstaben haben.
> Auch dazu habe ich im Netz keine brauchbaren
> Informationen gefunden. Wie der vorliegende Fall zeigt, kann sich ein und
> derselbe Eintrag "\Device\Harddisk0\D" auf Laufwerke mit unterschiedlichen
> Laufwerksbuchstaben und an unterschiedlichen Controllern beziehen.
Vermutungen, das Ganze hat den Charakter eines Ratespiels.
Gruß Heiko
Ralf Breuer
Dec 31, 2011, 3:02:42 AM12/31/11
to
Michael Landenberger <spameim...@arcor.de> schrieb:
> Fehlerhafter Block bei Gerät \Device\Harddisk0\D.
Das "D" ist verstümmelt, es müsste "DR0" heißen.
"Harddisk0" ist aber schon eindeutig das, was als "Datenträger0" in der
Datenträgerverwaltung auftaucht.
Das ist hilfreich:
http://technet.microsoft.com/de-de/sysinternals/bb896657
--
Gruß
Ralf
> Fehlerhafter Block bei Gerät \Device\Harddisk0\D.
"Harddisk0" ist aber schon eindeutig das, was als "Datenträger0" in der
Datenträgerverwaltung auftaucht.
Das ist hilfreich:
http://technet.microsoft.com/de-de/sysinternals/bb896657
--
Gruß
Ralf
Norbert Hahn
Dec 31, 2011, 6:56:52 AM12/31/11
to
"Michael Landenberger" <spameim...@arcor.de> wrote:
>Hallo,
>
>letztens fielen mir im Eventlog diverse Disk-Fehlermeldungen auf. Sie
>lauteten alle wie folgt:
>
>| Ereignistyp: Fehler
>| Ereignisquelle: Disk
>| Ereigniskategorie: Keine
>| Ereigniskennung: 7
>| Datum: 30.12.2011
>| Zeit: 03:17:22
>| Benutzer: Nicht zutreffend
>| Computer: ATHLON64
>| Beschreibung:
>| Fehlerhafter Block bei Gerät \Device\Harddisk0\D.
>| (...)
>
>Ok, da haucht also ein Datenträger sein Leben aus. Aber welcher?
Es ist keinesweg sicher, dass ein Datenträger sich demnächst
>Hallo,
>
>letztens fielen mir im Eventlog diverse Disk-Fehlermeldungen auf. Sie
>lauteten alle wie folgt:
>
>| Ereignistyp: Fehler
>| Ereignisquelle: Disk
>| Ereigniskategorie: Keine
>| Ereigniskennung: 7
>| Datum: 30.12.2011
>| Zeit: 03:17:22
>| Benutzer: Nicht zutreffend
>| Computer: ATHLON64
>| Beschreibung:
>| Fehlerhafter Block bei Gerät \Device\Harddisk0\D.
>| (...)
>
>Ok, da haucht also ein Datenträger sein Leben aus. Aber welcher?
verabschiedet. Die Meldung besagt lediglich, dass im Inneren von Windows
ein defekter Datenblock angekommen ist. Der kann natürlich auch bei
der Übertragung von der Plattenoberfläche bis zum Puffer im RAM unter-
wegs kaputt gegangen sein.
Als Gerät wird Harddisk0 genannt. Das ist die erste Platte, um die sich
Windows kümmert. Wo genau was passiert ist, kann man der Fehlermeldung
nicht entnehmen.
Beispiel: Ich hatte in dieser NG vor vielen Monaten ebenfalls gefragt,
weil es bei mir auf \Device\Harddisk1 viele Fehler beim Lesen oder
Schreiben der Page-Daten gekommen sein soll. Nun gibt es auf dem ganzen
Laufwerk keine Swap-Dateien. Das LW ist eine externe Platte, die über
eSATA angeschlossen war. Letztendlich stellte sich heraus, dass der
Controller im Plattengehäuse, der eSATA auf SATA umsetzt, ein Macke hat.
Seit längerer Zeit läuft die gleiche Platte im gleichen Gehäuse am
gleichen Rechner über USB 2.0 völlig einwandfrei. Ich benutze den eSATA-
Anschluss noch gelegentlich, um die SMART-Werte zu überprüfen.
Norbert
Winfried Sonntag
Dec 31, 2011, 7:21:19 AM12/31/11
to
Am 31.12.2011 schrieb Michael Landenberger:
> | Ereignistyp: Fehler
> | Ereignisquelle: Disk
> | Ereigniskategorie: Keine
> | Ereigniskennung: 7
> | Datum: 30.12.2011
> | Zeit: 03:17:22
> | Benutzer: Nicht zutreffend
> | Computer: ATHLON64
> | Beschreibung:
> | Fehlerhafter Block bei Gerät \Device\Harddisk0\D.
> | (...)
Nach einer Datensicherung hat CHKDSK mit allen seinen Parametern
> | Ereignistyp: Fehler
> | Ereignisquelle: Disk
> | Ereigniskategorie: Keine
> | Ereigniskennung: 7
> | Datum: 30.12.2011
> | Zeit: 03:17:22
> | Benutzer: Nicht zutreffend
> | Computer: ATHLON64
> | Beschreibung:
> | Fehlerhafter Block bei Gerät \Device\Harddisk0\D.
> | (...)
bisher dazu immer gut Dienste geleistet.
Servus
Winfried
--
Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
GPO's: http://www.gruppenrichtlinien.de
Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
Michael Landenberger
Dec 31, 2011, 11:58:11 AM12/31/11
to
"Winfried Sonntag" <Winfried...@gmx.de> schrieb:
> Nach einer Datensicherung hat CHKDSK mit allen seinen Parametern
> bisher dazu immer gut Dienste geleistet.
Hier leider nicht, die fehlerhaften Blöcke waren nach einem Durchlauf von
chkdsk /f /r immer noch da. Außerdem mag ich mich nicht auf eine
möglicherweise nur notdürftig reparierte Platte verlassen.
Gruß
Michael
> Nach einer Datensicherung hat CHKDSK mit allen seinen Parametern
> bisher dazu immer gut Dienste geleistet.
chkdsk /f /r immer noch da. Außerdem mag ich mich nicht auf eine
möglicherweise nur notdürftig reparierte Platte verlassen.
Gruß
Michael
Winfried Sonntag
Dec 31, 2011, 1:17:58 PM12/31/11
to
Am 31.12.2011 schrieb Michael Landenberger:
Rutsch. ;)
Rüdiger Rösler
Dec 31, 2011, 4:00:26 PM12/31/11
to
Winfried Sonntag <Winfried...@gmx.de> typed:
>> Hier leider nicht, die fehlerhaften Blöcke waren nach einem
>> Durchlauf von chkdsk /f /r immer noch da. Außerdem mag ich mich
>> nicht auf eine möglicherweise nur notdürftig reparierte Platte
>> verlassen.
>
> OK, in so einem Fall hatte ich auch immer die HDD ausgetauscht.
Bei mir hat es in einem Fall geholfen, die betroffenen Partition, in
diesem Fall die mit der Auslagerungsdatei, neu zu formatieren, und zwar
mit Überprüfung aller Sektoren. Danach habe ich die Auslagerungsdatei
wieder neu eingerichtet. Offenbar hat Windows manchmal Probleme mit
defekten Sektoren in der Auslagerungsdatei. Seitdem läuft die Festplatte
einwandfrei, und das ist immerhin schon drei Jahre her.
> Guten Rutsch. ;)
>
> Servus
> Winfried
Das wünsche ich Euch, Winfried und Manfred, und allen anderen auch.
--
ЯR
>> Hier leider nicht, die fehlerhaften Blöcke waren nach einem
>> Durchlauf von chkdsk /f /r immer noch da. Außerdem mag ich mich
>> nicht auf eine möglicherweise nur notdürftig reparierte Platte
>> verlassen.
>
> OK, in so einem Fall hatte ich auch immer die HDD ausgetauscht.
diesem Fall die mit der Auslagerungsdatei, neu zu formatieren, und zwar
mit Überprüfung aller Sektoren. Danach habe ich die Auslagerungsdatei
wieder neu eingerichtet. Offenbar hat Windows manchmal Probleme mit
defekten Sektoren in der Auslagerungsdatei. Seitdem läuft die Festplatte
einwandfrei, und das ist immerhin schon drei Jahre her.
> Guten Rutsch. ;)
>
> Servus
> Winfried
--
ЯR
Rüdiger Rösler
Dec 31, 2011, 4:04:41 PM12/31/11
to
Winfried Sonntag <Winfried...@gmx.de> typed:
>> Hier leider nicht, die fehlerhaften Blöcke waren nach einem
>> Durchlauf von chkdsk /f /r immer noch da. Außerdem mag ich mich
>> nicht auf eine möglicherweise nur notdürftig reparierte Platte
>> verlassen.
>
> OK, in so einem Fall hatte ich auch immer die HDD ausgetauscht.
--
ЯR
>> Hier leider nicht, die fehlerhaften Blöcke waren nach einem
>> Durchlauf von chkdsk /f /r immer noch da. Außerdem mag ich mich
>> nicht auf eine möglicherweise nur notdürftig reparierte Platte
>> verlassen.
>
> OK, in so einem Fall hatte ich auch immer die HDD ausgetauscht.
Bei mir hat es in einem Fall geholfen, die betroffenen Partition, in
diesem Fall die mit der Auslagerungsdatei, neu zu formatieren, und zwar
mit Überprüfung aller Sektoren. Danach habe ich die Auslagerungsdatei
wieder neu eingerichtet. Offenbar hat Windows manchmal Probleme mit
defekten Sektoren in der Auslagerungsdatei. Seitdem läuft die Festplatte
einwandfrei, und das ist immerhin schon drei Jahre her.
diesem Fall die mit der Auslagerungsdatei, neu zu formatieren, und zwar
mit Überprüfung aller Sektoren. Danach habe ich die Auslagerungsdatei
wieder neu eingerichtet. Offenbar hat Windows manchmal Probleme mit
defekten Sektoren in der Auslagerungsdatei. Seitdem läuft die Festplatte
einwandfrei, und das ist immerhin schon drei Jahre her.
> Guten Rutsch. ;)
>
> Servus
> Winfried
Das wünsche ich Euch, Winfried und Michael, und allen anderen auch.
>
> Servus
> Winfried
--
ЯR
0 new messages