Martin Richter – Seite 2

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.

Advanced Developers Conference C++ / ADC++ 2018 in Burghausen vom 15.-16.05.2018

Am 15. und 16. Mai 2018 wird die nächste Advanced Developers Conference C++ stattfinden.
Am 14. Mai finden ganztägige Workshops statt.!

Diesmal in der Heimatstadt des ppedv Teams in Burghausen unter der bewährten Leitung von Hannes Preishuber.
Mit dem Heimvorteil des ppdevs Team darf man gespannt sein was für eine Abendveranstaltung geplant sein wird. Diese haben zumindest für mich ja schon fast einen „legendären“ 😉 Ruf und haben immer viel Spaß und Abwechslung geboten.

Diesmal sind wieder interessante Gäste geladen. Insbesondere der Bekannte Buch Autor Nicolai Josuttis sticht für mich förmlich aus der Menge der Redner heraus. Manch altes und auch neues Gesicht findet sich in der Rednerliste.

Hauptthema wird C++17 sein und C++20 befindet sich ja auch schon wieder in der Standardisierung.
Neben dem (immer wieder guten) Social-Event bei dem man viele Kollegen treffen kann und darf, werden die Vorträge sicherlich die nächsten Evolutionsstufen von beleuchten.

Und bei der mittlerweile rasanten Updatefolge in Visual Studio werden wir vielleicht auch einiges interessantes neues vom Microsoft-Sprecher Steve Caroll erfahren.

Weitere Infos unter dem Link http://www.adcpp.de/2018

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.

Advanced Developers Conference C++ / ADC++ 2017 in München am 16.-17.05.2017

Am 16. und 17. Mai 2017 wird diesmal im Microsoft Hauptquartier in München die nächste Advanced Developers Conference C++ stattfinden.

Hannes Preishuber und sein bewährtes ppedv Team richten wieder eine Konferenz zu C++ aus.
Ich bin gespannt was wohl diesmal an der Abendveranstaltung am Dienstag geplant sein wird. Diese haben zumindest für mich ja schon fast einen „legendären“ 😉 Ruf und haben immer viel Spaß und Abwechslung geboten.

Neben dem (immer wieder guten) Social-Event bei dem man viele Kollegen treffen kann und darf, werden sicherlich wieder einige gute Vorträge über die nächsten Evolutionsstufen C++17 und C++20 zu erwarten sein. Und ich tippe mal das auch einige Microsoft Sprecher zu hören sein werden (wenn denn es schon bei Microsoft stattfindet). Ich bin gespannt was es vielleicht auch neues mit Microsoft in Verbindung mit C++ zu hören geben wird.

Mehr dazu unter dem Link http://adcpp.de/2017

Samsung S4 (I9500 und I9295) mit Android 5.01 stürzen ab, wenn man die Google Kontoeinstellungen bearbeiten will

Vor über 2 Monaten fing es an. Nach irgend einem Update konnte ich auf einmal die Kontoeinstellungen meines Google Accounts auf meinem Samsung S4 Active mit Android 5.01 nicht mehr erreichen. Einstellungen -> Konten -> Google und Crash, Anwendung wird angehalten.

Relativ schnell fand ich Leidensgenossen im Netz, denen es genauso geht. Der häufigste Kommentar der Experten war: „Warten auf ein neues Google-Play-Store Update“. Andere setzten tatsächlich ihr Handy zurück und machten die wildesten Klimmzüge. Resultat war: Nach dem nächsten Update lief es wieder nicht.

Bis dato war es mir erstmal egal, aber jetzt wollte ich doch eine Einstellung ändern. Also noch mal gegoogelt und gleich in mehreren Threads einen simplen Workaround gefunden, wie man doch an sein Konto kommt und den Tipp möchte ich Euch auch gerne zukommen lassen:

Einfach Gallerie App öffnen
Einstellungen auswählen
Und da findet man auch das verwendete Google Konto.

Hier stürzt nichts ab und man kann die entsprechenden Einstellungen vornehmen.

Siehe unter anderem hier und auch hier.

Bug im Outlook 2016 Update 16.0.6568.2025: Per POP3 werden wiederholt immer wieder Emails empfangen

Am Donnerstag Abend wunderte ich mich schwer. Auf einmal zeigte mein Outlook an, dass es noch 200 Emails herunterzuladen gäbe. Dann noch einmal 180. IWe ich leider feststellen musste warn alle diese Emails doppelt herunter geladen worden und erstreckten sich auf einen Zeitraum von ca. 2-3 Monaten. Eine Kontrolle ergab, dass es alle Emails waren, die noch bei meinem ISP in den Mailboxen lagen.

Zwei meiner Konten, die ich per POP3 ansteuere wurden in der Folge immer wieder herunter geladen. Ich vermutete erstmal einen Fehler bei meinem Provider, aber dem war nicht so. Zudem passierte das nun auch noch immer wieder mal. Eine Regel konnte ich nicht feststellen.

Erstmal machte ich mich ans Aufräumen. Also automatisches Abholen ausgeschaltet. Dann habe ich einfach die Spalte Geändert in der Listenanzeige in Outlook mit eingeblendet. Damit konnte ich sofort alle Emails ausmachen, die zuletzt heruntergeladen wurden. Einfach nach der Spalte sortieren und man hat alle Emails beisammen. Hat man allerdings Regeln wird es etwas komplizierter, aber hier kann die erweiterte Suche helfen. Die doppelten Emails waren dann auch schnelle gelöscht.

Nachdem ich die Google Suche nach dem Thema auf Einträge des letzten Monats eingeschränkt hatte, kam ich auch schnell zu einem Treffer in den Microsoft Communities im den englischen Foren sowie hier und auch in den deutschen Foren. Umstellen auf IMAP kam nicht in Frage und so versuchte ich die Lösung aus dem englischen Forum.

Ich musste feststellen, dass ich die neueste Version 16.0.6568.2025 auf meinem Rechner befand.

Outlook Updates abstellen.
Befehlszeile (CMD.EXE) als Admin ausführen.
Dann folgenden Befehl ausführen:

"C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeC2RClient.exe" /update user updatetoversion=16.0.6366.2068

Die detaillierten Schritte, falls das alte Update nicht mehr im Cache sind finden sich hier unter Punkt 6.

Erstmal hat es nicht geholfen. Dann einen Neustart ausgeführt und anschließend war die Version 16.0.6366.2068 wieder installiert.
Jetzt verhält sich Outlook wieder korrekt.

Microsoft arbeitet angeblich an dem Problem. Ich werde die Threads mal beobachten und sehen was sich tut. Vorerst bleiben die Office Updates ausgeschaltet.

Nachtrag 29.02.2016:
Jetzt ist ein offizieller KB-Artikel dazu erschienen: https://support.microsoft.com/de-de/kb/3145116

Schwerwiegender Fehler Ihr Menü „Start“ funktioniert nicht. Wir beheben das Problem, sobald sie sich erneut anmelden.

Ich hatte relativ schnell nach Veröffentlichung von Windows 10 auch meinen Produktivrechner umgestellt. Hier war sowieso ein Hardwaretausch nötig und da ich Windows 10 schon auf meinem Laptop hatte und es mir gut gefiel, habe ich auch gleich neu installiert. Und ich habe es eigentlich auch nicht bereut.

Die Freude am neuen System währte exakt 2 Wochen und ich bekam nach Neustart des Rechners wegen eines Updates den folgenden Fehler. 🙁

Schwerwiegender Fehler Ihr Menü „Start“ funktioniert nicht. Wir beheben das Problem, sobald sie sich erneut anmelden.

Jetzt Abmelden

Schwerwiegender-Fehler

Ich habe natürlich das Update deinstalliert aber das nützte mir nichts. Das Problem lag auch nicht am Rechner, sondern einzig an meinem Benutzerprofil, denn alle anderen Profile auf dem Rechner zeigten keine Probleme. Also war vermutlich auch das Update nicht die Ursache. 😕
Nachdem ich einiges ausprobiert hatte was auch so im Internet dazu stand, habe ich einfach den Microsoft Support angerufen (wir hatten sowieso noch 5 unbenutzte Cases). Leider hat der Support auch zu keiner Lösung gefunden. Damals habe ich also einige Daten aus dem Profil gesichert und mein Benutzerprofil auf dem Rechner entfernt und neu angelegt.

Das ganze ging jetzt Monate gut (auch nach dem Update 1510) und ich dachte: OK Problem scheint behoben.
Pustekuchen: Diese Woche war es wieder so weit. Der gleiche Fehler. Wieder Suche im Internet was im letzten Monat zu diesem Fehler heraus kam. Und siehe da… ein neuer Tipp: Dropbox ist die Ursache?

Kein Hexenwerk. Also Dropbox deinstalliert Rechner neu gestartet und siehe da. Der Fehler ist weg. Allerdings auch der Root Eintrag im Explorer für OneDrive.
Da ich die Dropbox aber täglich benötige habe ich die Software gleiche wieder installiert. Überraschung: Kein Fehler. 🙂
Auch der Root Eintrag im Explorer für DropBox war nun weg. Aber die Ordner funktionieren und sind erreichbar. Damit kann ich leben. (Evtl. finde ich wenn ich Zeit habe auch hierfür noch eine Lösung).
Fazit in meinem Fall: In diesem Szenario von Dropbox in Verbindung mit Windows 10 scheint was nicht zu passen, was bei mir (vermutlich bereits zweimal) einen Fehler auslöste.

Vielleicht hilft es anderen. Denn ein Profil neu aufzubauen mit allen Einstellungen macht nicht unbedingt viel Spaß, selbst wenn man einen Registry Auszug und eine Kopie alle Daten hat.

Nachtrag 11.01.2016:
Gestern hatten wir auf einem Rechner unserer Kirchengemeinde ein ähnliches Problem mit der folgenden Meldung:

Schwerwiegender Fehler. Das Menü Start und Cortana funktioniert nicht. Wir bemühen uns, das Problem bis zur nächsten Anmeldung zu beheben.

Jetzt Abmelden

In diesem Falle half ein anderer Tipp, der mittlerweile auch im Netz schon mehrfach geteilt wurde.

STRG + ALT + Entf Tasten drücken.
Jetzt die Umschalt-Taste drücken und mit der Maus auf das Power-Symbol klicken und Herunterfahren auswählen.
Die Umschalt-Taste gedrückt halten bis Windows 10 komplett heruntergefahren wurde.
Den PC erneut und hoffen, dass der Fehler diesmal behoben ist.

Bei diesem Problem kann ich nicht sagen, ob es am Profil liegt. Der Rechner hatte nur eines und dieses war mit einem Microsoft-Konto verbunden.

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.

Kein Bild kein Ton mit der Mini-DV Kamera an meinem Firewire IEEE 1394 Anschluss

Längst überfällig bin ich mit der Digitalisierung meiner Familienvideos. Für die alten VHS und VHS-C Aufnahmen habe ein Capture Device von Elgato, was auf einfache Weise macht was es soll.

Aber meine digitale Panasonic DS990 Kamera würde ich gerne direkt anschließen. Mein Nero Video Capture erlaubt mir zwar die Kamera zu bedienen, aber es kommt weder Ton noch Bild an. Einfach nur schwarzes Bild. Wechseln des Kameratreibers brachte nichts.
Ich erinnere mich, das ich das Problem vor Jahren mit Windows 7 auch schon hatte. Da gehörte ein 1394 Legacy Treiber zum Installationssatz und mit dem lief auch meine Panasonic. In Windows 10 finde ich das aber nicht. Zudem hatte ich damals noch 32bit und heute natürlich eine 64bit Installation.

Etwas Recherche in im Netz brachte mich zu dieser Seite:
http://support.microsoft.com/en-us/kb/2970191

OK. Was in Windows 8 und 8.1 geht auch in Windows 10. Also Treiber herunter geladen und installiert. Das brachte aber keinen Erfolg. Ich konnte den Treiber auch nicht nicht auswählen. Also habe ich das MSI-Installationspaket mit meinem SpeedCommander entpackt und finde in der 64bit Versi0n sowohl 32bit als auch 64bit Treiber.

Nun das ganze nochmal:

Gerätemanager gestartet.
IEEE 1394 ausgewählt.
Treiber aktualisieren
Auf dem Computer nach Treibersoftware suchen
Pfad angeben mit dem extrahierten Treiber
Und dann den Legacy Treiber auswählen.

Siehe da. Nun läuft auch mein Capture mit Nero und meiner Panasonic Mini-DV perfekt.

In der Liste der installierten Treiber kann ich nun den Firewire Port mit dem neuen und dem Legacy Treiber wahlweise betreiben.