Suppose we're running a Python program in an environment where PATH contains a directory that contains msvcr90.dll version A and that python27.exe is manifested to use msvcr90.dll version B, which is available in the SxS store but not on PATH.

Normally, python27.exe's side-by-side (SxS) manifest contains a description of *precisely* the correct version of msvcr90.dll to use, version B, so when python27.exe starts, the NT loader ignores msvcr90.dll version A and loads msvcr90.dll version B.

Everything works fine until somebody calls ctypes.CDLL("c"); uuid.py, which tries to find "uuid_generate_random" in libc on module load, is an example of a component that unexpectedly tries to load libc through ctypes.

Now, when someone tried to load "c", ctypes internally maps "c" to the C runtime library using ctypes.util.find_msvcrt, then calls _ctypes.LoadLibrary, which calls the Win32 API function LoadLibraryA. LoadLibraryA tries to find "msvcr90.dll", but WITHOUT CONSULTING THE SXS ACTIVATION CONTEXT, meaning that LoadLibrary finds msvcr90.dll version A, not version B. msvcr90.dll version A isn't loaded yet, so the NT loader does the usual loading and initialization; msvcr90.dll version A's DllMain runs, notices that it's not being loaded as part of an SxS manifest, and presents the user with an R6034 error message, "an application has made an attempt to laod the C runtime library incorrectly".

The overall result is that users of Python programs see error message popups from "Microsoft Visual C++ Runtime Library" that, in most cases, are completely benign. This problem doesn't occur if the correct version of msvcr90.dll happens to be in PATH.

One solution is to have _ctypes.LoadLibrary use the correct activation context; another is to use GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS, (LPCTSTR) &fopen, &module) to retrieve a handle to the current C runtime library without having to go through LoadLibrary at all.