Unterthema: PC-Ressourcen im Überblick
Unterthema: Wenn der PC noch `Piep´ sagt
Probleme beim Zusammenspiel einzelner PC-Komponenten waren vor einigen Jahren schon auf unsaubere Designs und nur unzureichend eingehaltene Spezifikationen zurückzuführen. Das setzt sich nahtlos fort mit Sperenzchen, die einen PC deshalb heimsuchen, weil sich Intel und Microsoft bemüht haben, den Einbau einer Erweiterung so einfach zu gestalten wie das Einlegen einer Scheibe Toast. Die stets ums Sparen bemühte Branche und das verkorkste Ur-PC-Design tragen ein übriges dazu bei, damit aus der Vision ein Alptraum werden kann.
Plug & Play findet sich heute allerorten, egal ob eine Komponente das Attribut verdient oder nicht. Einfache Netzadapter, Schnittstellen-, Sound- und ISDN-Karten sind kaum noch in klassischer Ausfertigung mit Jumpern oder DIP-Schaltern erhältlich. Theoretisch sollte das BIOS eines jeden aktuellen PC der Lage Herr werden und dem Anwender das Zuteilen verfügbarer Systemressourcen abnehmen. In der Praxis jedoch funktionieren all diese Mechanismen allenfalls mittelmäßig, so daß sich wohl jeder zweite noch das klassische PC-1×1 aneignen muß.
Seit die IBM das PC-Design auf den Markt warf, hat sich wenig geändert. Um mit der Hardware zu kommunizieren, stehen selbst modernen PentiumPro-Systemen eine arg knappe Anzahl von 16 IRQ-Leitungen zur Verfügung, über die zum Beispiel eine serielle Schnittstelle signalisieren kann, daß Zeichen zur Verarbeitung anstehen. Über vier 8- und ebenso viele 16-Bit-DMA-Kanäle kann ein Gerät am Prozessor vorbei Daten in den Speicher pumpen. Einzig die Ein-/Ausgabe-Ports, die der Prozessor zum Steuern der Hardware benutzt, sind reichlich vorhanden.
Mit all dem ließe sich prima leben, wenn nicht die zur Verfügung stehenden Ressourcen künstlich eingeschränkt wären. In durchschnittlichen PCs sind die Hälfte der IRQ-Leitungen bereits belegt, ohne daß nur eine Erweiterungskarte im System steckt. Hier fordern schon Tastatur und Timer in Form eines IRQ jeder ihren Tribut. Dort macht sich ein Floppy-Controller breit und belegt gleich noch einen der ebenfalls knappen DMA-Kanäle. Besonders schnell gehen einem PC die Ressourcen aus, wenn darin Erweiterungskarten noch alter ISA-Bauart werkeln, die Ressourcen stets exklusiv für sich beanspruchen.
Wer meint, insbesondere angesichts der knappen IRQs dem System ein Schnippchen schlagen zu können, indem er etwa eine dritte serielle Schnittstelle mit einem bereits von einer anderen belegten IRQ versorgt, fällt auf die Nase. Das gilt spätestens dann, wenn er versucht, beide Schnittstellen gleichzeitig zu benutzen. Mangels geeigneter Vorkehrungen gehen Interrupt-Signale verloren. Bei arger Knappheit kann man auf einen reibungslosen wechselweisen Betrieb hoffen - aber selbst dafür gibt es keine Garantie.
Allen im PC derzeit gebräuchlichen Erweiterungsbussen ist die Beschränkung auf den PC-Ressourcensatz gemein. Selbst bei PCI, das auf der Bus-Seite von all dem nichts weiß, werden die vier unterscheidbaren PCI-Interrupt-Signale A, B, C und D für die Software auf die üblichen PC-Interrupts 0 bis 15 abgebildet. Was sich am einen Ende also gut macht, begegnet am anderen uralten Problemen. Die inzwischen abgelösten Busse, VL und EISA, haben sich an einer solchen Abstraktion erst gar nicht versucht.
Moderne PCI-Erweiterungskarten vermögen sich aufgrund des Bus-Designs und eines modifizierten Betriebs des Interrupt-Controllers eine IRQ-Leitung zu teilen. Da ein PCI-Interrupt stets auf einen ISA-IRQ abgebildet wird, schränkt in der Praxis das jeweilige Betriebssystem solches Treiben ein. Oft hat sich die Neuerung nicht bis zu den Treiberentwicklern herumgesprochen. Das gilt besonders dann, wenn eine solche Erweiterung mit einem traditionell vorhandenen Treiber angesteuert werden soll, etwa bei einem NE2000-kompatiblen PCI-Netz-Adapter ist Vorsicht angebracht. Im Zweifelsfall bedarf es neuer, spezieller Treiber.
Beim Aufbau eines Systems oder der Erweiterung eines bestehenden muß man selbst heute noch peinlich genau darauf achten, IRQs, Port-Adressen und DMA-Kanäle konfliktfrei aufzuteilen. Besonderer Argwohn gebührt dabei Komponenten, die auf modernen Motherboards bereits integriert sind. Dort sind serielle und parallele Schnittstellen, Floppy- und IDE-Controller und ein PS/2-kompatibler Mausanschluß fast Standard. Sie alle hängen selbst bei modernen PCI-Systemen hinter der PCI-to-ISA-Bridge. Das heißt, sie brauchen als ISA-Komponenten alle ihren eigenen IRQ.
Zu allem Übel lassen sich die fest in die Chipsätze integrierten I/O-Bausteine mitunter gar nicht sauber abschalten, so daß man sich auf einen reibungslosen Betrieb von Erweiterungen mit den Ressourcen, die sie normalerweise belegen, nicht blind verlassen darf. Als hartnäckig erweisen sich PS/2-Mausports, die den IRQ12 blockieren, unabhängig davon, ob überhaupt eine Anschlußmöglichkeit für eine PS/2-Maus das Board ziert. So mancher hat Tage mit der Fehlersuche bei seiner internen ISDN-Karte verbracht, bis sich als Übeltäter der Mausport entpuppte. Nur auf Boards, die einen Jumper bieten, um den IRQ12 von der PS/2-Logik abzukoppeln, läßt sich dieser IRQ für andere Zwecke verwenden.
Die Art und Weise, auf die man die Konfigurationsdetails beeinflussen kann, hat sich in den letzten Jahren enorm verändert. Früher war der Anwender allein verantwortlich. Er hat Erweiterungen mittels Jumper oder DIP-Schalter auf die rechten Einstellungen getrimmt und mußte im Zweifelsfall Betriebssystem oder Treiber davon in Kenntnis setzen. Neuerdings nimmt ihm das BIOS dank PCI und Plug & Play diese Aufgabe weitgehend ab.
Wer sich allzu sehr auf die Automatik verläßt, verschenkt nicht nur Ressourcen, sondern verspielt womöglich ein Stück notwendige Kompatibilität. Das gilt besonders, wenn ein System mit vielen Erweiterungen zugepflastert werden soll. Über die Einflußmöglichkeiten bestimmt beinahe ausschließlich das BIOS. Die Regel- und Eingriffsmöglichkeiten, die moderne Betriebssysteme bieten, fallen eher dürftig aus - Windows 95 einmal an dieser Stelle ausgenommen.
In einigermaßen zugänglichen aktuellen BIOS-Varianten finden sich gemeinhin zwei total unabhängige Bereiche, einer für die PCI-Konfiguration und einer für (ISA-)Plug&Play. PCI-seitig kann ein BIOS als vollkommen gelten, wenn es die Zuordnung einzelner (ISA-)IRQs zu PCI-Slots erlaubt. So kann man wirklich gezielt einzelnen PCI-Karten Interrupt-Sharing und anderen exklusiv einen IRQ verordnen. Als brauchbar erweist sich aber schon die Möglichkeit, für IRQs eine PCI-Rangfolge zu vergeben.
In der PCI-Spezifikation steht, daß IRQs so lange von Slot 1 bis n vergeben werden, bis sie aufgebraucht sind. Benötigt eine weitere Karte einen IRQ, wird der erstvergebene IRQ von zwei Erweiterungen gemeinsam benutzt und so weiter. Arrangiert man die PCI-Karten geeignet, kommt man ähnlich weit wie mit einer direkten Zuordnung. Auf Boards, die noch dem Beginn der PCI-Ära entstammen, finden sich mitunter Jumper-Wüsten, die diese Aufgaben übernehmen.
Mancher guckt aber in die Röhre, was solche Vorhaben angeht: Besonders Markenhersteller wagen es noch heute, Systeme zu verkaufen, die keinerlei Einflußnahme gestatten. Oft überschreiten dann auch die Plug&Play-seitig gebotenen Möglichkeiten solcher Systeme den Grad des Unzumutbaren. Willkommenes Beispiel sind aktuellere Phoenix-BIOS-Versionen. Hierin ist weder PCI- noch Plug&Play-mäßig etwas auszurichten.
Käufer solcher Systeme müssen mit den Automatismen leben. Sie haben nicht einmal die Chance, sie abzuschalten. Vorangehendes Beispiel wäre mit einem solchen System kaum zu meistern. Einzig Windows 95 verspräche Abhilfe: Es kann zumindest die vom BIOS verteilten Plug&Play-Ressourcen neu mischen. PCI-seitig schafft erst das OEM Service Pack 2 Abhilfe. Es kann, ein modernes PCI-BIOS (Version 2.1 ff.) vorausgesetzt, auch die PCI-IRQs neu sortieren.
Den kleinsten sinnvollen Nenner stellt eigentlich die Möglichkeit dar, einem System per BIOS-Setup mitzuteilen, welche IRQs und DMA-Kanäle im System von Nicht-Plug&Play-fähiger Hardware belegt sind. Das soll verhindern, daß das System diese Ressourcen (unwissend) ein zweites Mal vergibt. Allzu oft jedoch wird die Chance nicht wahrgenommen. Die Symptome sind unterschiedlich, je nachdem, welche Komponenten zufällig betroffen sind.
Beispiel: Wer sein ISA-Video-Capture-Board, das den IRQ10 benutzt, im BIOS-Setup nicht als Legacy-Device anmeldet, muß damit rechnen, daß der PCI-SCSI-Adapter denselben IRQ vermittelt bekommt. Windows 95 würde in einem solchen Fall den Kompatibilitätsmodus aktivieren, also die SCSI-Platte konservativ übers BIOS ansprechen. Aber selbst das wäre nicht von Dauer: Spätestens bei Benutzung des Capture-Boards wären Abstürze vorprogrammiert.
Eine Besonderheit stellen PCI-seitig ISA-Karten dar, die nicht über I/O-Ports, sondern über ein Speicherfenster des normalen Adreßraums angesprochen werden. Das trifft für einige Netzadapter, aber auch für ISDN-Karten zu. Manche BIOS-Variante würdigt das mit einer speziellen Option, die meist `ISA shared memory´ oder ähnlich heißt. Vergißt man hier, die von ISA-Karten benötigten Adressen freizuschalten, verhält sich eine solche Karte, als sei sie defekt.
Einen wichtigen Zusammenhang würdigen leider die wenigsten BIOS-Varianten: Obwohl sowohl die IRQs, die PCI-Karten benutzen können, als auch die von ISA-Karten belegten IRQs demselben Pool entstammen, lassen sie sich sowohl PCI- als auch alten, Nicht-Plug&Play-Karten gleichzeitig zuweisen. Fürs Feinabstimmen zwischen diesen Bereichen zeichnet also der Anwender selbst verantwortlich. Stimmt es dort nicht, ist Ärger vorprogrammiert.
Ich habe noch kein BIOS gesehen, das freiwillig über die von ihm gewählte Ressourcen-Verteilung Auskunft gibt. Wer wegen vieler Erweiterungen Feintuning betreiben muß oder sich schlicht der Ressourcen vergewissern möchte, tut gut daran, eine DOS-Bootdiskette bereitzuhalten: Mit unserem Testprogramm CTPCI können Sie sich dort die Ressourcen ansehen, die das BIOS PCI-Komponenten zugeteilt hat. Das aus der Plug&Play-Pionierzeit stammende Isolate-Programm von Microsoft leistet etwas Ähnliches für Plug&Play-Erweiterungen.
Weder für Windows NT noch für OS/2 sind mir vergleichbare Werkzeuge bekannt. Da beide ohnehin einen weiten Bogen um Plug & Play schlagen und bei PCI-Geräten BIOS und Treiber alles Nähere regeln, sollten die DOS-Tools beim Verifzieren der Konfiguration ebenso ihren Zweck erfüllen. Die Linux-Gemeinde findet im /proc-Ast des Root-Devices die PCI-Informationen. Für Plug & Play müssen sie sich spezielle Kernel-Patches besorgen; das zugehörige Werkzeug zum Auslesen der Plug&Play-Karten übertrifft Microsofts isolate. Es kann Plug&Play-Karten sogar konfigurieren.
Die beiden hier erwähnten Plug&Play-Tools für DOS und Linux funktionieren unabhängig davon, ob ein Plug&Play-fähiges BIOS vorhanden ist. Einen anderen Ansatz hat Intel mit seinem Setup-Programm für den Einsatz von Plug&Play-Erweiterungen (ICU) auf nicht vorbereiteten Systemen respektive BIOS-Versionen gewählt: Ein DOS-Treiber ersetzt dabei das Plug&Play-BIOS und konfiguriert die Karten. Wie und welche Ressourcen bereits belegt sind, entnimmt es dabei einer Datei, die das ICU-Programm im Hauptverzeichnis der Boot-Partition hinterlegt.
Für OS/2- oder NT-Besitzer, die beispielsweise eine zwar Blaster-kompatible Soundkarte, jedoch mit Plug&Play-Konfiguration besitzen, kann Intels ICU ein Notnagel sein: Sie müssen nach dem Einschalten des Systems einmal DOS nebst Plug&Play-Treiber booten, damit die Karte die gewünschten Ressourcen akzeptiert. Anschließend steht die Karte dann bis zum nächsten Ausschalten auch unter dem Wahlbetriebssystem zur Verfügung. Einzig wer mit Windows 95 arbeitet, ist sogar auf einem herkömmlichen System mit Plug&Play-Erweiterungen fein raus.
Auf älteren Systemen, die noch kein adäquates BIOS aufweisen, konfiguriert Windows 95 die Geräte selbständig. Die Konfiguration muß dafür aber eine Voraussetzung erfüllen: Der Ressourcenbedarf aller Nicht-Plug&Play-Erweiterungen muß dem System bekannt sein. Das ist nur dann gegeben, wenn für alle vorhandenen Komponenten echte Windows-95-Treiber installiert sind. Eine nicht direkt unterstützte Meßwerterfassungkarte bleibt aber unter Umständen unerkannt. Von ihr belegte Ressourcen müssen dann für die automatische Vergabe unter Windows 95 ausgeklammert werden.
Eine Crux moderner Systeme ist es, daß sie bei jedem Einschalten die Vergabe der Ressourcen wiederholen. Bei PCI-Karten reicht es aufgrund der Zuordnung von IRQs zu Slots, wenn man sie nur in verschiedene Slots steckt, damit das BIOS die Ressourcen neu mischt. Ein Betriebssystem findet Hardware dann unter Umständen nicht wieder, wenn die Treiber die PCI-Informationen nicht selbst auswerten (bei NE2000-kompatiblen Netzadaptern unter Linux ist das zum Beispiel der Fall), sondern dies nur einmal erfolgt, zum Beispiel während der Installation.
Aber selbst Windows 95 reagiert empfindlich darauf: Es fährt beim Booten eine erneute Hardware-Erkennung, obwohl sich eigentlich nichts geändert hat, und möchte mindestens einmal neu gestartet werden. Man sollte sich also vor der richtigen Inbetriebnahme eines System entscheiden, welche PCI-Karte wo bleibt. Wer schließlich die Grenzen vorgibt, in denen ein BIOS Ressourcen verteilen darf, bleibt von solch unliebsamen Überraschungen meist verschont.
Beispiel: Auf einem System sollen parallel eine Sound-Blaster-kompatible Plug&Play-Karte auf den Standardadressen (IRQ5) und ein NE2000-kompatibler PCI-Netzadapter auf IRQ11 laufen, damit IRQ10 für die nicht-Plug&Play-ISDN-Karte freibleibt. Das gelingt, indem man im BIOS-Setup nur den IRQ11 für PCI freigibt und alle IRQs außer IRQ5 für Plug & Play sperrt. Das BIOS sollte dann die gewünschten Einstellungen vornehmen.
Generell kann es lohnenswert sein, ein wenig an der PCI- und Plug&Play-Konfiguration im BIOS-Setup zu drehen: Viele PCI-Grafikkarten fordern einen IRQ an, obwohl sie ihn für den Betrieb meist gar nicht brauchen - unseren Erfahrungen nach jedenfalls. Wer außer einer Grafikkarte derzeit keine weitere PCI-Karte in einem System betreibt, kann einfach dem PCI-Bus keine ISA-Interrupts zuteilen und voilà: die Grafikkarte belegt auch keinen. Der IRQ steht für andere Erweiterungen bereit.
Auf die Nase fällt man mit dieser Methode, wenn zusätzliche PCI-Erweiterungen betrieben werden. Ein SCSI-Hostadapter funktioniert ohne Interrupt nicht. Aber auch hier kann man sich helfen: Man gibt einfach einen IRQ weniger frei, als PCI-Karten vorhanden sind. Die Grafikkarte teilt sich dadurch einen IRQ mit einer anderen PCI-Karte. Der Nutzwert bleibt der gleiche. Klar dabei sollte sein, daß Interrupt-intensive Erweiterungskarten exklusiv einen eigenen IRQ spendiert bekommen und die weniger aktiven Erweiterungen zum Teilen verurteilt werden.
Beispiel: In einem System stecken zwei PCI-Karten, ein NCR-Hostadatper und eine S3-Grafikkarte. Sie belegen beide einen eigenen ISA-IRQ. Für den Einbau einer ISDN-Karte wird jetzt ein zusätzlicher IRQ gebraucht. Das läßt sich erreichen, indem man im BIOS nur einen IRQ für PCI freigibt respektive den betroffenen Slots denselben IRQ zuordnet. Nach einem Reboot teilen NCR und Grafikkarte einen IRQ. Es ist Platz für die ISDN-Karte.
Ein Haken der soweit geschilderten Beispiele liegt darin, daß man Plug&Play-seitig keine Prioritäten vergeben kann. PCI-seitig ist das immerhin darüber möglich, daß es eine klare Rangfolge für die Vergabe der IRQs gibt (vom ersten bis zum letzten Slot). Unter Umständen ist es so beispielsweise unmöglich, eine Sound-Blaster-kompatible Plug&Play-Karte auf IRQ5 zu zwingen, wenn eine weitere Plug&Play-Karte im System werkelt.
Die heute auf den meisten Systemboards integrierten Komponenten kommen als Plug&Play-Geräte daher. Das heißt, man muß ihre Ressourcen im BIOS keineswegs eintragen. Das geschieht automatisch. Leider fallen die Wahlmöglichkeiten für die Systemkomponenten bei den meisten Boards dünn aus. Zum Beispiel räumen sie den integrierten seriellen Ports nur die Standardadressen und IRQs für COM1 und COM2 ein (IRQ3 und 4). Erst in jüngster Zeit bieten einige Boards auch IRQs des zweiten Interrupt-Controllers an. Dadurch ist es möglich, selbst eine alte Schnittstellenkarte, die noch nicht mit IRQs größer 7 arbeiten kann, neben den Onboard-Komponenten weiterzuverwenden.
Auf reinen SCSI-Systemen bietet es sich heute an, die auf dem Motherboard eventuell vorhandenen IDE-Ports via BIOS-Setup abzuschalten. Dadurch werden mit einem Schlag zwei IRQs für andere Geräte frei. Vorsicht aber: Wer gemeint hat, am CD-ROM-Laufwerk Geld sparen zu können und sich so für die günstigere ATAPI-Version entschieden hat, zahlt Lehrgeld. Die IDE-Ports aktueller Boards lassen sich zwar vermeintlich beide abschalten und geben die Interrupt-Ressourcen frei, aber oft ist der IRQ14 dennoch nicht zu haben. (ps)
| IRQ0 | bei allen PCs vom integrierten Timer-Baustein belegt |
| IRQ1 | bei allen PCs vom Tastatur-Controller belegt |
| IRQ2 | zweiter Interrupt-Controller (IRQ8 bis 15), nicht benutzbar |
| IRQ3 | serielle Schnittstelle (COM2) |
| IRQ4 | serielle Schnittstelle (COM1) |
| IRQ5 | zweiter Druckerport (LPT2), normalerweise trotzdem verfügbar |
| IRQ6 | bei allen PCs vom Floppy-Controller beansprucht |
| IRQ7 | erster Druckerport (LPT2), normalerweise trotzdem verfügbar |
| IRQ8 | bei allen PCs von der integrierten Real Time Clock (RTC) belegt |
| IRQ9 | in der Regel frei (am Bus IRQ2-Leitung des Original-PC!) |
| IRQ10 | in der Regel frei |
| IRQ11 | in der Regel frei |
| IRQ12 | bei einigen PCI-Boards nicht abschaltbarer PS/2-Mausport |
| IRQ13 | bei heutigen Prozessoren stets für die FPU verwendet |
| IRQ14 | bei IDE-Platten stets (primärer) IDE-Port |
| IRQ15 | bei vielen PCI-Boards sekundärer IDE-Port |
Ausfälle der PC-Hardware äußern sich auf die unterschiedlichste Weise. Eindeutig ist es, wenn nach dem Einschalten nur noch eine Reihe von Piepsern ertönt. Eine Liste mit aktuellen Morse-Zeichen findet sich im Web an jeder zweiten Ecke und natürlich bei den einschlägigen BIOS-Herstellern, so etwa www.award.com, www.phoenix.com et cetera. Ebenso trivial sind Fehler beim Speichertest und vom BIOS als defekt gemeldete Platten. So unerfreulich und möglicherweise teuer das sein mag, um so einfacher ist die Beseitigung - wenn Wackler, defekte Kabel und dergleichen ausgeschlossen sind.
Unerfreulich wird die Fehlersuche in dem Moment, wo Software oder nur ein Betriebssystem mit von der Partie ist. Was früher Verklemmungen zwischen zwei installierten DOS-Disk-Caching-Programmen waren, die sich wie ein Hardware-Defekt gaben, sind heute sporadische Schutzverletzungen und dergleichen. Wer auf seinem PC zwei verschiedenartige Betriebssysteme, möglichst nicht DOS oder Windows 3.x, installiert hat, kann leicht verifizieren, ob die Hardware einen Schuß hat, oder ob er nur einer Software- oder Treiber-Schwäche aufzusitzen droht. Läuft eins der Betriebssysteme einwandfrei, ist letzteres wahrscheinlich.
Benehmen sich beide Systeme ähnlich sonderbar und haben sie womöglich Probleme mit ein und derselben Komponente, ist der Fall ebenso klar. Knifflig wird es bei nur einem Betriebssystem. Hier hilft es nur, einzelne Komponenten aus der Konfiguration zu entfernen, soweit sie zum Betrieb nicht unbedingt notwendig sind, die RAM-Ausrüstung zu halbieren, externe Speichercaches abzuschalten und zur Not die BIOS-Einstellungen auf konservatives Niveau herabzusetzen (etwa Speicher-, Bus- und Cache-Timings). Wer dabei jeweils nur einen Schritt macht, findet am ehesten heraus, wo es hapert.
PCs bilden durch ihre Hardware-Vielfalt in Kombination mit riesigen Betriebssystemen und Applikationen ein nicht mehr vollständig durchschaubares System. Darin gibt es jede Menge Wechselwirkungen, wodurch sich in der Mehrzahl der Fälle von den Symptomen eines Fehlverhaltens nicht mehr eindeutig nur per Logik auf die Ursache schließen läßt - der Möglichkeiten sind einfach zu viele, selbst für versierte PC-Schrauber.
Nachdem man den Fehler endlich gefunden hat, erscheinen auch die Symptome ganz logisch. Ein gewisser Kolumbus hat diesen Sachverhalt mal mit einem Ei, das es auf die Spitze zu stellen galt, demonstriert. Hinterher ist man immer schlauer.
Natürlich gibt es Symptome - wie eingangs beschrieben -, die eindeutig auf die Natur des Fehlers schließen lassen. Aber vor allem Ressourcen-Konflikte, also doppelt genutzte I/O-Adressen oder IRQs, sind tückisch. Bei einer Sound-Karte, die beim Abspielen von Systemsounds holpert oder abbricht, kann man fast darauf wetten, daß sie sich ihren IRQ noch mit einer anderen Karte teilt. Teilt sich der Mausport jedoch einen IRQ mit einer selten benutzten Karte, wird man vereinzelt fehlende IRQs beim Bewegen der Maus lange Zeit überhaupt nicht bemerken oder - wenn´s arg holpert - zunächst auf Schmutz an der Rollkugel zurückführen.
Wann immer man nach längerer Zeit - also etwa einer durchforschten Nacht - nicht zu Resultaten gekommen ist, sollte man Symptome Symptome sein lassen und zu einer methodischen Fehlersuche übergehen. Die wichtigste Regel lautet dabei, das System so weit wie möglich zu vereinfachen. Alle nicht benötigten Steckkarten raus, alle nicht benötigte (Treiber-)Software raus. Alle angeschlossenen Geräte abziehen, die man nicht braucht - dazu gehören auch CD-ROMs, Wechselplatten, Drucker, Scanner, Dongles und so weiter.
Wer noch mit einfachem DOS arbeitet, sollte dieses mal ohne Config.sys und Autoexec.bat betreiben. Hier stören sich oft genug Treiber oder TSRs untereinander, wobei manchmal schon die Änderung der Ladereihenfolge das Problem beseitigen kann.
Bei allen modernen Betriebssystemen ist es hilfreich, wenn man nur zu Testzwecken mal eine absolut jungfräuliche Version installiert. Keinen Sinn hat es, dasselbe Betriebssystem nur ein weiteres Mal über ein bestehendes zu installieren, weil dieses dann alle Einstellungen, Treiber, Hintergrundjobs und damit möglicherweise auch den Fehlerverursacher bestehen läßt. Ideal ist es folglich, wenn man mit einer frisch formatierten Harddisk neu beginnen kann - entweder nach einem vollständigen Backup oder auf einer frei verfügbaren zweiten Platte.
Das wichtigste Ziel dabei ist zunächst, eindeutig herauszufinden, ob der Fehler in der Hardware oder in der Software liegt. In beiden Fällen ist es zudem äußerst hilfreich, wenn man noch ein zweites, möglichst ähnliches, aber einwandfrei funktionierendes PC-System zur Verfügung hat. Einmal kann man leicht Komponenten hin- und hertauschen, zum anderen lassen sich vor allem zweifelhafte BIOS-Setup- oder Jumper-Einstellungen schnell und einfach vergleichen.