Kurz das Wichtigste: Die Fehlermeldung „assertion failed“ von Microsoft Visual C++ Runtime Library (Line 132 in t2kstrm.c) taucht auf, wenn ein Teil der Java-Runtime-Engine (JRE) bei bestimmten in Java geschriebenen Programmen – zum Beispiel der Transkriptionssoftware F4, Version 3, unter Windows XP, aber auch bei anderen Programmen – im Windows-Schriftenordner auf Schriftarten im Format TTF stößt, die „korrupt“ sind (z.B. ungültige Verweise im Dateiaufbau, nicht ganz standardkonform). Um diese Java-Programme trotzdem zum Laufen zu bringen, ist es notwendig, diese Schriftarten zu löschen – was wiederum nicht so ganz einfach ist, wie ich selbst erfahren durfte. Was ich gemacht habe, was passiert ist, und wie ich mein System wieder zum Laufen gekriegt habe, steht unten. Wer es nachmachen möchte: auf eigene Gefahr.
* * *
Zum Transkribieren nutze ich die De-Facto-Standardsoftware F4, die es als Freeware gibt. In der Version 3 hat sie einige neue Features bekommen, und auf meinem Arbeitsplatzrechner ebenso wie auf meinem Netbook ließ sie sich auch problemlos installieren. Auf meinem Rechner zuhause nicht. Egal, wie ich es versucht habe, immer gab es eine Fehlermeldung: „Microsoft Visual C++ Runtime Library … Assertion failed“, und zwar in einer Datei „t2k/t2kstrm.c“, Zeile 132. Fehlerhaft sei „pos = t-> maxpos“. Wiederholen, Ignorieren oder Abbrechen?
F4 ist ein Java-Programm. Bis ich herausgekriegt hatte, dass die Fehlermeldung damit zu tun hatte, dauerte aber noch ein bißchen.
Zunächst einmal habe ich bei Thorsten Dresing von audiotranskription.de um Rat gefragt – der kannte das Problem nicht und meinte, ich solle halt gleich die Beta-Version 4.0 nehmen. Die lief tatsächlich, mich wurmte das aber dann doch – und die Version 3 fand ich auch praktischer und schneller als die 4.0.
Also habe ich heute abend nochmal ein paar Stunden damit zugebracht, eine Lösung zu finden.
Erste Hinweise lieferte Google: z.B. hier oder auch im Javaforum von SUN. Damit wurde schnell klar, was wahrscheinlich das Problem ist – das überhaupt nichts mit F4 zu tun hat, sondern ein Problem aller (auch der neusten) Java-Runtime-Version unter Windows (XP) ist: korrupte Truetype-Fonts bringen ein Unterprogramm, das alle vorhandenen Fonts katalogisiert, zum Absturz.
Lösung laut Netz: alle Fonts von Hand durchgehen, korrupte Fonts löschen. Habe ich gemacht, habe auch ein Dutzend Fonts gefunden, die von der Font-Anzeige nur als leer angezeigt wurden (und ganz anders hätten aussehen sollen), und diese gelöscht. Half auch nichts. Was letztlich geholfen hat, war folgendes:
Achtung: auf eigene Gefahr ausprobieren! Evtl. bietet es sich an, eine Windows/Office-Installations-CD zur Hand zu haben, da einige Fonts sich selbst neu installieren wollen!
1. in der DOS-Shell ("cmd" bei Ausführen angeben) als Administrator nach c:\windows\ wechseln
2. Ein neues Verzeichnis "ttfonts" anlegen ("mkdir ttfonts").
3. Alle Truetype-Fonts aus dem Fonts-Verzeichnis dahin kopieren ("copy fonts\*.ttf ttfonts\").
4. Alle Truetype-Fonts löschen ("del fonts\*.ttf" - gibt ein paar Fehlermeldungen bei Systemfonts).
5. Testen, ob das das Problem gelöst hat, ob also F4 (bzw. irgendeine andere javaw-Datei) ohne Fehler startet.
6.a Font-Cache löschen (siehe Kommentar von Oliver unten)
6.b Im Font-Viewer von Windows auf die Ansicht "Liste" gehen und alle mit 0 Byte angezeigten ttf-Dateien löschen (die sind eigentlich schon gelöscht, Windows glaubt das aber nicht).
7. Im Font-Viewer über "Fonts installieren" aus dem Verzeicnis c:\windows\ttfonts von Hand all diejenigen Fonts neu installieren, die wirklich gebraucht werden (Nebeneffekt: Fonts, die nicht wirklich gebraucht werden, müllen den Fonts-Ordner nicht mehr zu).
8. Rechner neu starten.
Ganz schön viel Aufwand (ich habe ungefähr 700 Dateien in c:\windows\fonts …), aber mit etwas Glück war das nicht nur für F4, sondern auch für andere Programme ein Problem – und hilft also auch generell.
Warum blogge ich das? Um zur Auffindbarkeit dieses häufigen, aber doch exotischen Problems beizutragen.
P.S.: Jetzt habe ich ein Problem mit Excel; ich befürchte, eine Nebenwirkung dieses Vorgehens. Mit Transkribieren wird das heute abend nichts mehr.
Nachtrag: Ganz so einfach ist das alles wohl auch nicht – Firefox z.B. meint jetzt, auch die gelöschten Fonts noch zu kennen – Excel macht, wie bereits erwähnt, beim Öffnen einer bestimmten Datei Probleme – und an einigen Stellen machen die fehlenden Fonts Probleme. Dafür läuft F4. Hmm.
Nachtrag 2: Vielleicht ist diese Liste der Windows-Systemfonts hilfreich – ich schaue mal, dass die alle installiert sind, vielleicht löst das ja meine neuen Probleme.
Nachtrag 3: Hmmm … warum sehen Systemschriftarten wie Georgia und Arial Narrow plötzlich teilweise „korrupt“ aus? Was ist da beim Kopieren schief gelaufen? Stay tuned …
Nachtrag 4: Nach der eigentlich nicht geplanten Neuinstallation einiger Fonts auf deren Eigeninitiative von einer System-CD hin und nach dem Löschen des Fontcache – was Oliver im Kommentar sagt – scheint alles wieder zu laufen.
Man könnte sicherheitshalber den Fontcache löschen
del c:\windows\system32\fntcache.dat
dieser wird nach einem Neustart dann erneuert.
Danke für den Tipp!
Juchu, Geektalktime ;).
Eigentlich reicht es aus, alle Schriften rauszuwerfen, die kleiner als 5Kb sind.
Falls nicht benutzt man einfach Fontagent Pro oder die Adobe Master Collection zum Ausmisten – das spart auch ansonsten recht viel Ärger.
http://www.insidersoftware.com/FA_win.php
fuer alle die die alte version besser fanden
[Link entfernt, da Download den Lizenzbestimmungen von F4 widerspricht, T.W.]