Autor: Martin Richter

HP + UPS = Der Service des Grauens / oder man braucht viel Geduld (Teil 1)

Nach langer Zeit hatte ich mich im Sommer entschieden meinen lang dienendes Samsung Laptop auszumustern. Ich habe mir ein HP-Envy 15″ Laptop gegönnt. So ein richtig schönes mit allem drum und dran.
Vor allem wollte ich einen Touchscreen.

Irgendwann bemerkte ich, dass die Akku-Stands Anzeige ungenau war und auch der HP-Assistent meinte ich müsste mal meinen Akku kallibrieren. Wozu auch immer.

Das ging aber nicht. Die Aufforderung zum Kalibrieren blieb. Also habe ich, als ich endlich mal Zeit hatte und der Laptop nicht so benötigt wurde HP kontaktiert und hier nun die Abfolge chronolgisch:

Di – 22.12.2020 16:39 Uhr – erster Kontakt mit dem Support von HP
Auch eine neue Erfahrung per Facebook Chat. Nach einigen Anweisungen und Tests die ich durchführen sollte ergab sich keine Besserung.

Mi – 23.12.2020 08:35 Uhr – erneuter Kontakt mit HP
Nun hatte ich alle Logs und Meldungen und Screenshots hochgeladen.
Das Laptop muss eingesendet werden.

Mi – 23.12.2020 10:55 Uhr – Antwort von HP
Das Laptop muss eingesendet werden und dazu die folgenden Instruktionen.
– Das Laptop wird abgeholt
– Ich muss eine Datensicherung machen (Mist aber ich hätte sowieso niemals meine Daten auf dem Laptop belassen)
– Das Laptop wird abgeholt durch UPS
– Die Verpackung und das Label bringt UPS mit.
Das ging mir zu schnell… Laptop von meinen Daten putzen Datensicherung machen…

Mi – 23.12.2020 15:15 Uhr – gebe ich das OK zur Abholung
OK. ging doch schneller als gedacht.
Ich gebe alle Kontaktdaten durch, falls diese noch nicht vorhanden sind.

Do- 24.12.2020 08:43 Uhr – Antwort von HP
Nochmals erhalte ich die Anweisungen: „Nicht einpacken“, „Label kommt von UPS“, „Kiste kommt von UPS“

Do- 24.12.2020 09:38 Uhr – Email von HP (hp.customer.care@hp.com)
Email Bestätigung mit Falldaten und allen bekannten Infos nochmal.
Mit bestätigtem Abholtermin 28.12. durch UPS.

Mo- 28.12.2020 07:04 Uhr – Email von UPS (HP.notifications@ups.com)
Email Bestätigung mit bestätigtem Abholtermin 28.12. durch UPS.

Mo – 28.12.2020 Vormittags
Bei uns kommt UPS oft Vormittags oder später am Nachmittag.
UPS Laster fährt an unserem Haus vorbei. OK. Geduld. Die fahren in der Weihnachtszeit ja öfter.
Aber kein UPS am Montag.
Ja unsere Adresse kann man mit Google finden. Unsere Adresse ist seit Jahren unverändert. Wir bekommen seit Jahren Lieferungen durch Versanddienste! (Nur falls jemand meint wir würden in Hessisch-Uganda leben)

Di – 29.12.2020 Vormittags
UPS fährt wieder an unserem Haus vorbei. Auf der UPS Seite kann ich zu meiner Sendung in der Sendungsverfolgung nichts sehen. Keine Infos zur Abholung. Keine Adresse. Nichts. Nicht mal, dass es abgeholt werden soll.

Ich habe keine Lust ewig auf UPS zu warten und kontaktiere, telefonisch die Hotline.

Di – 29.12.2020 11:35 Uhr- Anruf bei UPS (20 Cent der Anruf)

Ich gebe meine UPS Sendungsnummer an und erfahre, dass es zu dieser Sendungsnummer keine Abholung gibt. Ich verlange den Vorgesetzten.

Ein unerfreuliches Gespräch:
– UPS würde niemals Kisten bereitstellen.
– Ich müsste das Label drucken und die Abholung veranlassen
– Ich hätte niemals eine Bestätigung von UPS per Email bekommen.
– Eine Email Adresse kann der Mitarbeiter mit bei UPS nicht geben, sonst hätte ich ihm die Email zugeschickt.
Ich beende total sauer das Gespräch.

Di – 29.12.2020 11:50 Uhr- Anruf bei HP

Nach x-Minuten gelange ich nach verständigem Gespräch in der Logistik.
Diese sagt, sie kümmert sich drum und eskaliert das bei UPS.

Di – 29.12.2020 Nachmittags

Kein UPS.

Di – 29.12.2020 16:49 Uhr- Anruf bei UPS (20 Cent der Anruf)

Genau der gleiche Verlauf.
– Angeblich habe ich keinen Abholtermin.
– Ich muss ein Label haben.
Ich bin geladen und der Kundenbetreuer betont unwillig.
Bei UPS hat scheinbar keiner eine Ahnung wie Abwicklungen mit HP laufen.

Di – 29.12.2020 16:59 Uhr- Anruf bei HP

Nochmal Logistik Abteilung. Nochmal die Beteuerung: „Wir kümmern und drum!“

Di – 29.12.2020 17:24 Uhr- Email von HP

Nochmal die Sendungsinfos und die Aufforderung ich solle mich an UPS wenden. Dazu die bekannt 20 Cent Telefonnummer.
Soll ich lachen oder weinen?

Mi – 30.12.2020 Vormittags

Wie erwartet fährt der UPS Laster an unserem Haus vorbei.

Mi- 30.12.2020 10:30 Uhr- Anruf bei HP

Nochmal ein Gespräch mit einem Supporter.
Der versteht zwar meinen Ärger aber es nutzt nichts.
Wieder ein Gespräch mit einem Mitarbeiter der Logistik. Wieder das Versprechen das etwas passiert.
Nochmal Telefonnummer und Handy Nummer durchgegeben.
Mir wird versprochen, dass ich eine SMS oder einen Anruf erhalte.

Do – 31.12.2020 10:30
Kein UPS. Keine Versprochene SMS. Keine weitere Email. Kein Anruf!
Ich bin wütend. Habe keinen Bock meine Zeit mit warten zu verbringen oder andere Mitbewohner zu instruieren was zu machen ist wenn UPS kommt (inkl. Zettel schreiben und an die Tür hängen)

HP ist nett aber unfähig etwas in die Wege zu leiten.

Bei UPS hat keiner eine Ahnung und man ist dort nicht mal gewillt einem zu helfen. (und dafür zahlt man noch 20 Cent pro Anruf)

Anmerkung: Ich habe bei UPS nicht einmal mit jemandem gesprochen, der mich zu 100% verstanden hat, oder den ich zu 100% verstehen konnte.
Ich habe nichts gegen einen Akzent in der Sprache aber verstehen und ausdrücken sollte man schon.

BTW: Wäre die Kalibrierung bereits Teil der Endkontrolle bei HP gewesen, dann wäre das Gerät niemals ausgeliefert worden. Aber auch hier wird halt lieber alles auf den Kunden abgewälzt.

To be continued…



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.

Benachrichtigungen erhalten wenn der Symantec Endpoint Protection Manager (SEPM) keine Virendefinitionen aktualisiert

Seit Jahren benutzen wir die Symantec Endpoint Protection in meiner Firma. Aktuell die Version 14.0.1.
Eigentlich macht das Ding was es soll. Aber… Es gibt einen Fall in dem im Werkzeug Koffer von Symantec kein Tool vorhanden ist das Problem zu lösen.

Was passiert?

Eigentlich möchte man ja von einem Antivirensystem nichts hören und sehen. Es soll funktionieren und das war es.
Ganz besonders in einer Firma in der 5, 10, 20 und mehr Clients vorhanden sind.
Der SEPM (Symantec Endpoint Protection Manager), benachrichtigt much brav wenn auf Stations nach mehreren Tagen noch alte Virendefinition sind, oder auch eine bestimme Anzahl von PCs erreicht wurden, die alte Virendefinitionen haben. Oft sind das bei uns Maschinen, die unterwegs sind, oder lange nicht eingeschaltet wurden.

Aber es gibt einen Fall in dem der SEPM vollkommen versagt: Wenn nämlich der SEPM selber keine neuen Virendefinitionen erhält. Warum auch immer!

Ich hatte in den letzten Jahren mehrfach den Fall, in denen der SEPM keine neuen Virendefinitionen von Symantec geladen hat. Die Gründe waren vielseitig. Mal hatte der SEPM kein Internet aufgrund eines Konfigurationsfehlers, mal startete der SEPM gar nicht nach einem Windows Update.
Aber in den meisten Fällen war der SEPM einfach nicht fähig, die neuen Signaturen zu laden obwohl er anzeigte, dass welche zum Download bereit stehen.

Der letzte Fall ist besonders nervig. Ich habe zwei Support-Cases zu dem Thema schon offen gehabt, aber die redlich bemühten Supporter haben dennoch nichts herausbekommen.
Nach jeweiligem Neustart des Dienstes oder des Servers, lief es fast immer wieder. Also hatte sich scheinbar nur irgendwas intern „verklemmt“!

Dieser Fall ist aber gefährlich. Man bekommt von der ganzen Sache nichts mit, bis eine bestimmte Anzahl von PCs nach ein paar Tagen eben alte Virendefinitionen haben. In der Einstellung bei uns sind das 10% der Maschinen nach 4 Tagen. Man kann das zwar herunter drücken, aber diese Warnungen nerven meistens nur ohne triftigen Grund.
Und man kann in diesem Fall nicht mal testweise einfach den SEPM neu starten.
Eigentlich will ich keine Meldung und das System soll erstmal selbst versuchen erkannte Problem zu lösen.
Vor allem habe ich keine Lust irgendjemanden zu beauftragen, der pro Tag einmal diese blöde Konsole startet und nachschaut was los ist. Über alles andere bekomme ich ja auch Emails.

Ich finde solch eine lange Latenz, in der es nicht bemerkt wird, dass die AV-Signaturen alt sind, einfach gefährlich.
Aber Bordmittel darüber zu warnen gibt es nicht!
Zudem trat dieser Fall ca alle 6-9 Wochen immer einmal wieder auf.
Und das nervt.

Also habe ich mich auf die Suche gemacht und habe für den SQL Server in dem unsere Daten gehalten werden zwei kleine Jobs geschrieben die nachfolgend beschreiben werden.
Diese Jobs laufen nun einige Monate und haben bereits mehrfach erfolgreich dieses Problem „selbsttätig“ behoben…

Job 1: Symantec Virus Signature Check

Dieser Job läuft jede Stunde einmal.
Der Code macht einfach folgendes.

  • Sollte es in den letzten 32 Stunden (siehe Wert für @delta) eine Änderungen in den Signaturen gegeben haben ist alles OK
  • Gab es kein Update der Signaturen dann werden zwei Schritte eingeleitet.
  • Es wird über den internen SQL Mail Dienst eine Warnung versendet an den Admin.
  • Danach wird ein weiterer Job gestartet mit dem Namen Symantec SEPM Restart.

Die 32 Stunden, sind ein Wert der sich aus Erfahrungswerten gebildet hat. In 98% aller Fälle werden Signaturen innerhalb von 24h aktualisiert. Aber es gibt eben ein paar Ausnahmen

Taucht die Email mehr als zweimal auf, muss ich wohl irgendwie aktiv werden und mal manuell kontrollieren.

DECLARE @delta INT
-- number of hours
SET @delta = 32 
DECLARE @d DATETIME 
DECLARE @t VARCHAR(MAX)
IF NOT EXISTS(SELECT * FROM PATTERN WHERE INSERTDATETIME>DATEADD(hh,-@delta,GETDATE()) AND PATTERN_TYPE='VIRUS_DEFS')
BEGIN
      SET @d = (SELECT TOP 1 INSERTDATETIME FROM PATTERN WHERE PATTERN_TYPE='VIRUS_DEFS' ORDER BY INSERTDATETIME DESC)
      SET @t = 'Hallo Admin!

Die letzten Antivirus-Signaturen wurden am ' + CONVERT(VARCHAR, @d, 120)+' aktualisiert!
Es wird versucht den SEPM Dienst neu zu starten!

Liebe Grüße Ihr
SQLServerAgent'
      EXEC msdb.dbo.sp_send_dbmail @profile_name='Administrator',
				   @recipients='administrator@mydomain.de',
				   @subject='Symantec Virus Definitionen sind nicht aktuell',
				   @body=@t
      PRINT 'Virus Signaturen sind veraltet! Letztes Update: ' + CONVERT(VARCHAR, @d, 120)
      EXEC msdb.dbo.sp_start_job @job_name='Symantec Restart'
      PRINT 'Restart SEPM server!!!'
    END
  ELSE
    BEGIN 
      SET @d = (SELECT TOP 1 INSERTDATETIME FROM PATTERN WHERE PATTERN_TYPE='VIRUS_DEFS' ORDER BY INSERTDATETIME DESC)
      PRINT 'Virus Signaturen sind OK! Letztes Update: ' + CONVERT(VARCHAR, @d, 120)
    END

Job 2: Symnatec Restart

Dieser Job wird nur durch den Job 1 gestartet und er ist äußerst trivial.
Führt einfach nur 2 Befehle aus, die den SEPM stoppen und anschließend neu starten.

NET STOP SEMSRV
NET START SEMSRV

PS: Traurig war, dass man durch den Support auch keine Hilfe bekam, nachdem ich solch einen Lösungsansatz vorschlug. Man wollte mir keine Infos über die Strukturen der Tabellen geben. Letzten Endes waren die Suchmaschinen so nett alle nötigen Informationen zu liefern, denn ich war nicht der einzige mit diesem Problem.

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.

  1. Outlook Updates abstellen.
  2. Befehlszeile (CMD.EXE) als Admin ausführen.
  3. 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