Martin's Blog

Gestern Abend hatten wir hier auf der ADC 2012 für C++ in Ohlstadt bei einem schönen Abendevent eine Q&A. Letztes Jahr fand diese Q&A auf einer Schiffahrt auf dem Chiemsee statt. Dieses Jahr war es ein Fußweg von ca. 20 Minuten vom Konferenzhotel, zu einem großen “Grillplatz”, dort standen Zelte, Fackeln Lagerfeuer und es wurde gut gegessen und wie immer viel “Networking” betrieben.

Wie auch letztes Jahr sollten detailierte Fragen auf diese Q&A zu späterer Stunde vertagt werden.

DIE FRAGE die viele Entwicklern brennend interessierte war:
Kann man mit VS-11 Programme für Windows XP entwickeln oder nicht?

Rede und Antwort stand in diesem Fall Steve Teixeira, als Director of Program Management. Also in diesem Fall jemand, der wirklich etwas sagen und auch mit zu entscheiden hat.

Ich gebe seine Antwort von Steve, auf diese Frage zusammengefasst wie folgt wieder:

1. Zu dem Zeitpunkt als die Entscheidung für das Fallenlassen vom XP-Support gefällt wurde erschien dies als richtig.
   Jetzt muss man allerdings eingestehen, dass diese Entscheidung ein Fehler von Microsoft war.
2. Die Benutzerzahlen wurden weiter als sinkend berechnet. Man vermutete, dass zum Zeitpunkt der Veröffentlichung von VS-11 noch maximal 20% XP-Nutzer vorhanden wären. Neue Umfragen gehen aber von einer Verbreitung von mindestens noch 46% Windows XP Installationen aus.
3. Bei Microsoft wurde auch vermutet, dass es genügt den Entwicklern die neue VS-11 Oberfläche anzubieten aber das für das Compilieren das Toolset von VS-2010 genügen würde. Es wurde unterschätzt wie groß das Interesse an den neuen Compiler Funktionen in VS-11 mit C++11  ist. Was eben auch AMP und neue STL Funktionalität einschließt.
4. Die Folge ist nun, dass Microsoft die Entscheidung für das Fallenlassen des Windows-XP Support neu überdenkt.
   Allerdings kann dies nicht mehr bis zum RTM geschafft werden.
   (Anmerkung von mir: Aktuell in der Beta wurde der gesamte Code, der die Windows-Vista/7 Funktionen isoliert entfernt und alle DLLs werden implizit geladen).

Möglich ist also, dass es ein Featurepack geben wird, dass nach dem RTM ausgeliefert wird, und in dem es dann doch einen XP Support in allen Bibliotheken und im Compiler gibt.

Die Antwort erschien mir ehrlich und geradeaus und war gewisslich keine Vertröstung ohne echten Hintergrund.
Ich weiß nicht wie groß wirklich die Chancen sind, aber diese Aussage deckt sich auch mit den “Gerüchten”, die ich um 5 Ecken gehört habe, und deckt sich auch mit der internen Diskussion, die mit den MVPs geführt wird.

Meine persönliche Schätzung ist eine 25 prozentige Chance, dass wir doch noch einen Windows-XP Support im VS-11 erhalten werden.

Lassen wir und überraschen. Aber es ist eine gute Nachricht

PS: Ich schreibe dies direkt von der ADC für C++ 2012 in Ohlstadt.

Nachträge und Kommentare habe ich direkt in den Blog-Post übernommen, da diese manchmal übersehen werden:

Kommentar 1 vom 04.05.2012 von Steive Teixeira zur Klarstellung:

Hi Martin,
It was great to see you at ADC C++ this week! Just so that there is no confusion for the readers of your blog, the issue of XP support for C++ in Dev11 is one we’re taking very seriously, and we’re continuing to take customer feedback on Dev11 beta. However, we are not yet prepared to make an announcement on platform support for the RTM version of Dev11. We will be making an announcement on this in the coming weeks.
Thanks!
Steve

Kommentar 2 vom 04.05.2012 von Michael Kühlshammer 

Steve Teixeira schickte mir heute einen Link für einen Workaround und empfahl mir, dass möglichst viele Leute auf dem unten angegebenen Link einen Beitrag dazu schreiben sollen (dafür voten sollen), dass der VC11-Compiler auch Code für Windows XP erzeugt. Hier die Email-Antwort von Steve Teixeira:

“Thanks for your email. We continue to devote resources to and support MFC in Dev11. The Windows XP issue is still unsettled, and I appreciate your feedback on this. You me have seen that I posted some of my thoughts on XP support in the comment thread of this blog entry on the VC++ team blog: http://blogs.msdn.com/b/vcblog/archive/2012/04/18/10295093.aspx.

Thanks again,
Steve

Wenn man ein COM Objekt erzeugt und dieses im System über die ROT (Running Object Table) sichtbar, dann sollte man normalerweise Weak-Locks benutzen. Das kann man auch in der Doku zu RegisterActiveObject  nachlesen. Ansonsten wird es schwierig zu entscheinden, wann man seine Objekte zerstören kann.

Wenn aber nun eine Anwendung sichtbar gemacht wird, also das Objekt vom Benutzer übernommen wird, dann darf es ja nicht beendet werden, wenn der externe Erzeugende Prozess beendet wird und die letzte Referenz zu dem Objekt beendet wird.

Wie verhindert man das?

Die Lösung ist relativ simpel. Solange die Anwendung sichtbar ist, oder besser, wenn sie sichtbar wird ruft man einmalig CoLockObjectExternal auf! Dadurch wird ein weitere Lock auf das Objekt ausgeführt.
Aber Achtung Hier wird keine Referenzzählung verwendet. Egal wie oft man CoLockObjectExternal aufruft, der Referenzzähler wird nur einmal erhöht.

Beendet der User das Programm entsperrt man das Objekt wieder. Sollten keine weiteren Objekte in der Anwendung benutzt werden, dann terminiert die Anwendung wenn man alles richtig gemacht hat
Man ruft CoLockObjectExternal am Besten entweder auf, wenn die Anwendung sichtbar wird (WM_SHOWWINDOW) und erneut wenn WM_CLOSE aufgerufen wird. Die MFC macht alles fast automatisch richtig, bis eben auf die Aufrufe von CoLockObjectExternal, die man selbst im Code unterbringen muss, wie auch die Registrierung der Objekte in der ROT.
Ist noch eine externe Referenz vorhanden wird die Anwendung nicht terminiert, weil der interne Objektzähler der MFC dies verhindert (Code in CFrameWnd::OnClose). Ist kein externer Lock mehr vorhanden sperrt CoLockObjectExternal die Anwendung vom terminieren weil damit exakt eine Referenz aufrecht erhalten wird. Wird durch den Benutzer das Schließen der Anwednung angefordert wird dann im WM_CLOSE diese letzte Refrenz aufgelöst und die Anwednung kann terminieren auch wnen noch ein Eintrag in der ROT vorhanden ist. Dieser wird dann beim Beenden der Applikation auch entfernt.

In den C++ Compilereinstellungen finden sich ein vorgegebener Makro %(PreprocessorDefinitions) in den C++ Präprozessor Definitionen. Die Verwendung dieses Makros ist nicht ganz offensichtlich.

Dieser Makro sollten in jedem Fall nicht entfernt werden, denn Sie dienen der Übernahme einiger Einstellungen aus der General-Seite für die C++ Projekte. Zum Beispiel werden die Einstellungen für Unicode und MBCS über den Makro %(PreprocessorDefinitions) in die allgemeinen Compiler-Einstellungen übernommen (die entsprechenden Defines sind _UNICODE; UNICODE; _MBCS ).
Erzeugt man eine DLL wird zusätzlich _WINDLL gesetzt.
Setzt man ATL Optionen in der General Seite wird auch über die %(PreprocessorDefinitions) _ATLDLL bzw. _ATL_STATIC_REGISTRY gesetzt oder zurückgesetzt.
Gleiches gilt, wenn die MFC als shared DLL verwendet wird. In diesem Fall wird der Define _AFXDLL zusätzlich gesetzt.

Löscht man also %(PreprocessorDefinitions) dann werden alle diese Einstellungen nicht mehr  korrekt übernommen.

Anmerkung:
Bei dem Linker Makro %(AdditionalDependencies) habe ich eine ähnliche Verwendung vermutet, konnte aber keine direkte Beziehung zur Seite General herstellen.

Obwohl es auch hier Einflüsse auf die Linkereinstellungen gibt bei Änderungen in den General-Einstellungen. Werden allerdings die MFC als zusätzliche Bibliothek ausgewählt werden die Standard-LIBs aus dem SDK komplett entfernt. Hier gibt die MFC Bibliothek selbst vor in welchen zusätzlichen Libs, des SDK gesucht werden soll über #pragma comment(lib,..).

Dann will ich mal das Problem lüften, dass sich mit diesem Code ergibt, dein ich meinem letzten Artikel vorgestellt habe:

template <class T>
void SecureClearString(T &strText)
{
  ::SecureZeroMemory(strText.GetBuffer(0),strText.GetAllocLength());
  strText.Empty();
}

Zuerst einmal liegt es nicht daran, dass es hier Template verwendet wurde.
Ein Template wurde verwendet, weil in dem Code nicht nur CString, sondern implizit CStringA und CStringW verwendet wurde. Der Code sollte also mit beiden Typen funktionieren.

Und damit sind wir bei Problem 1, das auch gelöst wurde:
Wenn ein CStringW verwendet wird, dann wird nur die Hälfte des Strings gelöscht, und nicht alles.

Das Szenario, dass zu einem miesen Crash führen kann, will ich nun in den einzelnen Schritten schildern (es wurde ja vermutet, dass es mit GetBuffer zusammenhängt und die Vermutung ist richtig):

1. Der CString der mit diesem template behandelt wurde enthielt einen größeren CString und anschließend wurde ein kürzerer CString zugewiesen. Damit ist GetAllocLength>GetLength.
2. Dieser CString wird nun an eine weitere Variable zugewiesen. Durch die Referenzzählung wird keine volle Kopie erzeugt.
3. Nun kommt unsere schöne Funktion ins Spiel und einer der beiden Strings wird mit dieser Template Funktion behandelt.
4. Die Funktion hat zwei Argumente, die von rechts nach links berechnet und auf den Stack geschoben werden.
5. D.h. Zuerst wird GetAllocLength ausgeführt. Und dies ergibt einen Wert für die Länge, der ursprünglich einmal in diese Variable passte.
6. Als zweites erfolgt nun der Aufruf von GetBuffer. Da wir aber einen CString haben, der mehrfach benutzt wird, muss nun ein Copy on Write erfolgen. D..h. der String wird kopiert und mit der jetzt benötigten Länge neu alloziert und der Zeiger auf diesen Speicher wird zurückgegeben, dieser ist aber eben kürzer als der ursprüngliche Puffer.
7. Und nun erfolgt der memset, auf einen Speicher der nur noch so groß ist wie der kurze String. Folgerichtig wird der Heap zerstört, weil der Speicher hinter dem String überschrieben wird.
8. Peng Wir haben hier einen ganz miesen Seiteneffekt.

Hier der Code, mit dem man den Crash gezielt nachbauen kann:

void Crash()
{
  CString str1 = _T("12345678901234567890");
  str1 = _T("123");
  CString str2 = str1;
  SecureClearString(str1); // Crash
  SecureClearString(str2);
}

Der Vollständigkeit halber will ich aber auch noch ein Stück Code zegen, der es richtig macht:

template <class T>
void SecureClearString(T &strText)
{
  // We need this only if there is a private buffer
  if (strText.GetAllocLength()!=0)
  {
    // Execute GetBuffer first. This might cause a fork and may change
    // GetAllocLength.
    T::XCHAR *pBuffer = strText.GetBuffer(0);
    size_t iLen =strText.GetAllocLength();
    ::SecureZeroMemory(pBuffer,iLen*sizeof(T::XCHAR));
  }
  strText.Empty();
}

PS: Der Leser kann sich denken, dass mich dieser Bug und die entsprechende Reproduktion einige Nerven gekostet haben.  Denn es war nicht einfach die Vorbedingung (erst langer String, dann kurzer String, dann Zuweisung) zu ermitteln. Und wie es oft so ist führen Heap-Fehler erst sehr verzögert zu einem Problem.
Wen es genau interessiert: Ich habe ca 7 Stunden an dem Fall geknobelt und hatte 3 verschiedene Crashdumps zur Verfügung. Selbst konnte ich diesen Fehler in unserem Testfeld zuvor nicht erzeugen, weil eben nie alle Bedingungen erfüllt waren. Erst als mir klar war wo das Problem lag, gelang es mir natürlich auch sofort Eingaben zu erzeugen, die den Crash reproduzierten.

Für manche Standardklassen bzw. Header oder Libraries ist es manchmal schön zu wissen ob die ATL oder die MFC in einem Projekt verwendet werden.  In der Vergangenheit habe ich dies oft benutzt um bestimmte Member in Klassen einzubauen, die dann zum Beispiel Daten auch als CString aktzeptieren, oder diese Member dann eben nicht einzubauen um eine Nutzung in einem “puren” WinAPI Projekt zu ermöglichen.
Seit die CString Klassen allerdings eigenständige Templates wurden ist dieser Grund für mich eigentlich weggefallen.
Ich benutzte es heute nur noch um evtl. Memberfunktionen zu unterscheiden die evtl. CWnd* zusätzlich zu HWND Parametern akzeptieren.

Aber wer weiß, vielleicht hat der eine oder andere doch die Frage wie er erkennen kann ob die ATL oder die MFC in einem Projekt Verwendung finden.

Vordefinierte Preprozessor Variablen gibt es dafür nicht, allerdings kann man erkennen ob die Standard ATL/MFCHeader in einem Projekt bereits als Include eingefügt wurden, denn in diesem Fall kann man die Existenz der Include-Guards prüfen.

Die MFC benutzt __AFX_H__ als Guard für die afx.h.
Die Basisklassen der ATL befinden sich in der atlbase.hund entsprechend lautet der Guard: __ATLBASE_H__.

Sofern also diese Guards definiert sind wurden auch die entsprechenden Libraries in der stdafx.h oder anderen Headern zuvor included.

Nachtrag 12.07.2011:
Stefan hat natürlich vollkommen recht mit seinem Kommentar, dass es die zwei Präprozessor-Variablen _MFC_VER und _ATL_VER gibt, die natürlich für den hier erwähnten Einsatz weitaus besser geeigent sind.
Siehe: http://msdn.microsoft.com/de-de/library/b0084kay.aspx
Ich habe hier den Wald vor lauter Bäumen nicht gesehen
Herzlichen Dank für diese produktive Ergänzung.

Ich bin Tastatur-Fan und ich achte in meinen Anwendungen immer darauf, dass ein Benutzer meine Anwendungen einfach mit der mit der Tastatur bedienen kann. Accelerator sind in Windows für den Entwickler hier ein einfaches Tool, Funktionen über die Tastatur einfach verfügbar zu machen.

Tastatur Acceleratoren werden in der MFC in CFrameWnd geladen und PreTranslateMessage angewendet. Üblicherweise passiert das Laden direkt wenn LoadFrame ausgeführt wird, oder wenn in einer MDI-Anwendung das Childframe mit dem entsprechenden Document-Template erzeugt wird.

Allerdings wird es spannend, wenn man den Accelerator wechseln will aufgrund verschiedener Ansichten oder Zustände in der Anwendung. Denn ein CMainFrame weiß ja eigentlich nichts von den Dokumententypen oder dessen Zustand. Und ich fände es eigentlich nicht schön entsprechenden Code imFrame zu verankern.

Zum Glück ist das auch nicht nötig, denn es gibt schon immer die zwei netten undokumentierten Funktionen CFrameWnd::GetDefaultAccelerator und CDocument::GetDefaultAccelerator.

Sobald eine Tastatureingabe in CFrameWnd::PreTranslateMessage ankommt wird CFrameWnd::GetDefaultAccelerator aufgerufen. Nur wenn diese Funktion NULL zurückgibt wird der im Frame gespeicherte m_hAccel verwendet. Nun und CFrameWnd::GetDefaultAccelerator ruft nun CDocument::GetDefaultAccelerator für ds aktuelle Dokument auf.
Damit kann nun das Dokument selbst über den Accelerator bestimmen, der verwendet werden soll. Wird NULL zurückgegeben wird der Accelerator des Frames verwendet.

In der MFC-Next ist das Verhalten etwas anders, weil dort der Keyboard Handler eingeschaltet ist, aber letzten Endes wird GetDefaultAccelerator auch von dort aufgerufen.

Accelerator sind ein einfach gutes Hilfsmittel um Funktionen in einem Programm über die Tastatur verfügbar zu machen.
Behandelt werden Accelerator in CFrameWnd::PreTranslateMessage. D.h. bevor eine Eingabe-Nachricht aus der Message Queue an ein Fenster ausgeliefert wird, bekommt das Fenster selbst und jedes Parent des Fensters die Nachricht zur Behandlung in PreTranslateMessage angeboten.

Aber das kann auch zu einem kleinen Problem werden. Nehmen wir an, wir haben eine Datenbank Anwendung und Bild-Hoch/Runter werden über Accelerator für das Blättern in den Datensätzen definiert. Soweit OK.

Was aber wenn man nun ein Inplace Control hat, oder eine kleine dynamische Listbox, die man einblendet und in der man nun auch blättern will? Dann wird der Accelerator im CFrameWnd zum Tastenschlucker und in dem Moment führen Bild-Hoch/Runter nicht zu dem gewünschten Blättern im Popupfenster.

Wie geht man nun vor?
Wenn man im View nun in PreTranslateMessage FALSE zurückgibt frisst der Accelerator im CFrameWnd die Taste. Gibt man TRUE zurück, dann wird die Nachricht nicht ausgeliefert. Der Trick ist eigentlich ganz simpel. Wenn alle PreTranslateMessage Funktionen FALSE zurückgeben wird die Nachricht ausgeliefert indem die beiden Funktionen TranslateMessage und DispatchMessage aufgrufen werden.
Das Ganze kann man abkürzen. Im PreTranslateMessage Handler des Fensters selbst  kann man nun einfach TranslateMessage und DispatchMessage aufrufen und nun TRUE zurückgeben. Das Fenster selbst oder evtl. sein Parent sorgt dafür, dass es die gewünschte Nachricht bekommt wie man es erwartet und der Accelerator im CFrameWnd wird umgangen.

Die Microsoft C/C++ Compiler haben schon immer eine durchgängige Versionsnummer, die mit den Produkten in denen sie eingebunden sind (z.B. VS-2010) nicht zu tun hat.

Diese Produktversion spiegelt auch auch in der vordefinierten Compiler Präprozessor Variable _MSC_VER wieder. Über diese Variable ist es zum Beispiel möglich verschiedene CRT oder STL Library Eigenarten abzufragen und entsprechen den eigenen Code für mehrere Compiler lauffähig zu machen. Gleiches gilt natürlich auch für den Code der MFC (siehe Anmerkung am Fuß der Tabelle).

Hier eine kleine Tabelle der Werte, die _MSC_VER für die verschiedenen Compiler annimmt mit ein paar zusätzlichen Hinweisen.

_MSC_VER  = Compiler
510  = C Compiler 5.1 (DOS)     - 1988?
       Mein aller erster Kontakt mit dem MS-Compiler
600  = C Compiler 6.x (DOS)     - 1990?
700  = C/C++ 7.0                - 1992
       Die UI war damals die PWB. MFC 1.0 wurde veröffentlicht
800  = Visual C++ 1.0           - 1993
       Existierte IMHO als 16bit und 32bit Compiler
900  = Visual C++ 2.0
       Existierte IMHO als 16bit und 32bit Compiler. MFC 3.0
1000 = Visual C++ 4.0           - 1995-03 ?
       Ab dieser Verison nur noch 32bit Compiler. MFC 4.0
???? = Visual C++ 4.1
       War nur für MSDN Subscriber verfügbar. Kam mit erstem Game/DirectX SDK.
???? = Visual C++ 4.2 und 4.21
       Erste Cross-Platform Version für Mac und PC. MFC 4.2, 4.21
1100 = Visual Studio 97 (5.0)   - 1997
       Enthielt weiterhin MFC 4.21
1200 = Visual C++ 6.0           - 1998-06
       Populärtse VC Version. MFC 6.0
1300 = Visual Studio.NET (2002) - 2002-02-13
       .NET hält Einzug. MFC 7.0
1310 = Visual Studio.NET 2003   - 2003-04-24
       MFC 7.1
1400 = Visual Studio 2005       - 2005-11-07
       MFC 8.0
1500 = Visual Studio 2008       - 2007-11-19
       MFC 9.0
1600 = Visual Studio 2010       - 2010-04-10
       MFC 10.0
1700 = Visual C++ 2011          - 2011 ???
       Produktname noch offen evtl. WinC++

Noch ein Hinweis auf _MFC_VER:
In der Tabelle habe ich nur die Versionen der zum Compiler passenden MFC Versionen aufgeführt. Die MFC setzt einen Define mit dem Namen _MFC_VER entsprechend. Dieser definiert ein WORD im Format 0xVVRR. Wobei VV für die Version der MFC steht in hexadezimaler schreibweise und RR für die Revision allerdings in dezimaler Schreibweise. Die aktuelle _MFC_VER von VS-2010 hat also den Wert 0x0A00 und in der MFC 4.21 wurde _MFC_VER als 0×0421 definiert.

PS: Auf die Idee für diese Tabelle kam ich durch eine Diskussion mit einem Teilnehmer auf der ADC für C++ in Prien, der auch schon x-Jahre mit dem MS-Compiler verbracht hat wie ich, und wir über die Entwicklung der Sprache C/C++ nachgedacht haben und was wann als Innovation unsere Programme veränderte. Eben ein typisches Bits+Bytes Gespräch…

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)

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.