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…?

Inhalt des Papierkorbs wird nicht angezeigt…

Ich hatte immer wieder Probleme, dass mein Papierkorb leer war, obwohl ich gerade eine Datei dort hin verschoben war.

Es schien auch alles andere zu funktionieren, denn ich konnte auch Aktionen im Explorer rückgängig machen und Dateien wieder so aus dem Papierkorb herausholen. Nur anzeigen konnte ich den Inhalt des Papierkorbes nicht mehr.

Analyse der Festplatte ergab, aber, dass die Dateien vorhanden sind, CHKDSK keinen Fehler liefert… nichts problematisches eigentlich zu finden. Ich habe keine Ahnung wie oft ich den entsprechenden Ordner entfernt habe und hoffte, dass sich die Datenbank des Papierkorbes irgendwann fängt. Aber dem war nicht so 🙁
Ich löschte eine Datei, die kurz im Papierkorb erschein um sofort wieder zu verschwinden.

Irgendwann hat es mich so genervt, dass ich doch weiter auf die Suche gegangen bin und habe in einem Forum einen Hinweis für eine Richtung gefunden, die ich gar nicht auf der Rechnung hatte.
Die Ursache war ein Wibu Codemeter-Dongle. Dieser Dongle steckt immer in meiner Entwicklungsmaschine um bestimmte Szenarien testen zu können. Wir benutzen für größere Lizenzen die Wibu-Codemeter-Dongles seit einigen Jahren mit gutem Erfolg und wir sind auch sehr zufrieden mit der Qualität, sowohl von Hardware als auch Software und SDK.

Der eingesteckte Codemeter Dongle meldete sich als  lokaler Datenträger an. Dadurch wollte Windows auch scheinbar den Papierkorb auf diesem Laufwerk suchen und finden. Aber eigentlich ist das Ding nur eine RAM-Disk, die keinen permanenten Speicher bietet. Sobald der Dongle als lokale Festplatte angemeldet ist, funktioniert auch der Windows-Papierkorb nicht mehr.
Ein schneller Test zeigte, dass der Papierkorb nur bei nicht eingestecktem Dongle verfügbar war.
Weitere Recherche ergab, dass die eigentliche Ursache ein Bug in Windows 7/2008R2 ist. Netterweise ist sogar ein Hotfix für Windows-7 und Windows Server 2008R2 verfügbar (Links siehe unten), aber leider hat der seinen Weg nach Windows-Update nicht gefunden :(.

Aber es lässt sich auch ohne Installation des Hotfixes schnell mit der Codemeter Runtime schnell ändern.
Die Codemeter Runtime gibt folgende Auskunft zu dem Dongle.

C:\...\CodeMeter\Runtime\bin>cmu32  -s1-2345678 --show-config-disk
cmu32 - CodeMeter Universal Support Tool.
Version 5.00b of 2013-May-14 (Build 1067) for Win32
Copyright (C) 2007-2013 by WIBU-SYSTEMS AG. All rights reserved.

- CmStick with Serial Number 1-2345678 and version 1.16
  Version:            1.16
  Flash Size:         no real flash available
  Virtual Drive:      D:
  Configuration:      LocalDisk with ActivePartition
  File System:        FAT32
  Boot-Code:          Int18 Boot Code
  Mdfa:               0x539

Über die entsprechenden Commandline Utilities der Wibu-Runtime kann man das aber umkonfigurieren. der Befehl lautet:
cmu32 -s1-2345678 –set-config-disk RemovableDisk
Dazu muss mit dem Parameter -s die Seriennummer des betroffenen Dongles angegeben werden.

C:\...\CodeMeter\Runtime\bin>cmu32 -s1-2345678 --set-config-disk RemovableDisk
cmu32 - CodeMeter Universal Support Tool.
Version 5.00b of 2013-May-14 (Build 1067) for Win32
Copyright (C) 2007-2013 by WIBU-SYSTEMS AG. All rights reserved.

  Communication mode changed successfully.

  Please replug your CmDongle to apply the changes.

Also Dongle wie angezeigt einmal rausziehen und wieder anstecken.
Und sie da 🙂 mein Papierkorb ist sofort wieder da und sichtbar. „Gelöschte Dateien“ erscheinen wir gewohnt.
Die Kontrolle zeigt nun einen Removeable-Device, wie das bei anderen USB-Sticks auch der Fall wäre.

C:\...\CodeMeter\Runtime\bin>cmu32  -s1-2345678 --show-config-disk
cmu32 - CodeMeter Universal Support Tool.
Version 5.00b of 2013-May-14 (Build 1067) for Win32
Copyright (C) 2007-2013 by WIBU-SYSTEMS AG. All rights reserved.

- CmStick with Serial Number 1-2345678 and version 1.16
  Version:            1.16
  Flash Size:         no real flash available
  Virtual Drive:      D:
  Configuration:      RemovableDisk with ActivePartition
  File System:        FAT32
  Boot-Code:          Int18 Boot Code
  Mdfa:               0x539

Weitere Hinweise zu dem Vorgehen finden sich auf den Microsoft und Wibu-Supportseiten hier:
http://support.microsoft.com/kb/2677246/en-us
http://www.wibu.com/de/faq-codemeter/question/single/warum-ist-mein-papierkorb-leer-wenn-ein-cmstick-angesteckt-ist-138.html
http://www.wibu.com/de/faq-codemeter/question/single/wie-kann-man-einen-cmstick-ohne-speicher-umkonfigurieren-145.html

Bericht über die Advanced Developers Conference (ADC) für C++ in Ohlstadt vom 03.+04. Mai 2012

Auf http://www.c-plusplus.de ist von mir jetzt ein Artikel zu der ADC C++ Konferenz in Ohlstadt erschienen, die am 03.04. Mai 2012 stattfand.
Über die Abendveranstaltung habe ich in meinem letzten Blogartikel auszugsweise berichtet.

Advanced Developers Conference C++ – native C++ im Blickpunkt (Tag 1)
Advanced Developers Conference C++ – native C++ im Blickpunkt (Tag 2)

Viel Spaß beim Lesen!

 

vNext (VS-2011): Im aktuellen Preview kann man keine Programme mehr für XP entwickeln

Es kursiert ja bereits das Windows Developer Preview, also eine virtuelle Maschine mit der man in die nächste Windows 8 und Visual Studio Version hinein schnuppern kann.

Mein Mit-MVP Mike Ryan hat nun bei Tests festgestellt, dass die mit der neuen Visual Studio Version erzeugten Programme, die die MFC 11 und CRT 11 benutzen nicht mehr unter Windows XP laufen ❗ 😮 Aus eigenen Tests kann ich das noch nicht bestätigen.

Das ist mit großer Sicherheit ein Killerkriterium… zumindest ist es das in unserer Firma.
Mich wundert das, vor allem weil der Support für Windows XP auch noch bis 2014 läuft und wenn man Statistiken glauben darf, dann ist die Häufigkeit der Verwendung von Windows XP erst seit Juli diesen Jahres unter die 50% Marke gefallen.

Auf Connect wurde ein entsprechende Bug-Report eröffnet, es gibt hier die Möglichkeit mit den eigenen Stimmen für etwas Widerstand zu sorgen:
https://connect.microsoft.com/VisualStudio/feedback/details/690617
Also bitte gebt Eure Stimme ab!

Da die nächste VS Version vermutlich noch bis Herbst nächsten Jahres auf sich warten lässt kann man nur hoffen, dass sich das ändern wird.

Nachtrag 26.09.2011: Weitere Details zu den fehlenden Funktionen siehe Kommentare
Nachtrag 29.09.2011: Es scheint kein Zufall oder eine vorläufige Beschränkung zu sein. Der Bug wurde mit By Design geschlosen ❗ Ich kann dennoch nur raten auf deisem case weiter mit Stimmen abzugeben.

„Elevated“ Programme unter Vista / Windows 7 / Windows 8 / Windows 10 haben auf einmal keine gemappten Laufwerke mehr

Ist man Administrator unter Vista, Windows 7, Windows 8 oder Windows 10 und UAC ist aktiviert, dann existieren technisch zwei Sicherheits -Tokens. Ein Token mit den vollen Administrativen Rechten und ein reduziertes gefiltertes Token, ohne Admin-Rechte.

Wenn man sich anmeldet und Netzwerklaufwerke (Freigaben/Shares) zugeordnet werden, dann erfolgen diese Laufwerksmappings in dem Token mit den reduzierten Rechten.

Startet man nun eine Session mit angehobenen, vollen administrativen Rechten, dann sind die vorher zugeordneten Netzwerklaufwerke in dieser Session nicht sichtbar.
Ein etwas ungewöhnliches aber durchaus logisches Verhalten.
Das Logon Skript läuft eben nicht in dem selben Sicherheitskontext, wie Prozesse, die man mit vollen angehobenen Rechten startet. Defakto sind es wirklich zwei verschiedene Logon’s mit zwei verschiedenen Logon-ID’s.

Mit einem einfachen setzen eines Registry Keys kann man jedoch erreichen, dass auch die angehobenen Admin-Sessions die gleichen Laufwerkmappings erhalten:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections = 1 (DWord)

Aber leider ist dieser Schalter nicht als Standard gesetzt.
Ärgerlich wird dies, wenn man ein kleines Setup-Programm schreiben will, dass einige Daten aus dem Nezwerk kopieren soll und dem man ein entsprechendes requireAdministrator-Manifest gibt. Startet man dieses Programm findet es auf einmal nicht mehr die Laufwerke, die eben noch verfügbar waren. Umgehen kann man das ganze nur in dem man UNC-Dateinamen verwendet.

Beschrieben wird dies auch hier auch in diesem KB Artikel und besonders dieser TechNet Artikel.