Ein harmloses Stück Hardware

Mein Bürokollege verwendet seit Jahr und Tag ein gewisses Zeiterfassungsprogramm, das er schon seit mehr als 10 Jahren in intensivem, täglichen Gebrauch hat. Dieses Programm besteht aus vielen einzelnen Modulen (in diesem Fall tatsächlich viele einzelne ausführbare Dateien), die auf eine zentrale Datenbank zugreifen. Obwohl ich ihn immer wieder damit aufziehe dass es schon so alt ist, ist es doch der viel geliebte "Traktor", der alle Betriebssystemupdates (Windows XP, Windows 7) überstanden hat und immer noch einwandfrei funktioniert.
Bis heute.

Seit heute Vormittag spuckte ein bestimmtes Modul (die Detailauswertung) den gefürchteten Fehler "6-Überlauf" aus und verweigerte den Start. Alles andere lief aber immer noch tadellos. Das Problem musste behoben werden, soviel war klar. Doch zuerst musste die grundlegende Frage "wieso genau dieses Modul?" geklärt werden. Mein Bürokollege vermutete, dass ein kürzlicher Systemabsturz die Ursache sein müsse, da das Programm seither nicht mehr funktionierte. Für mich war die wichtigste Frage: wurde ein neues Programm installiert, oder die Rechnerkonfiguration in irgendeiner Weise verändert? Nein, es war eigentlich alles beim Alten geblieben. Okay, bis auf den neuen, zweiten Monitor, aber der schied als Fehlerquelle ja wohl aus. Oder?

An dieser Stelle rufe ich mir immer wieder einen kleinen Vorfall bei meinem vorherigen Arbeitgeber ins Gedächtnis, als ein Druckertreiber dafür verantwortlich war, dass unter bestimmten Umständen Videos auf einem System nicht abgespielt werden konnten. Mal funktionierte es, mal wieder nicht.

Im Fall des Zeiterfassungsprogramms hatte ich bereits einen konkreten Verdacht, der den nagelneue Monitor zum (indirekt) Schuldigen erklärte. Man stelle sich jetzt bitte kurz mal das Gesicht meines Bürokollegen vor, als ich ihm mitteilte, sein Monitor sei mit 27 Zoll zu groß für das Programm. Bewiesen war meine Vermutung schnell: wurde das Programm auf dem kleineren 23 Zoll Monitor gestartet, lief alles ohne Probleme. Das Ganze auf dem größeren Monitor wiederholt, führte sofort zum Absturz des Programms. Aber nur, wenn das Programmfenster über eine gewissen Punkt hinaus vergrößert wurde (unglücklicherweise startet sich dieses Programm standardmäßig maximiert und das lässt sich auch mit keiner bekannten Einstellung ändern *seufz*). Schuld daran war (und ist) ein unsauber geschriebenes Bitmap-Display, das für die grafische Darstellung der Auswertung verwendet wird. Dieses Display wächst proportional mit dem Programmfenster. Erreicht es einen Punkt der über die Größe des Bitmaps hinaus geht, wird versucht in den nachfolgenden Speicher zu schreiben, was ein Zugriffsfehler und damit ein legitimer Grund für den Absturz ist.

Leider haben die Entwickler des Zeiterfassungsprogramms nicht an die Möglichkeit gedacht, dass Monitore einmal so groß werden könnten (immerhin hat dieses Monster eine Auflösung von 2560x1440 Pixel). Fairerweise muss man dann aber auch das Alter der Software berücksichtigen. Vor 12 Jahren war bei etwa 1600x1200 Pixel Schluss. Das war dann aber auch der High-End-Bereich. Dennoch hätte man bereits damals bei einer gewissen maximalen Vergrößerung abriegeln, oder eine Speicherbereichsprüfung einbauen können.
03/03/2014 - 7:40pm

Comments

Ich
03/03/2014, 9:24pm
Nach 12 Jahren kann man dem Entwickler aber keinen Vorwurf mehr machen.
Vorwürfe kann man nur dem Benutzer machen - nach 12 Jahren kann man auch mal etwas Geld in die Hand nehmen und sich neue Software kaufen.
KIENI
03/03/2014, 10:52pm
Wenn der Preis akzeptabel ist, ja. Wenn er aber - wie in diesem Fall - einfach nur utopisch ist, verstehe ich den frustrierten User.
besucher
03/04/2014, 9:35am
ich nehme mal an dass unter windows gearbeitet wurde. verhindert das gdi im normalfall nicht genau solche fehler durch region-clipping?
KIENI
03/04/2014, 5:29pm
Uuh, gleich so technisch? Du hast Recht, es ist Windows. Es trifft aber auch auf Linux, MacOS und andere Betriebssysteme zu.
Das GDI ("Graphics Device Interface" für Außenstehende) verwendet (fast) immer eine Clipping-Region um das zu verhindern. Aber in diesem speziellen Fall wird ein Bitmap der Größe X*Y angelegt und die Zeichenoperationen direkt darauf ausgeführt, weil das GDI - entschuldige Microsoft - a****langsam ist. Damals kannte man Direct2D eben noch nicht. Versucht man nun also einen Pixel zu zeichnen der außerhalb dieser Region liegt, befindet man sich in nicht zugesichertem Speicher. Man verursacht also eine Speicherverletzung und das Betriebssystem reagiert damit, dass das Programm abgewürgt wird.
besucher
03/07/2014, 4:51pm
da spricht wohl jemand aus erfahrung?
KIENI
04/17/2014, 3:19pm
Kann man so sagen

Write a comment