ADC C++ Konferenz in Prien am Chiemsee – Ein Rückblick

Wenn man etwas weiter zurückdenkt, dann war C++ eigentlich ein Thema, das von keiner Entwicklerkonferenz wegzudenken war. Das hat sich allerdings in den letzten Jahren gravierend geändert. C++ fristete mehr oder weniger ein Nischendasein (speziell auch auf Microsoft Konferenzen). Nicht zu vergessen begannen die ADC Konferenzen (IMHO vor 15 Jahren) auch mit Themen aus der nativen Welt und wurden in den letzten Jahren immer mehr nur eine Konferenz für die „Managed Welt“.
Und wenn man manche Vorträge der Vergangenheit anhörte (gerade auch von deutschen Microsoft Mitarbeitern), dann bekam man das Gefühl vermittelt, dass man mit C++ Native Code eigentlich keinen Platz in der „geplanten/zukünftigen neuen Welt“ hat.

Alleine das Microsoft Deutschland niemanden im deutschsprachigen Raum hat, der für C++ zuständig ist und das Produkt auch wirklich kennt und damit arbeitet ist für mich eine Eigentümlichkeit der besonderen Art und hoffentlich etwas was sich in der Zukunft ändern könnte 😉

Umso mehr muss man den Mut von ppedv bewundern eine Konferenz genau zu diesem Thema „Natives C++“ zu veranstalten, die Advanced Developers Conference zu C++ in Prien.

Das wichtigste was ich zuerst schreiben möchte ist:
Solch eine Veranstaltung war überfällig

Warum?

  1. Es gibt einen Bedarf in unserer Industrie und Technik, nach nativem Code. Und das betrifft eben nicht nur „legacy Code“ sondern auch Neuentwicklungen.
  2. C++ ist alles andere als eine tote Sprache. Das zeigt gerade die Entwicklung der Sprache, Compiler und Library die C++11 (vormals (C++0x) mit sich gebracht hat.
    Und ich kann jedem C++ Entwickler nur dringend anraten sich mit den neuen Sprach- und Library-Features auseinander zu setzen.
    Es lohnt sich unbedingt und es ist produktiv diese neuen Features (auto, decltype, Lambdas uvam.) auch zu verwenden.
    Und der nächste Standard lässt hoffentlich mit seinen neuen Features keine 11 Jahre auf sich warten 😉
  3. Weil gerade auch der Microsoft C++ Compiler in VS-2010 (beginnend schon mit dem Featurepack von VS-2008 bzw. VS-2008 SP1) sehr viele der neuen Sprachfeatures anbietet. Alleine hier hat Microsoft eigentlich schon gezeigt, dass native Softwareentwicklung alles andere als tot ist.
  4. Viele C++ Entwickler leben längst in beiden Welten, d.h. sie entickeln sowohl in der Managed Welt mit C# und sie entwickeln auch in nativem C++.  Auch dieser Entwicklung muss Rechnung getragen werden, denn diese zwei Welten vertragen sich ja excellent mit C++/CLI, COM oder auch der MFC als Kleber.
  5. Das auch in Windows 7 alle neuen Features über bestehende native Technologien (Standard Windows API Interface, COM) verfügbar gemacht wurden. Wo doch „viele Auguren“ prophezeiten, dass nun auch .NET im OS weiter und weiter Fuß fassen wird.
  6. Und wenn man die angehende Diskussionen und Gerüchte um WinC++ und eine Modernisierung von COM (siehe letzte Artikel auf ZDNet) liest scheint unmanaged Code noch einiges Neues in Zukunft zu bieten.

Ich spare mir mal einen detaillierten Rückblick auf einzelne Sessions.
Wie immer auf solchen Konferenzen hört man bekanntes, in manchen Vorträgen schaltet man ab, oder macht seinen Kram 😉 …
und bei manchen hört man wirklich neues und wird aufmerksam auf Techniken, die man wirklich produktiv einsetzen kann.
Und was solch eine Konferenz auch mit sich bringt, ist neues „zwischen den Zeilen“. Man sieht zum Beispiel die Nutzung von Tools und Funktionen, die man noch gar nicht kannte (ich werde einiges, was ich selbst neu gelernt habe in einigen Artikeln noch verarbeiten). Viele dieser „Neuigkeiten“ für mich kamen in Vorträgen vor, die ich eigentlich als „nicht ganz so interessant“ und „kenne ich eigentlich“ eingestuft hätte. So irrt man eben manchmal.

Und sicherlich bringt solch eine Konferenz auch wieder einen guten Überblick über manche Funktionalität, die man sich alleine (auch mit einem Tutorial) nicht so gut erarbeiten kann. Hier in Prien war es für mich speziell die verschieden Ansätze der Libraries für „Parallel Programming“ (OpenMP und PPL) und auch was „Transactional Memory“ in C++ bringen kann.

Ein weiterer wichtiger Punkt: „Mal wieder aus seiner Höhle“ herauszukommen, wie es ein Teilnehmer in einer Frage-Session formulierte. Der Kontakt zu anderen Entwicklern in den Pausen. Der Austausch, wie man selber aktuell Probleme löst, auf was man hinarbeitet, eröffnet einem einen anderen Blick auf die eigene Arbeit und hilft auch zu anderen Einsichten.
Und wenn es nur die Erfahrung ist: „Ich bin nicht der einzige, der dieses und jenes Problem hat…“

Und nicht zu vergessen, ist es die Möglichkeit den Repräsentanten der verschiedenen Firmen auf den Zahn zu fühlen. Man bekommt zwar wie üblich oft keine 100% Antworten auf Fragen und manche Antwort wird durch Firmen-Policies verwässert, aber man kann zwischen den Zeilen doch oft etwas mehr als „Marketing“ herauslesen und sich ein Bild machen.

Speziell erwähnen will ich hier die für mich positiven und sehr offenen Worte von Boris Jabez erwähnen, der offen zugab, dass Microsoft in den letzten 10 Jahren keinen guten Job gemacht hat „natives C++“ in der Art zu unterstützen und zu propagieren, wie es eigentlich angebracht gewesen wäre. Ich will es mal ganz vorsichtig so formulieren.
Der Begriff der „C++ Renaissance“ macht ja langsam die Runde.
Die Zukunft wird es zeigen, dass es hoffentlich keine „reine Marketingmasche“ ist…

Relativ einmütig war die Meinung der Teilnehmer, dass es gut war nach all den Jahren endlich mal wieder eine „echte C++“ Konferenz zu haben und viele wünschen sich –  wie auch ich – dass dies keine Eintagsfliege bleibt.

Fazit für mich:
Die ADC zu C++ in Prien hat mir Appetit auf mehr gemacht

Ein absolut gelungenes Event an einem schönen Plätzchen am Chiemsee, interessanten Beiträgen und Referenten, eine schönen und gemütlichen Abendversanstaltung und guter Organisation.

Ich bin gespannt ob diese Konferenz wirklich im nächsten Jahr eine Fortsetzung findet. Mich persönlich würde es freuen und ich wäre in jedem Fall wieder dabei.  Hoffen wir, dass sich Träger und Sponsoren zu einer neuen ADC für C++ in 2012 finden.

ADC C++ Konferenz in Prien am Chiemsee – Tag 2

Ich wollte eigentlich schon über Tag 1 etwas schreiben, aber gestern ist es doch sehr spät geworden weil einige von uns nach einer Fahrt über den Chiemsee noch bis ca. Mitternacht mit Boris Jabez gesprochen haben.
Also wird es noch dauern bis ich noch etwas nachtrage.

Das Wetter ist super. Etwas über 100 Teilnehmer können hier die Gegend am Chiemsee zumindest in den Pausen genießen, wenn man nicht noch manchmal Fragen an die Referenten hat…

Meinen Tag für heute habe ich so geplant:

  • Intel Keynote: The Power for Second-Generation Intel® Core™ Processor Family for Software Developers – Aaron Coday
  • Software Transactional Memory in C++ – Michael Wong
  • Die C++ Releaseversion. Ein Buch mit sieben Siegeln? –Matthias Wedemeyer
  • Native C/C++-Code in der Cloud (Windows Azure)Cosmin Dumitru
  • Game Development with Visual Studio – Boris Jabes
  • DLL Injection – Matthias Wedemeyer

ADC C++ Konferenz in Prien am Chiemsee – Count Down

Die Gegend ist wirklich sehr schön ❗
Das ist der Ausblick oberhalb des Chiemsees auf einem Wanderweg Richtung Prien.

Leider werden wir von dieser schönen Landschaft morgen nicht soviel mitbekommen, wenn es um natives C++ geht auf der Advanced Devlopers Conference speziell zu C++.

Meine Agenda für den morgigen Tag sieht so aus (mal sehen, vielleicht wechsel ich noch,gerade bei den beiden letzten Sessions bin ich mir noch nicht sicher):

  • Microsoft Keynote: State of Native Development – Why You Should Care Boris Jabes
  • C++ Standard Committee Representative Michael Wong
  • Building Asynchronous And Parallel Applications With C++ Boris Jabes
  • Managed Wrapper Klassen mit C++/CLI Bernd Marquardt
  • Does & Don’ts in der Parallelprogrammierung Bernd Marquardt
  • Team Foundation Server 2010 Version Control Christian Binder

Mal sehen was der Tag bringt.
Jetzt werde ich noch mal in die Hotelbar gehen, denn Schalke liegt hoffungslos mit 2:1 hinten… 😉

Wenn man mal doch Hardware in einem auf Hyper-V gehosteten Server benötigt…

Virtuelle Server sind was tolles. Aber leider lässt sich doch nicht alles virtuell abbilden, denn manche Software braucht die Verbindung zur Hardware. Und hier hat Hyper-V doch eine klare Einschränkung. Man kann kann nicht einfach ein USB Device an dem Hyper-V Host anschließen und in einer virtuellen Maschine benutzen, wie das VMWare Workstation perfekt beherrscht..

In meinem Fall waren es folgende Devices, die ich in meinen virtuellen Maschinen benötigte:

  • Unseren Master-Dongle für die Dongleerzeugung (WiBu)
  • Ein USB-Modem für unseren Fax-Eingang
  • Ein USB-Seriell Adapter an der eine TK-Anlage angeschlossen ist und gesteuert wird
  • Ein weitere USB-Port nochmal für eine weitere TK-Anlage
  • Manchmal für den direkten Anschluß einer USB Festplatte/Sticks

Ich habe mir einige Lösungen angesehen, die alle die USB-Devices über das Netzwerk sharen. Manche sind spezielle USB-Hubs mit Netzwerkanschluss, andere reine Software Lösungen.

Im Einsatz ist nun USB over Ethernet von KernelPro als reine Softwarelösung gekommen.
Bei dieser Lösung wird auf dem Hyper-V Host nur die Server Komponente installiert. Am Host schließt man nun die gewünschten USB Geräte an, ohne deren Treiber zu installieren. Man wählt in der Server Software nun die USB Geräte aus, die über das Netzwerk an interne Server weitergereicht werden.
Auf dem internen virtuellen Server, wird nun die Client-Software installiert. Dort kann mannun die USB Geräte auswählen, die der Server zur Verfügung stellt und die man in der virtuellen Maschine benötigt. Entsprechende Portfreigaben in der Firewall sind natürlich zu beachten. Auf dem virtuellen Client werden nun wie gewohnt die USB-Treiber installiert.
USB over Ethernet läuft als Dienst sowohl als Client wie auch als Server. Man muss sich um nichts mehr kümmern, alle angeschlossenen Geräte werden auch bei entsprechenden Serverneustarts einfach durchgereicht wenn die Dienste wieder starten.

Die Oberfläche des Tools ist einfach und verständlich ohne Schnickschnack wie man sich das für ein Server-Tool wünscht, dazu ist der Speicherverbrauch und die Prozessorlast niedrig. Die Software läuft seit 2 1/2 Monaten unauffällig und stabil, wie es sein soll.

Auf was man unbedingt achten muss, wenn man an Manifesten für Assemblies herumbastelt

Ich habe für ein Projekt Manifeste zur Verwendung von Registration-Free COM Module gebaut.

Diese COM-Module wurden über ein Manifest in einer EXE geladen. Natürlich hatte jedes der COM Module wieder ein eigenes Manifest, die ich entsprechend angepasst habe. Jede COM-Class, die verwendet wird, muss ja in dem Manifest der DLL-Assembly aufgeführt werden.

Eigentümlich war, dass ich nach Änderungen der Manifeste und auch nachdem das COM Modul komplett neu gelinkt wurde, dennoch die EXE ihr Ladeverhalten nicht geändert hat. Manche COM-Klassen wurden nicht gefunden. Sobald ich aber den Rechner neu gestartet hatte funktionierte ab dann alles wie gewünscht und das geänderte Manifest schien nun wirksam zu sein.

Da gibt es einen Cache dachte ich mir. Und nach einiger Recherche im Internet stieß ich auf den folgenden interessanten Artikel von Junfeng Zang:
Windows Vista Sxs Activation Context Cache

Wie man lesen kann, wird bei jedem erfolgreichen Einlesen einer Anwendung und dem erfolgreichen Laden aller Manifeste und DLLs, die ganzen ermittelten Daten in einen Cache gespeichert. Da ich die EXE aber nicht geändert habe, wurden auch die untergeordneten Manifeste nicht neu gelesen, auch wenn diese geändert wurden.

Durch das Ändern des Datums der EXE werden die Cacheeinträge ungültig, und danach werden alle Aktivierungskontexte der Anwednung und aller anderen Assemblies neu geladen.

Feature Request: Always ask the developer before applying a service pack or a security fix to Visual Studio that need changed C++ runtime DLLs ATL/MFC/CRT

I know this is a German blog, but for reaching a wider range of developer this article is written in English 🙂

In the past security patches to Visual Studio were automatically installed on the machines of developers. This might have a great impact of to the shipment of the software that is created with this new pachted Visual-Studio version and it might cause incompatibilities with previous created modules.

And we all suffered under the problems that came with this patches and I don’t want to know how much time and money was wasted here.

Also I am aware of the risk that is caused when security fixes are not applied. But the last decision must be allowed to a developer if a fix is applied or not.

To avoid this I have a feature request that such security fixes to Visual Studio (any Version: VS-2005, VS-2008, VS-2010) is only applied to the developers machine if he is asked to do this!

Please use your vote and your words to comment this feature request ❗
Here is the link:

Always ask the developer before applying a security fix or service pack to Visual Studio that need changed the C++ runtime DLLs ATL/MFC/CRT

BUG: Black Patchday for all OS from XP and later 3. – MFC 8.0 (VC-2005) or MFC 9.0 (VC-2008) linked dynamically to the MFC may not find the MFC language DLLs after installation of the security packs dated April 12th 2011

This is the English translation of the already published German article:
BUG: Schwarzer Patchday für alle OS XP und später 3. – MFC 8.0 (VC-2005) oder MFC 9.0 (VC-2008) die dynamisch gelinkt wurden finden die MFC Sprach-DLLs evtl. nicht mehr nach Installation der Sicherheitspatches vom 12.04.2011

Affected are:

  • All programs created with MFC 8.0 and MFC 9.0 that link dynamically to the MFC DLLs .
  • All operating systems from Windows XP and later. 32bit as 64bit
  • Al programs that do not use an application local installation (program directory, see note at the bottom of the article). So all programs that use and depend on WinSxS and VCRedist_x86.exe ( VCRedist_x64.exe).
  • All programs that are localized and use the MFC90xxx.DLL or. MFC80xxx.DLL language-DLLs and the OS system language is not set to English.

It is affected due to the security fixes offered April 12th, 2011:

For VS-2005 SP1 http://support.microsoft.com/kb/2465367 and http://support.microsoft.com/kb/2467175
For VS-2008 SP1 http://support.microsoft.com/kb/2465361 and http://support.microsoft.com/kb/2467174

Failure description:

The MFC language DLLs (satellite DLLs) are not loaded any longer. Parts of the application appear in English and not the selected language from the OS.

Background:

To prevent loading of wrong satellite DLLs (Binary Planting), an internal function in appcore.cpp named _AfxLoadLangDLL was changed. It checks if an activation context is active or not and if the DLLs should be loaded using this context. If there is an activation context active it is safe to load the satellite DLLs(MFCDEUxxx.DLL etc.) without defining a full path. If no activation context is active the path of the current application is used to load and find the satellite DLLs. The DLLs are loaded with a call to LoadLibrary.

The code used looks like this (empty lines removed):

...
TCHAR *pszFilename = ::PathFindFileName(szLangDLL);
ACTCTX_SECTION_KEYED_DATA data;
if (FindActCtxSectionString(
    FIND_ACTCTX_SECTION_KEY_RETURN_HACTCTX,
    NULL,
    ACTIVATION_CONTEXT_SECTION_DLL_REDIRECTION,
    pszFilename,
    &data) )
{
    // Load using the dll name only...
    hInstance = ::LoadLibraryEx(pszFilename, NULL, 0);
}
else
{
    // Load using the full path...
    hInstance = ::LoadLibraryEx(szLangDLL, NULL, 0);
}
...

The code looks OK.  And it is conform to the documentation of FindActCtxSectionString where the last parameter is defined as __out.

BOOL FindActCtxSectionString(
  __in   DWORD dwFlags,
  __in   const GUID *lpExtensionGuid,
  __in   ULONG ulSectionId,
  __in   LPCTSTR lpStringToFind,
  __out  PACTCTX_SECTION_KEYED_DATA ReturnedData
);

But the documentation of ACTCTX_SECTION_KEYED_DATA tells a different story:

Callers should initialize the ACTCTX_SECTION_KEYED_DATA structure as such:
„ACTCTX_SECTION_KEYED_DATA askd = { sizeof(askd) };“
which initializes all members to zero/null except the size field which is set correctly.

(BTW: In my eyes a documentation failure)

So what we see is that the code misses this: data.cbSize isn’t initialized
Now we have 3 possible scenarios what can happen with a  randomly initialized data.cbSize field:

  1. data.cbSize is larger than sizeof(ACTCTX_SECTION_KEYED_DATA):
    In this case the activation context is correctly detected. The program executes normal.  With an activation context no full path is needed. The MFC90xxx.DLL will be loaded from the WinSxS (Side by Side) or found over the common search path.
  2. data.cbSize is less than  sizeof(ACTCTX_SECTION_KEYED_DATA):
    In this case FindActCtxSectionString returns with an error. The DLL is now loaded with a full path name constructed from the application directory to prevent Binary Planting. Butthe problemis that with a normal installation the searched files are all in WinSxS, and the application directory has no such data. The DLL is not loaded.
    If the application local assemblies are used and placed in sub directories they aren’t found either.
  3. A future problem.
    If an OS will use a larger ACTCTX_SECTION_KEYED_DATA and data.cbSize has a greater value than the corresponding sizeof(…):
    We have a buffer-overrun!

I always recommend to use private and application local assemblies for the CRT and MFC DLLs. And to install all this files local to the application.
Years ago I wrote an article for this scenario that was published on CodeProject and a hotfix for VS-2008 is also available
Create projects easily with private MFC, ATL and CRT assemblies
Hotfix für UseMSPrivateAssemblies.h und VC-2008

What to do?

Uninstall all of the mentioned security fixes with the specified article IDs.
Runtime-2005: KB2467175, Runtime-2008: KB2467174
VS-2007 SP1: KB2465367, VS-2008 SP1: KB2465361).

Further notes:

The affected C/C++ Runtimes of Visual Studio have the following version numbers:
– VC-2005 8.0.50727.5592 (KB2467175)
– VC-2008 9.0.30729.5570 (KB2467174)

My comment to tis issue:
It was easier to live with the DLL-hell. 🙁

Many thanks to my Co-MVP Mike Ryan who helped me to discover this problems with the latest security patches:!:

What Do I mean with „application local“?
Some people ship the MFC files in the application directory. In such a case this DLLs are not loaded if a newer version can be found in the WinSxS directory. This is not application local for me!
So if the manifest file in the program directory still have a publicKey entry, the local files will be used  in case of the here described bug. Even if the activation context was not detected, so the local files are a kind of fallback and help prevent get around the problem.
My articles describe how to make your application really application local in removingthe publicKey tokens from the manifest files. Such programs will never fail on such broken security patches. (Just read my article at Codeproject). (Thanks for Co-MVP David Ching who asked me for a clarification)

Workaround für Patchday Bug vom 12.04.2011: Wenn unter Windows 2000 der Einsprungpunkt FindActCtxSectionStringA nicht gefunden wird

Hintergrund siehe hier:
BUG: Schwarzer Patchday für Windows 2000 – MFC 8.0 (VC-2005) und MFC 9.0 (VC-2008) DLLs sind nicht mehr lauffähig nach Installation von KB2467174 bzw. KB2467175
BUG: Schwarzer Patchday für Windows 2000 2.- MFC 8.0 (VC-2005) und MFC 9.0 (VC-2008) Static Libraries erzeugen auch inkompatiblen Code für Windows 2000 durch KB2465367 bzw. KB2465361

Unter Windows 2000 kann man wie folgt vorgehen und das Problem beheben:

  1. Am Besten macht man das nachdem man das System neu gestartet hat und noch keine Anwendung gestartet hat.
  2. Alle betreffenden Hotfixe entfernen (für Runtime-2005 KB2467175, Runtime-2008 KB2467174, für VS-2007 SP1: KB2465367, VS-2008 SP1: KB2465361).
    Die betroffenen C/C++ Runtimes des Visual Studio, die deinstalliert werden müssen, haben die folgenden Versionsnummern
    – VC-2005 8.0.50727.5592 (KB2467175)
    – VC-2008 9.0.30729.5570 (KB2467174)
    Um VS-2005/2008 wiederherzustellen ist zwingend eine Deinstallation des Patches nötig.
    Die Dateien für das Visual Studio sollten dann wieder denen des letzten Fix aus 2005/2008 entsprechen.
  3. Eigentlich sollte die Deinstallation des Patches genügen.
    Sofern es sich nur um ein Problem mit den Runtimes handelt und sich das Problem nicht behoben hat kann man mit den nächsten Schritten weiter machen und versuchen die alten Dateien wieder herzustellen.
    (
    Man kann diese Schritte auch ohne Deinstallation durchführen)
  4. Für VS-2008: Die Dateien für aus dem letzten Sicherheitsupdate müssten in dem folgenden Verzeichnis unter C:\WinNT\winsxs\ liegen:
    a. x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4974_…
    b. x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4148_…
    c. x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.1_…
    Man wählt das Verzeichnis, dass man zuerst findet.
  5. Für VS-2005: Die Dateien für aus dem letzten Sicherheitsupdate müssten in dem folgenden Verzeichnis unter C:\WinNT\winsxs\ liegen:
    a. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.4053_…
    b. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.4027_…
    c. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.1833_…
    d. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.762_…
    Man wählt das Verzeichnis, dass man zuerst findet.
  6. Alle Dateien aus diesen gefundenen Verzeichnissen in das C:\WinNT\System32 Verzeichnis kopieren.

Hope that helps ❗

PS: Ich habe den Artikel mehrfach überarbeitet während er bereits veröffentlicht war und immer neue Infos eingebaut bzw. die Vorgehensweise besser erklärt.

BUG: Schwarzer Patchday für alle OS XP und später 3. – MFC 8.0 (VC-2005) oder MFC 9.0 (VC-2008) die dynamisch gelinkt wurden finden die MFC Sprach-DLLs evtl. nicht mehr nach Installation der Sicherheitspatches vom 12.04.2011

Betroffen sind:

  • Alle Programme die mit MFC 8.0 oder MFC 9.0 erzeugt wurden und dynamisch an die MFC DLLs gelinkt sind.
  • Alle Betriebssysteme ab Windows XP aufwärts. 32bit wie 64bit
  • Alle Programme, die nicht die MFC und CRT DLLs applikationsnah (d.h. im Programmverzeichnis, siehe dazu auch die Fußnote in meinem Artikel) installiert haben. Also alle Programme die WinSxS benutzen und die VCRedist_x86.exe ( VCRedist_x64.exe)  mit ausliefern.
  • Alle Programme, die lokalisiert sind und die MFC90xxx.DLL bzw. MFC80xxx.DLL Sprach-DLLs verwenden und das OS nicht auf Englisch eingestellt ist

Betrifft die folgenden Fixes vom 12.04.2011:

Für VS-2005 SP1 http://support.microsoft.com/kb/2465367 und http://support.microsoft.com/kb/2467175
Für VS-2008 SP1 http://support.microsoft.com/kb/2465361 und http://support.microsoft.com/kb/2467174

Effekt:

Die MFC Statelite DLLs werden nicht geladen. Teile der Anwendung erscheinen in englischer Sprache.

Hintergrund:

Um das Laden von falschen Satelite DLLs zu verhindern (Binary Planting), wurde intern in appcore.cpp in der Funktion _AfxLoadLangDLL geprüft, ob die DLLs in aus einem Activation Context geladen werden oder nicht. Sollte ein Activation Context vorhanden sein, dann kann man gefahrlos die Sprach DLLs (MFCDEUxxx.DLL etc.) ohne Pfadnamen laden. Ist kein Activation Context vorhanden wird der Pfad der Anwendung verwendet und LoadLibrary mit vollem Pfadnamen durchgeführt.

Der Code der dazu verwendet wird sieht so aus (Leerzeilen entfernt):

...
TCHAR *pszFilename = ::PathFindFileName(szLangDLL);
ACTCTX_SECTION_KEYED_DATA data;
if (FindActCtxSectionString(
    FIND_ACTCTX_SECTION_KEY_RETURN_HACTCTX,
    NULL,
    ACTIVATION_CONTEXT_SECTION_DLL_REDIRECTION,
    pszFilename,
    &data) )
{
    // Load using the dll name only...
    hInstance = ::LoadLibraryEx(pszFilename, NULL, 0);
}
else
{
    // Load using the full path...
    hInstance = ::LoadLibraryEx(szLangDLL, NULL, 0);
}
...

Eigentlich sieht der Code prima aus. Und er verträgt sich auch mit der Doku von FindActCtxSectionString dort wird der letzte Parameter als __out definiert.

BOOL FindActCtxSectionString(
  __in   DWORD dwFlags,
  __in   const GUID *lpExtensionGuid,
  __in   ULONG ulSectionId,
  __in   LPCTSTR lpStringToFind,
  __out  PACTCTX_SECTION_KEYED_DATA ReturnedData
);

Aber die Doku zu ACTCTX_SECTION_KEYED_DATA sagt was anderes:

Callers should initialize the ACTCTX_SECTION_KEYED_DATA structure as such:
„ACTCTX_SECTION_KEYED_DATA askd = { sizeof(askd) };“
which initializes all members to zero/null except the size field which is set correctly.

(BTW: Auch ein krasser Doku-Bug in meinen Augen)

Und jetzt sieht man was dem Code fehlt: data.cbSize wird nicht gesetzt
Daraus ergeben sich nun drei Varianten, da data.cbSize nun zufälligen (nicht initialisierten) Inhalt hat:

  1. data.cbSize ist größer als  sizeof(ACTCTX_SECTION_KEYED_DATA):
    In diesem Fall wird korrekt ermittelt ob ein Activation Context vorhanden ist. Das Programm läuft normal. Mit Activation Context ist kein voller Pfadname nötig. Die MFC90xxx.DLL wird evtl. aus dem WinSxS (Side by Side) geladen, oder in einem der Suchpfade gefunden.
  2. data.cbSize ist kleiner als  sizeof(ACTCTX_SECTION_KEYED_DATA):
    In diesem Fall liefert FindActCtxSectionString einen Fehler und nun wird es spannend. Die DLL wird nun versucht mit dem vollen Pfadnamen zu laden um Binary Planting zu verhindern. Das Problem ist aber dass bei korrekter Installation im WinSxS, dass im Applikationsverzeichnis keine dieser Daten liegen. Die DLL wird nicht gefunden.
    Sollten die private applikationsnahe Assemblies in einem Unterverzeichnis installiert sein, werden diese auch nicht gefunden.
  3. Für die Zukunft.
    Ein zukünftiges OS vergrößert ACTCTX_SECTION_KEYED_DATA und data.cbSize hat zufälligen Inhalt und ist größer als sizeof(…):
    Ein Buffer-Overrun!

Ich empfehle nicht ohne Grund seit VS-2005 private Assemblies zu verwenden, und die MFC Dateien in das Anwendungsverzeichnis zu kopieren. Dazu habe ich auf Code-Projekt einen entsprechenden Artikel geschrieben und ein Hotfix für VS-2008 existiert auch ❗
Create projects easily with private MFC, ATL and CRT assemblies
Hotfix für UseMSPrivateAssemblies.h und VC-2008

Was ist zu tun?

Deinstallation aller hier erwähnten Sicherheitspatches mit den entsprechenden Arikelnummern:
Runtime-2005: KB2467175, Runtime-2008: KB2467174
VS-2007 SP1: KB2465367, VS-2008 SP1: KB2465361).

Weitere Anmerkungen:

Die betroffenen C/C++ Runtimes des Visual Studio haben die folgenden Versionsnummern
– VC-2005 8.0.50727.5592 (KB2467175)
– VC-2008 9.0.30729.5570 (KB2467174)

Mein Kommentar dazu:
Das Leben in der DLL-Hölle war fast angenehmer als das hier. Ohne Worte 🙁

Herzlichen Dank auch an meinem Mit-MVP Mike Ryan, der mit mir zusammen auf diese gesamte Problematik gestoßen ist ❗

Was meine ich mit „application local“?
Einige Entwickler installieren die MFC runtme Dateien im Applikationsverzeichnis. In diesem Fall werden diese DLLs nicht verwendet wenn eine neuere Version der DLLs im WinSxS Verzeichnis liegen. Das ist für mich keine applikationsnahe Instalation! Diese Manifeste im Programmverzeichnis haben immer noch einen publicKey Eintrag. Aber durch die Existenz der lokalen Dateien wird dieses hier beschriebene Problem umgangen, weil die lokalen Dateien eine Art Fallback bilden.
Meine Artikel beschriben wie man eine Anwendung wirklich applikationslokal macht und damit unabhängig von solchen „kaputten“ Security Patches. Dazu muss der publicKey Token aus den Manifesten entfernt werden. (Lesen Sie meinen Artikel aufCodeproject).
(Danke an Co-MVP David Ching der mich um Kläurung gebeten hat)

BUG: Schwarzer Patchday für Windows 2000 2.- MFC 8.0 (VC-2005) und MFC 9.0 (VC-2008) Static Libraries erzeugen auch inkompatiblen Code für Windows 2000 durch KB2465367 bzw. KB2465361

Wer VS-2005 SP1 oder VS-2008 SP1 installiert hatte und bei dem auch die entsprechenden Patches von gestrigen Tag (12.04.2011) durchlaufen wurden, der hat nun auch veränderte statische Libraries.

Sollte man nun also EXEs oder DLLs mit den neuen Libararies statisch linken, dann sind diese genausowenig lauffähig unter Windows 2000. wie auch die EXEs und DLLs die gegen die MFC 8.0 bzw. MFC 9.0 DLLs gelinkt werden

Das Ganze ist hier aufgelistet:
für VS-2005 SP1 http://support.microsoft.com/kb/2465367
für VS-2008 SP1 http://support.microsoft.com/kb/2465361

Die LIBs sind aufgeführt und auch diese verwenden auch die Funktion FindActCtxSectionStringA, die natürlich nicht unter Windows 2000 vorhanden ist.

Siehe auch:
http://blog.m-ri.de/index.php/2011/04/13/bug-schwarzer-patchday-fur-windows-2000-mfc-8-0-vc-2005-und-mfc-9-0-vc-2008-dlls-sind-nicht-mehr-lauffahig-nach-installation-von-kb2467175-bzw-kb2467175/

PS: Ich kann nur raten die entsprechenden Patches zu deinstallieren sofern man noch für Windows 2000 entwickelt und warten bis neue Securitypatches vorhanden sind.

Nachtrag:
Die betroffenen C/C++ Runtimes des Visual Studio haben die folgenden Versionsnummern
– VC-2005 8.0.50727.5592 (KB2467175)
– VC-2008 9.0.30729.5570 (KB2467174)