Visual Studio 2013 ist nun verfügbar

Heute ist Visual Studio 2013 verfügbar gemacht worden.

Weitere Infos finden sich im VC++ Blog und in Somasegar’s Blog:
http://blogs.msdn.com/b/vcblog/archive/2013/10/17/visual-studio-2013-available-now.aspx
http://blogs.msdn.com/b/somasegar/archive/2013/10/17/visual-studio-2013-available-for-download.aspx

 

Mystisch: Der Windows-Ressourcenschutz konnte den Reparaturdienst nicht starten.

Ich hatte ein Problem mit einer Fehlfunktion und hatte eine defekte DLL in Verdacht.

Mein erster Griff ging daher zum System-File-Checker um das System erstmal zu prüfen.
Aber OHA. Der verweigerte strikt jede Zusammenarbeit:

C:\>sfc /verifyonly
Der Windows-Ressourcenschutz konnte den Reparaturdienst nicht starten.

C:\>sfc /scannow
Der Windows-Ressourcenschutz konnte den Reparaturdienst nicht starten.

OK. Jetzt ein noch größeres Rätselraten ❓ Was ist kaputt?  Ich befürchtete schon einen totalen Systemzusammenbruch… 🙁

Die Lösung war dann doch einfacher als gedacht. Ich hatte eine 32bit Konsole gestartet. Aus der 32bit Konsole war dieser 64bit Dienst nicht zu steuern. Aber was ist das für eine blödsinnige Fehlermeldung… und warum gibt es überhaupt einen nicht funktionierenden 32bit Teil dieser Komponente?

Nachdem ich die 64bit CMD.EXE Aus C:\Windows\System32 gestartet hatte lief alles wie erwartet:

C:\Windows\system32>sfc /verifyonly
Systemsuche wird gestartet. Dieser Vorgang kann einige Zeit dauern.
Überprüfungsphase der Systemsuche wird gestartet. Überprüfung 36 % abgeschlossen.
...

 

Mein 15. Award als deutscher MVP für Visual C++

Da denkt man: „Das war es dann wohl!“, aber dann kommt doch anders.

Pünktlich am 01. Oktober bekam ich eine Email mit dem folgenden Inhalt:

Sehr geehrte(r) Martin Richter,
herzlichen Glückwunsch! Wir freuen uns, Ihnen den Microsoft® MVP Award 2013 verleihen zu können! Diese Auszeichnung wird an herausragende, führende Mitglieder der technischen Communities verliehen, die ihre wertvollen praktischen Erfahrungen mit anderen Menschen teilen. Wir schätzen Ihren außerordentlich bedeutenden Beitrag in den technischen Communities zum Thema Visual C++ im vergangenen Jahr hoch ein.

Das ist nun mein 15. Award als MVP für C++.

Ich bleibe dabei: Alles hat seine Zeit (Prediger 3, 1-11) 😉

PS:
Kleiner Nachtrag. Ich war einer von fast 1.000 MVPs:
Nachzulesen hier http://blogs.msdn.com/b/mvpawardprogram/archive/2013/10/01/new-and-renewed-mvps-announced.aspx

Windows 7, PlaySound und die vermisste Prüfung auf Speicherlecks

Bei der Entwicklung von neuen Funktionen in einem Modul bekam ich irgendwann einen ASSERT. Diesen ASSERT hatte ich in einem Cache eingebaut. Der ASSERT sprang an, wenn bei Programmende der Cache nicht sauber aufgeräumt wurde. Also eigentlich in der Entwicklungsphase nichts ungewöhnliches. Irgendwo wurde also eine Funktion zum Aufräumen nicht aufgerufen.

Aber was mich in diesem Moment extrem stutzig machte, war, dass in der Debugausgabe meines VisualStudios keine Memory Leaks angezeigt wurden ❗ Das machte irritierte mich nun schon sehr. Erster Verdacht. Evtl. hat ja jemand die Leakprüfung für den Cache ausgeschaltet (siehe AfxEnableMemoryTracking). Aber eine kurze Prüfung ergab, dass dem nicht so ist.

Also den Test noch mal ausgeführt. Diesmal wieder der ASSERT und zusätzlich der Dump. „Oha“ dachte ich „Hier ist aber was richtig faul!“

Nachdem ich immer wieder andere Testszenarien verwendet habe, erschienen mal die Leaks und mal erschienen sie nicht. Und nach einiger Zeit kaum ich dahinter, dass immer wenn PlaySound in meiner Debug Version der Anwendung verwendet wurde, kein Leak-Check erfolgte. Wurde PlaySound nicht verwendet war alles gut und die Leaks wurden ausgegeben.

Jetzt ging es ans eingemachte. Schnell isolierte ich folgende DLLs die zusätzlich beim ersten PlaySound geladen wurden.

'xyz.exe': Loaded 'C:\Windows\SysWOW64\MMDevAPI.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\propsys.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\wdmaud.drv', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\ksuser.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\avrt.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\setupapi.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\cfgmgr32.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\devobj.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\AudioSes.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\msacm32.drv', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\msacm32.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\midimap.dll', Symbols loaded (source information stripped).

Und nach etwas weiter debuggen kam ich dahinter, dass der DllMain Code von setupapi.dll beim DETACH_PROCESS den Prozess sofort terminiert und nicht alle DLLs einen DETACH_PROCESS Aufruf erhalten. Aber der Code für die Leak-Detection der MFC liegt in der MFCx.DLL und wird durch eine statische Variable ausgelöst, die beim Entladen der MFCx.DLL dann zur Ausgabe der Speicherlecks führt. (Siehe PROCESS_LOCAL(_AFX_DEBUG_STATE, afxDebugState) und AfxDiagnosticInit).

Eine genauere Analyse des Stacktraces ergab folgendes Bild:

ntdll.dll!_ZwTerminateProcess@8()  + 0x5 bytes	
ntdll.dll!_RtlpWaitOnCriticalSection@8()  + 0x1d38f bytes	
ntdll.dll!_RtlEnterCriticalSection@4()  + 0x16a38 bytes	
setupapi.dll!_pSetupInitGlobalFlags@4()  + 0x1fc bytes	
setupapi.dll!_pSetupGetGlobalFlags@0()  + 0xe2 bytes	
setupapi.dll!_FlushWVTCache@0()  + 0x2f bytes	
setupapi.dll!_DestroyDeviceInfoSet@8()  + 0x3f bytes	
setupapi.dll!_SetupDiDestroyDeviceInfoList@4()  + 0x44 bytes	
MMDevAPI.dll!CDeviceEnumerator::FinalRelease()  + 0x78 bytes	
MMDevAPI.dll!ATL::CComObjectCached::~CComObjectCached()  + 0x3c bytes	
MMDevAPI.dll!ATL::CComObjectCached::`scalar deleting destructor'()  + 0xd bytes	
MMDevAPI.dll!ATL::CComObjectCached::Release()  + 0xf0c6 bytes	
MMDevAPI.dll!ATL::CComClassFactorySingleton::~CComClassFactorySingleton()  + 0x18 bytes	
MMDevAPI.dll!ATL::CComObjectNoLock<ATL::CComClassFactorySingleton >::`scalar deleting destructor'()  + 0x1a bytes	
MMDevAPI.dll!ATL::CComObjectNoLock<ATL::CComClassFactorySingleton >::Release()  + 0xe0e3 bytes	
MMDevAPI.dll!ATL::CAtlComModule::Term()  + 0x27 bytes	
MMDevAPI.dll!__CRT_INIT@12()  + 0x26e6 bytes	
MMDevAPI.dll!__CRT_INIT@12()  + 0x2588 bytes	
ntdll.dll!_LdrpCallInitRoutine@16()  + 0x14 bytes	
ntdll.dll!_LdrShutdownProcess@0()  + 0x141 bytes	
ntdll.dll!_RtlExitUserProcess@4()  + 0x74 bytes	
kernel32.dll!75eb7a0d() 	
msvcr100d.dll!__crtExitProcess(int status=0)  Line 709	C
msvcr100d.dll!doexit(int code=0, int quick=0, int retcaller=0)  Line 621 + 0x9 bytes	C
msvcr100d.dll!exit(int code=0)  Line 393 + 0xd bytes	C
xyz.exe!__tmainCRTStartup()  Line 568	C

Ursache war, dass MMDevAPI.DLL in seinem DllMain Code ausführt in der setupapi.dll, die aber bereits den DETACH_PROCESS abgearbeitet hat. Das grundsätzliche Problem wird hier in diesem Blog Artikel geschildert: http://blogs.msdn.com/b/oldnewthing/archive/2005/05/23/421024.aspx
Mit eigenen Worten: Die MMDevAPI.dll ruft Funktionen in einer DLL auf, die bereits alle Ihren Speicher und Ressourcen freigegeben hat. Und wie es hier im Code so aussieht, versucht die SetupAPI.DLL wieder Ressourcen zu akquirieren, die eben bereits schon freigegeben wurden, weil eine DLL sie erneut benutzt.

Die Folge ein „Crash“ in DllMain, die der Windows-Lader aber abfängt und sofort mit einer Terminierung des Prozesses ahndet. D.h. nun aber, dass nicht alle DLLs, die noch einen DllMain Aufruf mit DETACH_PROCESS erhalten müssten,  auch an die Reihe kommen.

Etwas weitere Recherche ergab, dass dieses Problem auch in den MSDN Foren bereits diskutiert wurde inkl. einer möglichen Lösung.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/8cb1847d-3218-4610-9cb8-6905bd255ff5/no-dllprocessdetach-after-calling-playsound-on-windows-7-64bit

Die Lösung ist erstaunlich einfach: Wenn vor der Benutzung von PlaySound explizit die SetupAPI.DLL geladen wird, dann verläuft der Rest der Deinitialisierung vollkommen normal. SetupAPI.DLL wird nicht entladen, weil die DLL durch den LoadLibrary Aufruf die DLL im Speicher sperrt. MMDevAPI.DLL kann erfolgreich selbst aufräumen und der Code läuft nicht mehr ins Nirvana.

Hier handelt sich offensichtlich um einen Bug in Windows 7 (Windows 8 konnte ich dies bzgl. nicht testen).
Dieser Bug kann natürlich auch empfindlichere Probleme mit sich bringen, wenn Ressourcen betroffen sind, die nicht automatisch mit Prozessende freigegeben werden und wenn diese Ressourcen ausschließlich in der DllMain bei einem DETACH_PROCESS behandelt werden.

Änderungen für MFC + ATL in VS-2013

Im Microsoft C++ Team Blog kann nachgelesen werden was sich in ALT+MFC in VS-2013 tun wird:
http://blogs.msdn.com/b/vcblog/archive/2013/08/20/atl-and-mfc-changes-and-fixes-in-visual-studio-2013.aspx

Wer hätte es gedacht…, ja es gibt wieder etwas „Neues“, auch wenn es mehr oder weniger nur Bugfixes sind.

Besonders erwähnenswert ist der Wegfall des MBCS Supports in der MFC, siehe auch hier.
Das die ATL jetzt nur noch als statische Bibliothek mit sehr kleinem Footprint existiert ist nett. Warum eigentlich nicht gleich so?

Nachtrag und Korrektur durch den aufmerksamen Blog-Leser Sasche:

Wie auch im verlinkten Artikel beschrieben, fällt der MBCS Support in VS-2013 noch nicht weg, sondern ist erst mal nur “deprecated” (und die entsprechenden Libs nur noch als separater Download verfügbar). Erst in einer Folgeversion soll der Support für MBCS ganz wegfallen.

 

Microsoft veröffentlicht Update 3 für VS-2012 und zeitgleich einen Preview auf VS-2013

Das Update 3 für VisualStudio 2012 wurde gestern veröffentlicht.

http://support.microsoft.com/kb/2835600/en-us
http://blogs.msdn.com/b/vcblog/archive/2013/06/27/what-s-new-for-visual-c-developers-in-vs2013-preview.aspx
http://blogs.msdn.com/b/visualstudio/archive/2013/06/26/visual-studio-2013-preview-available-now.aspx
http://visualstudiomagazine.com/articles/2013/06/26/update-3-of-visual-studio-2012-released.aspx

Damit ist die Regression aus dem Update 2 endgültig behoben. Mit Update 1 konnte man wieder Programme bauen, die auch auf Windows XP laufen. Update 2 machte dies wieder zunichte.

Siehe auch:
http://connect.microsoft.com/VisualStudio/feedback/details/783137/visual-studio-2012-update-2-rtw-breaks-xp-targeting-with-c-when-statically-linking-mfc-and-atl
http://tedwvc.wordpress.com/2013/04/14/how-to-get-visual-c-2012-update-2-statically-linked-applications-to-run-on-windows-xp/
http://blogs.msdn.com/b/vcblog/archive/2013/05/07/fix-visual-studio-2012-update-2-breaks-windows-xp-targeting-with-atl-and-or-statically-linking-mfc.aspx

Zeitgleich wurde auch ein Preview auf VS-2013 veröffentlicht.
http://blogs.msdn.com/b/visualstudio/archive/2013/06/26/visual-studio-2013-preview-available-now.aspx

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

Mathematik ist einfach, sie auf Rechner zu bringen nicht…

Mathe ist ja eigentlich ganz einfach. Die nachfolgende Routine berechnet die kürzeste Distanz zwischen zwei Punkten auf der Erde unter der Berücksichtigung, dass die Erde eine perfekte Kugel ist.
Benutzt wird diese Routine um die Luftlinie zwischen zwei geokodierten Adressen zu ermitteln.

double DistanceBetweenCoordinates(
          double dLatitude1, double dLongitude1, 
          double dLatitude2, double dLongitude2)
{
  // Convert to radient
  dLatitude1 *= M_PI / 180;
  dLongitude1 *= M_PI / 180;
  dLatitude2 *= M_PI / 180;
  dLongitude2 *= M_PI / 180;

  // Get distance
  double dDistance;
  dDistance = sin(dLatitude1) * sin(dLatitude2) + cos(dLatitude1) * 
        cos(dLatitude2) * cos(dLongitude2-dLongitude1);
  // Ohne diese Zeile haben wir ein Problem... dDistance ist evtl. >1
  // dDistance = min(dDistance,1.0);
  dDistance = acos(dDistance) * EARTH_RADIUS;
  return dDistance;
}

Eigentlich ganz einfach. Aber dieser Code hat ein massives Problem, denn dDistance kann vor dem acos durch Rundungsfehler größer als 1 werden.

Für die folgenden Werte passiert etwas Übles:

dLatitude1 0.86208095750908087 
dLongitude1 0.15333764167657613 
dLatitude2 0.86208095750908087 
dLongitude2 0.15333764167657613

Eigentlich müsste glatt 1 herauskommen, denn die Koordinaten sind gleich, aber dDistance wird bei diesen Werten 1.0000000000000002. Der Sinus bzw. Cosinus ergibt eben doch leicht abweichende Werte. Der folgende acos scheitert dann aber und das Resultat wird NaN (Not a Number). Erlaubt sind natürlich nur Werte <=1.0 und >=-1.0. Die Folge ist, dass die Distanz nicht 0.0 ist.

Also muss hier eine kleine Sicherung eingebaut werden, die Aufgrund der Rundungs-Genauigkeitsfehler, das überschreiten von 1 verhindert.
Eigentlich ist Mathe ganz einfach, aber auf einem Rechner ist das alles manchmal ganz anders.

PS: Ich weiß schon warum ich noch nie Fließkommaarithmetik auf PCs mochte.

Umstellung der MSDN Foren…

<Ironie>Mittlerweile frage ich mich ob Microsoft überhaupt noch eine Community will.</Ironie>
Ja sicher wollen sie das und sagen und versichern tun das auch alle Offiziellen immer und überall. Das nehme ich Ihnen sogar ab. Aber mit der Umstellung der Forensoftware haben sie sich wohl eher einen Bärendienst geleistet. Und mit dieser „neuen“ eigenen MSDN-Forenplattform werden Sie kaum Bäume ausreißen.

Die HTTP Foren wurden nun ein weiteres Mal umgestellt und sind nun – aus meiner persönlichen Sicht – gar nicht mehr zu bedienen.
Weiterhin bezweifle ich stark, dass sich mit dieser neuen Forensoftware wirklich viele Nutzer anfreunden können. Es ist einfach auf den ersten, zweiten und dritten Blick viel zu undurchschaubar und chaotisch. Man findet alles mögliche, nur nicht das was man sucht. Die Übersicht über Meine Foren, ist kaum zu gebrauchen, alte nicht mehr existente Einträge lassen sich nicht entfernen. Meine Forenthreads fehlt ganz! Es ist extrem kompliziert zwischen den deutschen und englischen Forenbereichen zu wechseln. Ich verirre mich immer in den deutschen, englischen, Technet, MSDN Seiten. Tausend Foren und Bereiche aber keine Übersicht. Optische großflächige Schalter rauben den Raum für eigentliche Informationen. Es muss ja jetzt alles „flat“ sein.
Ich verstehe nicht, warum Filter den Vorzug vor klaren Baumstrukturen bekommen?

Von den Bugs will ich gar nicht reden: „Leider kann Ihre Anforderung nicht bearbeitet werden.“ , „Es wurden keine Ergebnisse gefunden.“, Links Führen ins leere, Administrative Funktionen melden Serverfehler. Die NNTP-Bridge arbeitet nicht. Es gehen wieder Gerüchte um, dass die Bridge ganz eingestellt wird. 🙁

DAS macht keinen Spaß. Ich muss mir stark überlegen, ob ich hier überhaupt noch vorbei schauen soll.
Aber da sich hier seit „Zerstörung“ der NNTP Foren auch keine neue Community gebildet hat, ist das wohl auch kein großer Verlust: Der letzte macht dann mal das Licht aus…

Visual Studio 2012 RC für Update 3 behebt XP Kompatibilitätsprobleme die mit Update 2 kamen

In einem Note in meinem Blog wurde es ja auch erwähnt, das Update 2 zu Visual Studio 2012 eine Regression hat. Mit Update 1 konnte man wieder Programme bauen, die auch auf Windows XP laufen. Update 2 machte dies wieder zunichte. Jetzt ist ein RC für Update 3 verfügbar gemacht worden mit dem dieser Fehler behoben wurde.

Hier die Ankündigung im C++ Blog:
http://blogs.msdn.com/b/vcblog/archive/2013/05/07/fix-visual-studio-2012-update-2-breaks-windows-xp-targeting-with-atl-and-or-statically-linking-mfc.aspx