Programmieren – Martins Blog

WebView2 Build 120 zerstört COM-Infrastruktur

Wieder mal eine tolle Geschichte wie Kunden auf uns als Softwarehersteller sauer werden, weil Microsoft ein nicht funktionierendes Update veröffentlicht.

Die Story:

Wir nutzen intern COM für sehr viele Objekte, um unsere eigene Software via VB-Script zu steuern.
Wir haben auch die Möglichkeit Controls vom Typ WebView2 anzulegen.
Am 07.12. veröffentlichte Microsoft für den WebView2 den Build 120.
Unsere Software benutzt im Allgemeinen „Evergreen“, d.h. es wird immer die aktuelle WebView2 ohne eigne Installation benutzt.

Effekt:
Seit dem Update kann man nach dem, ein WebView2 Fenster zerstört wurde, keine COM Class Factory in unserem Programm aufrufen.
Intern scheint das WebView2 CoSuspendClassObjects aufzurufen wenn das Control zerstört wird. Die Folge unser IMessageFilter springt an und es kommt ein Dialog, der auf einen nicht reagierenden COM Server hinweist.

Der nicht reagierende COM-Server ist unsere eigene Anwendung… 😯

Toll! 😥

Einziger für uns möglicher Workaround für uns ist leider, die alte Version 119 auf jedem Client lokal zu installieren. Dann über einen Registry Eintrag (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\WebView2\BrowserExecutableFolder) den Aufruf von der aktuellen Version umzubiegen.
Netterweise kann man das für jede Anwendung separat steuern.

Details zum Nachlesen auf GitHub.

Nachtrag: Der Bug verschwand mit dem Update 120.0.2210.77 in der evergreen Version. Bei mir wurde der Fix am Montag den 18.12.2023 automatisch installiert.

VS-2022 Rollback deinstalliert manche VS-Extensions

Leidvoll musste ich erleben, dass ein Visual Studio 2022 Rollback auf die ältere vormals installierte Version leider auch einige VS-Extensions deinstalliert. Bzw. diese gehen verloren.

Man sollte also einen Rollback mit Vorsicht verwenden. Er eignet sich also nicht einfach und schnell ein Problem zu umgehen. Es sind einige Nacharbeiten nötig.

VS-2022 Update 17.8 zerstört Mixed Mode Debugger-Funktionen „Unable to step. Operation not supported. Unknown error: 0x8ede0018.“

In der letzten Zeit habe ich regelmäßig die aktuellsten Visual-Studio 2022 installiert. Ich muss ehrlich sagen, dass ich seit VS-2029 nicht einmal schlechte Erfahrungen gemacht habe.
Das hat sich mit dem heutigen Tag geändert 🙁 !

Nach der Installation des Updates ging keine Step-Debug-Funktion mehr (Step-In, Step-Over, Step-Out, etc.) im Mixed Mode Debugging. Native Mode Debugging scheint zu gehen.

Egal was man macht man bekommt den Fehler:

Unable to step. Operation not supported. Unknown error: 0x8ede0018.

In der Developer Community für VS ist dieser Bug auch bereits bekannt und angeblich gibt es einen Fix. Der ist aber noch nicht öffentlich.

Leider arbeite ich an einigen C++/CLI Modulen und benötige den Mixed-Mode.

Das erste mal habe im Visual Studio Installer einen Rollback versucht. Leider hat der Rollback meine Extension zum Teil deinstalliert. Mein Visual Assist von Whole Tomato war auf einmal nicht mehr vorhanden. Toll… 😯

Nachtrag: Das Problem ist in der Version 17.8.4 behoben, die am 10.01.2024 veröffentlicht wurde.

Note 1 für den Support von Schaudin / RC-WinTrans

Seit Jahren benutzen wir RC-WinTrans von Schaudin.com für unsere die Multilinguale Unterstützung unserer Software.

Durch eine Änderung in VC-2019 16.3.3 wurden nun RC Dateien nicht mehr ANSI Codepage 1252 gespeichert sondern grundsätzlich als UTF-8 Dateien. D.h. alle RC Dateien, die nicht in UTF-8 oder UTF-16 vorliegen, werden zwangsweise in UTF-8 konvertiert.

Jetzt hatten wir ein Problem. Unsere Tools von Schaudin (RC-WinTrans) können kein UTF-8 in der von uns genutzten Version. Zuerst habe ich bei Microsoft einen Case zu öffnen, weil so ein erzwungenes Encoding ist für mich ein No-Go.

Eine Anfrage in Stackoverflow brachte keine Erkenntnis außer, das das Problem ist bereits bekannt unter mehreren Incidents
Link1, Link2, Link3

Also habe ich mich an den Support von Schaudin gewandt. Neuere Tools können zwar kein UFT-8 aber UTF-16 verarbeiten. Also müssen wir eben ein Update kaufen.
Nach einigen Emails hin und her bot mir Schaudin an, die nächste Version nach meiner (die auch UTF-16 unterstützt) kostenlos zu erhalten.

Ich bin etwas sprachlos! So etwas (kostenlos) auf die nächste Version, ist doch nicht so ganz üblich in unserer Welt.

Ich sage Danke und gebe der Firma Schaudin die Note 1 in Kulanz und Support.

Sieh mal an: SetFilePointer und SetFilePointerEx sind eigentlich überflüssig, wenn man ReadFile und WriteFile verwendet…

Man lernt nie aus, bzw. man hat vermutlich nie die Dokumentation vollständig und richtig gelesen.

Wenn man eine Datei nicht sequentiell liest ist es normal Seek, Read/Write in dieser Folge zu nutzen. Order eben SetFilePointer, ReadFile/WriteFile.

In einer StackOverflow Antwort stolperte ich über die Aussage:

you not need use SetFilePointerEx – this is extra call. use explicit offset in WriteFile / ReadFile instead

(Rechtschreibung nicht korrigiert).

Aber der Inhalt war für mich neu. Sieh mal an, selbst wen man kein FILE_FLAG_OVERRLAPPED benutzt, kann man die OVERLAPPED Struktur nutzen und die darin vorhandenen Offsets verwenden.
Diese werden sogar netterweise angepasst, nachdem gelesen/geschrieben wurde.

Zitat aus der MSDN (der Text ist gleichlautend für WriteFile):

Considerations for working with synchronous file handles:

If lpOverlapped is NULL, the read operation starts at the current file position and ReadFile does not return until the operation is complete, and the system updates the file pointer before ReadFile returns.

If lpOverlapped is not NULL, the read operation starts at the offset that is specified in the OVERLAPPED structure and ReadFile does not return until the read operation is complete. The system updates the OVERLAPPED offset before ReadFile returns.

Sicherheitsupdates von Microsoft führen zu Problemen mit dem ODBC Export nach Excel

Eigentlich habe ich nichts gegen Sicherheitsupdates. Genaugenommen bin ich ein Verfechter, dass Sicherheitsupdates sofort und umgehend installiert werden sollen.

Eigentlich ging das die letzten Jahre bei unserer Software ziemlich gut. Aber heute hat es uns voll erwischt. Dazu auf allen Plattformen von Windows 7, Windows 8.1 bis Windows 10.

Es kommt jetzt beim Anlegen einer Excel Datei über ODBC zu einer Fehlermeldung in der Form:

Reservierter Fehler (-5016); es gibt keine Meldung für diesen Fehler.
Ungültiges Attribut für die Verbindungszeichenfolge. CREATE_DB
Ungültiges Attribut für die Verbindungszeichenfolge. CREATE_DB
Ungültiges Attribut für die Verbindungszeichenfolge. CREATE_DB
Ungültiges Attribut für die Verbindungszeichenfolge. CREATE_DB
Allgemeine Warnung Registrierungsschlüssel ‚Temporary (volatile) Jet DSN for process 0x2c44 Thread 0x37f4 DBC 0x5b84d54 Excel‘ kann nicht geöffnet werden.
Ungültiges Attribut für die Verbin

Aktuell kann ich die Ursache nur in den folgenden Windows Updates sehen:

Windows 7	KB4041681
Windows 8.1	KB40416393
Windows 10	KB4040724 KB4041676

Einen entsprechenden Anfrage an andere Entwickler habe ich über Stackoverflow gestellt.

Als exMVP oder rMVP hat man jedoch nicht mehr die schönen Kanäle von früher… <seufz/> 🙁

Ich frage mich, wie solche Fehler durch eine Qualitätskontrolle schlüpfen können…?

Fehler in ATLTHUNK.DLL führt auf Windows 10 (64bit) unter bestimmten Umständen zu zufälligen Crashes von Anwendungen

Wer es schnell mag, kann gleich den Beitrag und technische Details auf Stack Overflow lesen:
http://stackoverflow.com/questions/41741448/random-crashes-on-windows-10-64bit-with-atl-subclassing

Hier möchte ich etwas ausführlicher, die Story dazu erzählen, eine Story aus dem ganz „normalen“ Leben eines Programmierers 😉

Letztes Jahr stellen wir in der Firma produktiv von VC-2013 auf VC-2015 um. Wir haben eine relativ große Anwendung, die im Kern, MFC und ATL verwendet. Unsere Anwendung zeigt Informationen in vielen Tabs und Dialogen an. Mehr als 256 Fenster sind da keine Ausnahme und eher die Regel als eine Seltenheit.

Unsere Anwendung erzeugt bei Crashes automatisch volle Dumps auch bei Kunden. Für unsere Qualitätssicherung ein Muss und ein Segen.
Bereits in der Alpha und Beta Phase hatten wir auf manchen Rechnern ein eigentümliches Phänomen. Unser Programm startete und erzeugte Fenster und auf einmal kam es zu einem Absturz bei oft ganz einfachen Windows API Funktionen, die ein Fenster verwendeten und die alle ausnahmslos letzten Endes dazu führten, dass eine Nachricht an ein Fenster gesendet wird. Der Stack war nichtssagend und schien zerstört. Die Dumps für die einzelnen User waren aber fast immer glich.
Das Problem trat in Release und Debug Builds auf.

Der Horror für jeden Programmierer. Nicht nachzuvollziehende Crashes auf manchen Rechnern. Heapfehler? Wilder Zeiger? Buffer-Overrun? Nichts was man gebrauchen kann… aber kein Analysetool was wir verwendeten schlug Alarm…

Nach Sammlung von mehreren Dumps waren die Crashes immer wieder an ähnlichen Stellen und fast immer alle sofort nach Programmstart. Betroffen in der Regel alles Windows 10 64bit Maschinen auf dem aktuellen Softwarestand, meistens hatten diese Maschinen 8GB und zum Teil weitaus mehr Speichern und es waren ausnahmslos schnelle Intel i7 verschiedener Generationen. Und in virtuellen Maschinen konnte ich das bisher nicht nachvollziehen.

Interessant, war, dass ich diese Crashes auch auf meiner Entwicklungsmaschine hatte. Manchmal…
Nach einigen Tests konnte ich sagen. Entweder tritt der Fehler auf und solange der Rechner gestartet ist kann man es manchmal nachvollziehen, oder der Fehler tritt eben nicht auf und man hat Ruhe vor ihm. Dann hatte ich mir 3 Tage hintereinander – ohne Rechnerneustart – mit Debug-Session auf Debug-Session eine Spur erarbeitet. Es war immer das 257 Fenster, dass gesubclassed wurde (mit ATL Thunking) oder erzeugt wurde (ATL Fenster), dass zum Crash führte.
Insofern war es bei jedem User auch immer ein ähnlicher Dump, weil der Fensteraufbau ja bei jedem User individuell war.

Am Ende des dritten Tages hatte ich einen Testcode, der den Fehler in der aktuellen Windows Session meines Rechners und meinen Programm zu 100% nachvollziehbar machte. Ich verschob den Testcode immer weiter in einem Programm nach vorne, bis ich bei InitInstance ankam.
Ups. Es liegt nicht an meiner Software.
Dann isolierte ich den Testcode in eine eigenes Programm und konnte den Bug in einem minimalen Sample nachstellen.

Zeit für einen Support-Case bei Microsoft und eine Anfrage auf stackoverflow.com (das war am 19.01.2017).

Mit dem Case hatte ich natürlich auch einen Workaround. Ich musste nur einfach die atlthunk.dll nicht benutzen und auch das ging mit einer einfachen Änderung in der atlstdthunk.h. (Auskommentieren des defines USE_ATL_THUNK2).

Die Kommunikation mit Microsoft gestaltete sich nicht einfach. Aber ich hatte zumindest einen konstruktiven MS Mitarbeiter aus Indien erwischt. Dumps konnte ich Microsoft liefern, auch den Crash direkt in einer Session zeigen. Code hatten sie auch, aber der Bug war bisher nicht bei Ihnen nachvollziehbar. Das trieb mich fast in die Verzweiflung. Natürlich musste alles andere ausgeschlossen werden.. Virenscanner, andere Software… etc…
Dennoch kein Repro auf eine Microsoft Maschine. Allerdings weiß ich nicht wie „intensiv“ da gesucht wurde.

Dann endlich ein Lichtblick auf stackoverflow.com. Eugene konnte den Bug nachvollziehen. Endlich.
Und nachdem ich wusste, dass es mit der bevorzugten Ladeadresse zu tun hatte, konnte ich auch meinen Code erweitern und mit 100% Wahrscheinlichkeit den Crash erzeugen.
Wenn also an der bisher bevorzugten Ladeadresse der atlthunk.dll kein Speicher zur Verfügung liegt und sofort wieder eine Relocation notwendig wird, dann kracht es. Lustig, da wir ja durch ASLR sowieso keine festen Ladeadressen haben, aber es gibt innerhalb einer Windows Session dennoch eine „bevorzugte Ladeadresse“.

Jetzt bin ich gespannt auf Microsoft…
Denn defakto kann jede Software die mit dem VC-2015 und VC-2017 Compiler und der ATL kompiliert wurde von diesem Problem betroffen sein.

PS: Man entschuldige mir Ungenauigkeiten oder auch falsche Begrifflichkeiten…
Bis heute habe ich den Fehler immer noch nicht ganz verstanden und ganz sooo tief lebe ich im Kernel von Windows doch nicht. 😀

PPS: Ich werden den Artikel auf stackoverflow.com aktuell halten.

Nachtrag 01.03.2017:

Microsoft hat bestätigt, dass es sich um um einen Bug handelt.
Der Bug soll in der nächsten Windows 10 Version (RS2) gefixed sein.
Nachteil: Ich werde wohl mit der Änderung der ATL leben müssen, denn auch andere Windows Versionen sind von diesem Fehler betroffen.

SHA1 und SHA256 Codesigning mit SIGNTOOL und einem Timestamp

Ihr seid vielleicht auch betroffen und nutzt bisher Code Signing für Eure Software oder MSI Pakete.
Ich zumindest habe von Symantec (ehemals Verisign) für unsere Zertifikate zum Jahresende eine Email bekommen, die mir empfiehlt zukünftig sowohl SHA1 als auch SHA256 zu nutzen. Entsprechende Links wurden mitgeliefert. (1) (2)(3)(4)

Ich habe also erstmal das bisherige Codesigning SHA1 Zertifikat als SHA256 Zertifikat neu ausgeben lassen. Das ganze war kostenlos über die Symantec Seite möglich und dauerte letzten Endes höchstens 30 Minuten.

Dann habe ich das neue Zertifikat im Produktionsserver installiert.
In unserem Produktionsprozess ist das Codesigning integriert. Die entsprechenden Dateien liegen in einem Quellordner und werden von unserem Produktionserver verwendet um daraus unsere Installationspakete oder Hotfixes zu generieren. Dabei werden alle Dateien entsprechend automatisch signiert.

Die entsprechende Code Passage in unserem Batch sah bisher so aus:

>signtool sign -sha1 FingerPint-SHA1-Zertifikat -fd sha1 -t http://timestamp.verisign.com/scripts/timstamp.dll myexe.exe

Da dachte ich: OK Ganz einfach, also nur eine zweite Zeile mit dem Parameter -as hinzufügen und das neue Zertifikat angeben.
Aber Pustekuchen:

>signtool sign -as -sha1 FingerPint-SHA256-Zertifikat -fd 256 -t http://timestamp.verisign.com/scripts/timstamp.dll myexe.exe
Done Adding Additional Store
SignTool Error: SignedCode::Sign returned error: 0x80070057
        Falscher Parameter.
SignTool Error: An error occurred while attempting to sign: AGVIP.exe

🙁 Nach einigem hin und her probieren und Lesen einiger Artikel, musste ich feststellen, dass die Ursache einzig und alleine in dem angegebenen Timestamp Server liegt. Der Verisign Timestamp Server mag einfach keine SHA256 Zertifikate für das Gegenzeichnen.

Die Lösung war also einfach. Ich habe einen anderen Timestamp Server benutzt und nun sehen die Befehlszeilen einfach so aus.

>signtool sign     -sha1 FingerPint-SHA1-Zertifikat   -fd sha1   -tr http://timestamp.geotrust.com -td sha1   myexe.exe
>signtool sign -as -sha1 FingerPint-SHA256-Zertifikat -fd sha256 -tr http://timestamp.geotrust.com -td sha256 myexe.exe

Und siehe da 🙂 alles funktioniert bestens und meine Programme haben nun 2 Zertifikate.

Bye Bye MVP-Award

Alles hat seine Zeit… (Prediger 3,1)

Eine kleine Ära geht für mich zu Ende. Vor kurzem erhielt ich von Microsoft die Information, dass ich dieses Jahr nicht neu zum C++ MVP nominiert werde.

Seit 2000 bis einschließlich 2014 habe ich diesen Titel insgesamt 16 mal erhalten. Über den Sinn und Zweck dieser Ehre mag man streiten. Stolz bin ich trotzdem drauf. Und gerade weil es mir mit anderen MVPs auch gelungen ist doch manchmal etwas Dampf und Druck zu machen. Z.B. damals für eine längere XP-Unterstützung, die wurde in VS-2012 Update 1 dann nachgeliefert. Obwohl ich klar sagen muss, dass die grundsätzliche Möglichkeit Einfluss zu nehmen in den letzten Jahren immer weiter abgenommen hat.

Hauptgrund ist sicherlich meine eingeschränkte Online Aktivität und auch meine nunmehr eingeschränkte Blog-Aktivität. Und um ehrlich zu sein: Ich hatte es irgendwann erwartet.

Meinen Blog werde ich deshalb nicht einstampfen und auch Online werde ich noch hier und da anzutreffen sein.
Also wird sich so viel für Euch gar nicht ändern… 😎

Universal CRT auf Windows 7, Vista und Windows 8.0/8.1 wird über Windows Update ausgerollt

Eine „Spaßbremse“ Software mit Visual Studio 2015 auszuliefern war bisher in jedem Fall das Universal CRT.

Im Speedproject.de Blog ist davon auch einiges zu lesen gewesen:
Noch kein Umstieg auf VS-2015
Anwendungslokaler Einsatz der Universal CRT
Visual Studio 2015 und die Universal CRT

Dieses Paket musste man zusätzlich mit installieren auf allen Systemen die Windows 7, Vista oder Windows 8.x verwendet haben. Die Probleme und das Nachfragen von Entwicklern hat nun Wirkung gezeigt.
Microsoft veröffentlicht den KB2999226 über Windows Update. Damit entfällt das Ausrollen mit dem eigenen Setup.

angeboten bzw. installiert wurde.

Danke für den Hinweis an Michael Külshammer. (siehe auch dotnetpro)

Nachtrag:
Bei mir erscheint jetzt auf meinen Windows 7 Rechner das entsprechende Update als optionales Update