Re: Release build crashes when creating dialog from DLL

Finally we found the reason for the crash. The DLL we build is a
dynamically linked MFC dll and it has its own CWinApp object. Before
calling the function in the DLL to launch a dialog, I added
AFX_MANAGE_STATE(AfxGetStaticModuleState( )); to switch the module
state for the resource handle to point to the DLL's own CWinApp
object. After that, the code works fine.

Besides, we found in the Debug build of the DLL, when the function in
the DLL to launch a dialog is called by the main application,
AfxGetApp() returns the handle to the main application's CWinApp
object, so the program does not crash (although this is not right).
However, in the release build, AfxGetApp() returns NULL pointer if the
module state is not switched using AFX_MANAGE_STATE(). That causes the
crash.

Following is what we found in MSDN that is related to our problem:

"By default, MFC uses the resource handle of the main application to
load the resource template. If you have an exported function in a DLL,
such as one that launches a dialog box in the DLL, this template is
actually stored in the DLL module. You need to switch the module state
for the correct handle to be used. You can do this by adding the
following code to the beginning of the function:

AFX_MANAGE_STATE(AfxGetStaticModuleState( ));"

and also:
"The ability to dynamically link a regular DLL to the MFC DLL allows
some configurations that are very complicated. For example, a regular
DLL and the executable that uses it can both dynamically link to the
MFC DLL and to any extension DLLs.

This configuration poses a problem with regard to the MFC global data,
such as the pointer to the current CWinApp object and handle maps.

Before MFC version 4.0, this global data resided in the MFC DLL itself
and was shared by all the modules in the process. Because each process
using a Win32 DLL gets its own copy of the DLL's data, this scheme
provided an easy way to track per-process data. Also, because the
AFXDLL model presumed that there would be only one CWinApp object and
only one set of handle maps in the process, these items could be
tracked in the MFC DLL itself.

But with the ability to dynamically link a regular DLL to the MFC DLL,
it is now possible to have two or more CWinApp objects in a process -
and also two or more sets of handle maps. How does MFC keep track of
which ones it should be using?

The solution is to give each module (application or regular DLL) its
own copy of this global state information. Thus, a call to AfxGetApp
in the regular DLL returns a pointer to the CWinApp object in the DLL,
not the one in the executable. This per-module copy of the MFC global
data is known as a module state and is described in MFC Tech Note 58.

The MFC common window procedure automatically switches to the correct
module state, so you do not need to worry about it in any message
handlers implemented in your regular DLL. But when your executable
calls into the regular DLL, you do need to explicitly set the current
module state to the one for the DLL. To do this, use the
AFX_MANAGE_STATE macro in every function exported from the DLL. This
is done by adding the following line of code to the beginning of
functions exported from the DLL:

AFX_MANAGE_STATE(AfxGetStaticModuleState( ))"