Die Fehler bei den Fehlermeldungen

Gestern habe ich über die sprachlichen Herausforderungen geschrieben, die sich bei Texten über Tech-Themen oft stellen. Die gleichen Ursachen führen dazu, dass sich unsere Artikel oft sehr schwer bebildern lassen. Abstrakte Konzepte werden typischerweise in Symbolbildern ausgedrückt, die manchmal passen. Oft passen sie nicht, häufig sind sie ausgelutscht.

Beim Tagi unterstützt uns die Bildredaktion heute nach Kräften. Früher mussten wir uns oft selbst behelfen. So ist auch obiges Foto entstanden. Es wurde gewissermassen aus der Not geboren, um den Artikel «Tipps zur Absturzbekämpfung» vom 3. Oktober 2005 zu illustrieren. Auf dieses Meisterwerk bin ich noch heute stolz. Ich habe mich selbst mit der Nikon D70s geknipst, während ich eine vorher ausgedruckte Fehlermeldung vom Bildschirm entfernt habe. Beim Tipp ging es, natürlich, um die Frage, wie man Fehlermeldungen vom Bildschirm bekommt.

Fehlermeldungen – im Lexikon sollte neben dem Begriff «notwendiges Übel» obige Fehlermeldung abgebildet sein. Notwendig sind die Fehlermeldungen, weil Perfektion bei der Software ein unerreichbarer Wunschtraum bleibt. Die Entwickler sind so fehlbar wie wir alle. Und selbst wenn sie perfekten Code liefern würden, dann könnten problematische Rahmenbedingungen weiterhin die Programmausführung zum Stocken bringen. Was nun aber die Fehlermeldungen angeht, sind die alles andere als perfekt. Im Lauf der Jahre habe ich folgende Problembereiche isoliert:

Die Fehlermeldungen sind falsch, nichtssagend oder sogar irreführend

Softwarehersteller machen es sich in der Regel einfach. Statt im Code jede einzelne Ausnahmesituation abzufangen, bauen Sie «Catch-all»-Exceptions, die diverse Ursachen haben können. Entsprechend vage sind dann die Beschreibungen, in denen von Ausnahme- oder Ausführungsfehlern die Rede ist. Oft fehlt eine Angabe von Ursachen, und es kommt auch vor, dass die angegebene Ursache falsch ist.

Ein Paradebeispiel ist die oben abgebildete Meldung. «Catastrophic failure» ist übertrieben. Es gab einen Absturz des Windows Media Players, was weiss Gott keine Seltenheit ist. Angemessen wäre diese Fehlermeldung, wenn das CD-Laufwerk beim Einzug den Finger des Nutzers abgetrennt hätte. Oder wenn sich das Modem bei einem russischen Atomkraftwerk eingeloggt und eine Kernschmelze ausgelöst hätte. Oder wenn der Browser auf die Idee gekommen wäre, in Eigenregie auf Facebook Pro-Pegida-Parolen zu posten.

Andererseits gibt die Meldung keinerlei Hinweis auf die Ursache oder die Art des Problems. Immerhin: Der Hex-Fehlercode bietet eine gute Recherchemöglichkeit. Codes sind ideal, weil sie bei Suchmaschinen- oder Wissensdatenbank-Recherchen sprachunabhängig Resultate liefern. Bei ausformulierten Meldungen muss man bei deutschen Softwareprodukten oft erst den englischen Wortlaut in Erfahrung bringen, weil die Quellen ergiebiger sind.

Von einer guten Fehlerangabe erwarte ich einen Fehlercode, eine Beschreibung, plus einen Link auf weiterführende Informationen.

Fehlermeldungen sind weg, bevor man sie zur Kenntnis genommen hat

Das liegt natürlich daran, dass wir User schneller klicken als lesen. Es liegt aber oft auch daran, dass uns erst nach und nach klar wird, dass wir der schnell weggeklickten Meldung unsere Aufmerksamkeit hätten schenken müssen. Es braucht daher eine Möglichkeit, Fehlermeldungen nachträglich einzusehen – am besten über eine Benachrichtigungs-Historie oder ähnlich. Bei Windows gibt es die Ereignisanzeige (siehe Wie Windows sich nonstop selbst auf die Finger schaut). Das wäre eine hervorragende Idee, wenn sich die Ereignisanzeige nicht nur an Administratoren, sondern auch an die normalen Nutzer wenden würde. So ist nutzt sie faktisch nichts, weil die meisten Nutzer sie nicht kennen und weil so viele Ereignisse geloggt werden, dass die relevanten kaum aufzufinden sind.

Das Wartungscenter könnte ein guter Ersatz sein. Meine Erfahrung ist jedoch, dass wirklich nützliche Informationen im Wartungscenter die Ausnahme und nicht die Regel sind. Beim Mac ist die Konsole auch nicht gerade der Inbegriff an Benutzerfreundlichkeit.

Fehlermeldungen brauchen einen klaren Urheber

Man mag es kaum glauben, aber es ist tatsächlich so: Bei Windows sieht man recht häufig Fehlermeldungen, die sich noch nicht einmal einem Programm zuordnen lassen. Das ist vorwiegend beim Start der Fall: Da werden Treiber und Dienste geladen, Systemstartobjekte ausgeführt und über idiotische Mechanismen wie RunDLL und Svchost in Betrieb gesetzt. Wenn dabei etwas schief geht – und obwohl man sich das bei Microsoft anscheinend nicht vorstellen kann, geht dabei oft etwas schief – kommen so verquere Meldungen heraus, aus denen selbst erfahrene Windows-Anwender nicht schlau werden.

Mein Highlight: Meldungen, bei denen Pfad und Dateiname der betroffenen Datei aus Platzgründen abgeschnitten sind oder die Systemkomponenten aufführen, von denen der normale Anwender noch nie gehört hat. (Und nicht gehört haben muss, weil die fraglichen Komponenten nicht auf eine direkte User-Interaktion ausgelegt sind.

Der Fehlerfall muss bei der Softwareentwicklung systematisch berücksichtigt werden

Das ist das grösste Problem überhaupt, wie man bei Windows und bei Microsoft-Produkten häufig sieht. Microsoft baut Software selten aus einem Guss, sondern setzt lieber auf Frameworks und Schnittstellen. Alles wird in Komponenten zerlegt und über APIs genutzt. Das klingt in der Theorie wunderbar, weil Programme nicht isoliert werkeln, sondern interagieren und im Ganzen zu mehr als der Summe der Einzelteile werden.

In der Praxis ist diese Softwarearchitektur eine Quelle von unendlichen, schwer zu behebenden Problemen. Einige Beispiele:

• Die Systembibliotheken (DLLs). Die Idee ist, Funktionen in Bibliotheken auszulagern, die dann von allen Programmen benutzt werden können. Die Probleme sind fehlende Bibliotheken, Versionskonflikte (DLL hell), DLL-Hijacking und schlechte Wartbarkeit der Programminstallationen.
• .Net-Framework. Das soll plattformübergreifend internetaffine Anwendungen ermöglichen¹. Unter Windows treten häufig Update- und Versionskonflikte auf. Für die Kummerbox habe ich unzählige Male die Anleitung verschickt, wie man Probleme mit Service Packs fürs .Net-Framework behebt – die sind sehr umfangreich, kompliziert und betreffen auch Leute, die noch nicht einmal .Net-Anwendungen einsetzen.
• Messaging Application Programming Interface (Mapi). Dank dieser Schnittstelle kann man direkt aus Word oder aus anderen Programmen heraus Mails versenden. Oder auch nicht, denn Mapi macht häufig Ärger. Ältere und neuere Programmversionen harmonieren schlecht.
• Add-ins, Add-Ons, Plug-Ins, Browserhilfsobjekte, Shell-Extensions und was es da auf Anwendungs- und Betriebssystemebene sonst noch gibt. Offenheit ist grundsätzlich zwar zu begrüssen, geht aber in der Praxis zu oft auf Kosten der Stabilität. Erweiterungen dürfen daher nie ohne Zustimmung des Benutzers installiert werden (was bei Windows gang und gäbe ist). Sie müssen jederzeit widerstandsfrei und rückstandslos entfernt werden können (was bei Windows nicht der Fall ist). Und sie müssen sollten so weit gekapselt ausgeführt werden, dass sie im Problemfall das Hauptprogramm nicht tangieren oder wenigstens leicht als Fehlerquelle identifiziert werden können.
• ActiveX. Microsofts Softwarekomponentenmodell, mit dem sich Windows-Code im Browser ausführen liess. Dass eine solche Funktion nicht nur von wohlmeinenden Leuten benutzt werden würde, sondern auch von Cyberkriminellen, konnte sich Microsoft nicht vorstellen. In der Folge hat sich ActiveX zu einer einzigen gigantischen Sicherheitslücke entwickelt.

Wie ActiveX beweist, werden diese immer für den Betrieb unter Idealbedingungen entwickelt. Dem Missbrauchsfall wird während der Entwicklung keine Rechnung getragen und selbst die Auswirkungen mangelnder Qualität von Einzelkomponenten aufs ganze System nicht bedacht. Dabei müsste es umgekehrt sein. Solche Systeme müssen konsequent so gebaut werden, dass der Ausfall einzelner Komponenten verkraftbar sind. Und für den Nutzer sofort klar wird, welche Komponente versagt hat. Dann erhält der User seine Handlungsfreiheit zurück und kann entscheiden, was er tut: Aktualisieren, deinstallieren oder den Hersteller auf Schadenersatz verklagen. (Oder wenigstens jemanden an der Support-Hotline zusammenscheissen…)