Seit einigen Tagen gibt es wohl wohl Probleme mit der Microsoft Visual C++ Redistributable, die unter Windows die ODBC-Anbindung stört. Das wirkt sich auf diverse Anwendungen (DATEV, SFirm, Lexware etc.) aus, die nicht mehr funktionieren. Ein Entwickler hat mir seine Erkenntnisse aus einer Analyse zukommen lassen. Ich stelle diese mal hier im Blog ein – vielleicht hilft es anderen Software-Entwicklern bei der Lösung der Probleme.
Anzeige
Rückblick: Worum geht es?
Ein Update der Visual C++ Redistributable macht wohl Probleme mit einer in verschiedenen Software-Produkten verwendeten Datenbank-Anbindung über den Windows ODBC-Treiber.
Beim Zugriff auf auf Datenbanken kommt es zu dem Fehler "Ungültiges Datumsformat" oder "invalid date format", wobei die Meldung je nach ODBC-Treiber-Version variieren kann. Zwei Blog-Leser haben mich unabhängig voneinander informiert, dass dieses Problem verschiedene Software-Produkte betrifft. Erwähnt wurden DATEV-Anwendungen (Steuerberater), die von Firmen eingesetzte Finanzsoftware SFirm der Sparkassen, aber auch die Software von Lexmark.
Genannt wurden mir die Visual C++ Redistributable-Versionen 14.42.34438.0 und die Microsoft Visual C++ Redistributable for Visual Studio (14.44.35112). Ich hatte das Ganze im Blog-Beitrag Probleme mit Visual C++ Redistributable und ODBC – DATEV und SFirm betroffen beschrieben.
Analyse eines Entwicklers
Blog-Leser Dieter G. hat mich zum 16. Mai 2025 auf Grund meines obigen Beitrags kontaktiert. Er hat eine eigene MFC-Anwendung entwickelt, so dass der zum 15. Mai 2025 die ersten Anfragen von Anwendern mit Problemen bekam. Dieter bedankte sich für meinen Blog-Beitrag, weil so auf das Thema hingewiesen wurde. Nach Lektüre des Beitrags hat er dann eigene Tests gefahren und schrieb mir "Vielleicht helfen meine folgenden Tests weiter".
Anzeige
Laut Blog-Leser hat sich bei seinen Tests herausgestellt, dass diese Fehler in seiner MFC-Anwendung mir alle mit der Datumsklasse COleDateTime zusammenhängen. Zur Eingrenzung des Problems hate er eine kleine Testanwendung erstellt. Die folgenden Zeilen beschreiben das Problem.
COleDateTime oledateToday = COleDateTime::GetCurrentTime(); CString strToday; strToday = oledateToday.Format( (LPCTSTR) "%Y%m%d"); AfxMessageBox(strToday);
Der Abruf der Systemzeit des Rechners funktioniert laut Leser zwar noch mit der Anweisung:
COleDateTime::GetCurrentTime();
Die formatierte Ausgabe mit oledateToday.Format produziert allerdings einen String mit japanischen (Kanji) Schriftzeichen (siehe folgender Screenshot).
Der Text im Dialogfeld heißt übersetzt 'Extensive research'. Der Leser hat dann Tests mit dem kleinen Programm gefahren und schreibt, dass das Problem bei den folgenden MFC-Varianten auftritt:
MFC Unicode x64
MFC Unicode x32
MFC MBCS x64
MFC MBCS x32
Bei seinen x86-Installationen hat er das Problem vorerst wie folgt gelöst:
- Das 'Visual C++ 2015-2022 Redistributable (x86) – 14.44.35112' wird deinstalliert.
- Die DLL mfc140.dll wird manuell aus dem Verzeichnis c:\windows\SysWOW64 gelöscht.
- Das 'Visual C++ 2015-2022 Redistributable (x86) – 14.42.34438' wird installiert.
Im Anschluss sollte die MFC-Anwendung wieder funktionieren. Vielleicht hilft der Ansatz anderen Betroffenen und Software-Entwicklern weiter. Danke an den Leser für die Ergänzung.
Anzeige
Hat dieses Setting Einfluss auf das Ergebnis?
Windows Settings > Time & language > Language & region > Administrative language settings > Change system locale, and check Beta: Use Unicode UTF-8 for worldwide language support
Wir haben schon vor längerer Zeit dies (fast) überall aktiviert und sehen weniger Problem.
wenn man die Einstellung nur fände… ich meinen Gruppenrichtlinien kommt kein passendes Ergebnis, wenn ich z.B. nach 'Unicode' suche.
kannst Du das genauer beschreiben?
Es ist keine Beschreibung einer Gruppenrichtlinie. Eine solche kann ich auch nicht finden. So kann die Option eingeschaltet werden:
Systemsteuerung (die alte)
> Region
> Reiter Verwaltung > "Gebietschema ändern"
> Option "Beta Unicode UTF-8 für die Unterstützung weltweiter Sprachen verwenden" aktivieren.
Sollte mit W10 und W11 so klappen.
Nee, das behebt das Problem in Lexware Programmen zumindest nicht.
jetzt habe ich etwas dazu gefunden. in der Registry unter
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage
gibt es die Einträge ACP, MACCP und OEMCP. Ohne den Haken stehen die auf 1252,10000 und 850 und mit der Unicode-Unterstützung alle auf 65001.
das kann in CMD-Fenstern interessant werden…
Die Option gibt es bei Server 2016 noch nicht, erst ab 1809/Server 2019. Verschiedene Programme haben mit der gesetzten Option Darstellungsprobleme. Da es hier um Codepages geht, kann ich mir nicht vorstellen, dass das Einfluss auf ODBC-Verbindungen hat.
Und das ist nicht das erste Ärgernis mit der MFC. Von daher sollte man versuchen seine Programme anzupassen, dass sie mit dieser VC-Runtime-Version auch funktionieren. Ich denke, dass die neue Version des Visual Studio (17.14?) diese Runtime mitbringen wird.
Ach ja: VEEAM mit MSSQL als Datenhaltung hat keine Probleme, ebenso wenig wie Diamant-Rechnungswesen oder Starke-DMS, die ein Kunde (der mit S-Firm) im Einsatz hat, oder WSUS
Welche Werte (als Zahl) haben denn die Unicode-Zeichen aus dem Screenshot? Steckt da vielleicht was drin, was mit dem dem Zeitpunkt der Screenshoterstellung zusammenpasst?
Entschuldigung, aber so hat das überhaupt noch nie funktioniert. Es muss heißen:
strToday = oledateToday.Format( TEXT("%Y%m%d"));
Das stimmt.
In meinem MBCS-Test-Programm ist _T zwar nicht erforderlich, allerdings habe ich beim Ändern der Projekteinstellungen zwischen _unicde und mbcs und wieder zurück usw. dann wohl Fehler gemacht und natürlich _T vergessen (siehe auch meinen Kommentar unten).
OT | Kleiner Hinweis: Chinesische Schriftzeichen erkennt man i.d.R. daran, dass sie aussehen, als würden sie in einem (unsichtbares) Quadrat geschrieben sein.
Es ist etwas schwer zu erkennen, aber der Schriftzug dürfte Japanisch sein, wobei das erste und vierte Schriftzeichen ziemlich sicher chinesische Schriftzeichen sind, das Zweite dürfte ein Japanisches sein und das Dritte wiederum relativ sicher wieder ein Chinesisches.
PS Was mir gerade noch eingefallen ist: Waren oder sind nicht Windows Updates mit Problemen bei japanischer Eingabemethode erschienen? Hängt vielleicht zusammen!? (Doch kein OT dann! :D)
Ich wuerde ja weniger falsche Lokalisierung vermuten als vielmehr ein falsches Zeichen-En-/Decoding, aka Mojibake: https://en.wikipedia.org/wiki/Mojibake
Ich muss mich leider korrigieren:
Die Rückschlüsse aus der formatierten Ausgabe von COleDatetime::Format waren leider fehlerhaft.
Ich habe bei meinem schnellen Test vergessen das Makro '_T' den Parametern "%Y%m%d" voranzustellen.
In meinem MBCS-Test-Programm ist _T zwar nicht erforderlich, allerdings habe ich beim Ändern der Projekteinstellungen zwischen _unicde und mbcs und wieder zurück usw. dann wohl Fehler gemacht.
Jetzt zurück zu meinem Programm.
Ich erhalte direkt beim ersten Änderungsaufruf per ODBC-Treiber den Fehler
'…Ungültiges Datetime-Format (null)'.
Der Workaround mit der Installation der Runtime-Version 14.42.34438 ist nach wie vor gültig und funktioniert.
Das Problem kann aber auch vorübergehend behoben werden, indem die DLL mfc140.dll mit der Versionsnr 14.42.34438,0 direkt in das Verzeichnis kopiert wird in dem sich die eigene Exe-Datei befindet, die diese DLL benötigt.
Dies ist zwar nicht ganz so gut, da wir dann in die Zeiten der mfc42.dll zurückfallen, aber…
Bei diesen Workarounds muss auch darauf geachtet werden, dass es jeweils eine x32 und eine x64 Variante gibt, die unterhalb des Windows-Verzeichnisses jeweils in anderen Verzeichnissen (c:\windows\System32, c:\Windows\SysWOW42) ersetzt werden müssten.
Test einer Datenbankanwendung mit Visual Studio 2022 17.14.0
Auf einem Testsystem habe ich jetzt die neueste VisualStudio 2022 Version 17.14.0 installiert und einen Teil des Datenbank-Source verwendet, der oben zu '…Ungültiges Datetime-Format (null)' führt.
Wenn ich jetzt dieses Programm compiliere funktioniert der Datenzugriff, ein vorhandener Datensatz Datensatz lässt sich ändern und speichern, in der Datenbank kommt auch das gewünschte an.
Allerdings lässt sich eine andere Tabelle (mit anderen Feldern) nicht filtern, bei der Suche nach einem Datensatz zur Änderung wird dieser nicht gefunden, es wird stattdessen ein neuer angelegt.
Dies könnte den Schluss zulassen, dass eine Anwendung die mit Visual Studio 17.14 und der neuen DLL 14.44 compiliert wird, zumindest nicht alle Fehler produziert.
Danke für die Analyse. Evtl auch interessant wegen der Nebenwirkungen:
ich habe gerade das neue SSMS 21 installiert und feststellen müssen, dass es auf dem VS17.14 basiert und daher auch die VC-Runtime 14.44 mitbringt.
Noch ist es ja nicht dringend diese Version zu verwenden, die braucht es erst für den SQL-Server 2025 und der ist noch gar nicht fertig.
Bin ja gespannt wann MS das Problem in den Griff kriegt, denn es kann ja nicht sein, dass alle ihre Programme mit VS17.14, die keine ESR ist, neu bauen müssen.
Ist endlich "under investigation" bei Microsoft mit mehreren geschlossenen "closed duplicates":
https://developercommunity.visualstudio.com/t/Problem-stoering-COleDateTime-with-RFX_D/10904635
Überraschung: mittlerweile ist die Hilfeseite auf 14.44… aktualisiert, beim Download kommt aber die vorige 14.42…
Auch über Evergreen kommt entsprechend die 14.42., nur bei Winget steht noch die 14.44.35112.1 als verfügbar
Sieht so aus als ob die kaputte Version von MS zurückgezogen wurde.
vgl auch die fortgeschrittene Diskussion unter dem Link oben.
Soeben wurde die Version 14.44 (x86) auch bei Winget zurückgezogen. Finally!
seit heute Nacht gibt es einen neuen Versuch mit der Version 14.44.35208.0
auf allen mit bekannten Kanälen (Winget, Evergreen, Download über offizielle Seite)
Das Problem soll mit Version 14.44.35208.0 der Microsoft Visual C++ 2015-2022 Redistributables behoben sein.
Siehe auch:
https://developercommunity.visualstudio.com/t/Problem-stoering-COleDateTime-with-RFX_D/10904635
Direkter Download der aktuellen Version:
https://github.com/abbodi1406/vcredist/tree/master/source_links