What will cause AfxGetModuleState() return different values during DLL initialization?

What will cause AfxGetModuleState() return different values during DLL initialization?

• rab712

  Sure that all DLLs are using the same MFC version
  
  

• dida

  AFX_MANAGE_STATE(AfxGetModuleState( )) is redundant, as you're telling MFC to context-switch to the context it's already in.

  I would try to troubleshoot the multiple Dllmain issue. This still smells strongly like a AFX_MANAGE_STATE issue.

  Brian

  
  

• Dirty.Harry

  Is every DLL bound to the MFC80.DLL Or is one of files statically bound to the MFC
  
  

• Timothy P

  I don't think "static" refers to how the MFC library was linked.  It really means "the MFC state corresponding to this DLL."  Every MFC DLL maintains certain state information for that DLL only, and MFC has to be told that a DLL boundary has been crossed.

  Your observation "AfxGetModuleState returns the same value" tells me that MFC isn't updated on what module state it should be using.  That's your responsibility.

  You might have seen this comment when you run the MFC Dll wizard:

  //

  //TODO: If this DLL is dynamically linked against the MFC DLLs,

  // any functions exported from this DLL which call into

  // MFC must have the AFX_MANAGE_STATE macro added at the

  // very beginning of the function.

  //

  // For example:

  //

  // extern "C" BOOL PASCAL EXPORT ExportedFunction()

  // {

  // AFX_MANAGE_STATE(AfxGetStaticModuleState());

  // // normal function body here

  // }

  //

  // It is very important that this macro appear in each

  // function, prior to any calls into MFC. This means that

  // it must appear as the first statement within the

  // function, even before any object variable declarations

  // as their constructors may generate calls into the MFC

  // DLL.

  //

  // Please see MFC Technical Notes 33 and 58 for additional

  // details.

  //

  
  

• Soumya B

  That is for sure. I have checked that with depends.exe.
  

• JAG8

  AFX_MANAGE_STATE(AfxGetStaticModuleState( )) will cause the DLL fail to link( DllMain() already exist ). If I change it to AFX_MANAGE_STATE(AfxGetModuleState( )), I get no information from the macro. Thanks.
  

• Naynesh Shah

  Every DLL is bound to the MFC80d.DLL, none file is statically bound to MFC libraries. Thanks.

  
  

• Anders_And

  Could it be a failure to use

  AFX_MANAGE_STATE(AfxGetStaticModuleState( ));

  on your DLL entry points  This macro informs MFC that a DLL boundary has been crossed and needs to switch contextual information.

  Brian

  
  

• VBFan

  My Dlls are all MFC Extention Dll, according to Technical notes 58, I do not need to care about the module state.
  

• NSK

  I do not know if this could be helpful, the AfxGetModuleState() in the first 20 DLL's entry point returns the same value, while in the rest returns another.(according to the sequence of the DllMain() called)
  

• Prasad Honrao

  Thanks, Brian, I found a regular Dll in my solution. This regular Dll changed the value of modulestate without restoring it in the Dll entry point, DllMain(). I did nothing in DllMain() except the code the Wizard generated. I change this Regular Dll to Extension Dll, everything is ok, but I am still not sure, how can this happen. Another MFC application works fine with this regular Dll.
  

• Markus H

  True.  The theory I now have is that something is changing the value of pState->m_pModuleState and is not restoring it.  You can use memory breakpoints to track how this value changes.

  In afxstate.cpp, set a breakpoint at the top of AfxGetModuleState.  Run it, and then turn off that breakpoint so you don't get spammed with it during your diagnostic.  Now get the address of pState->m_pModuleState (put &pState->m_pModuleState in the watch window).  Under Debug menu, add New Data Breakpoint, and enter this address.  Then continue running with F5.

  The debugger will now take you to all lines that changes this value (press F5 to continue after each time).  You should find AfxSetModuleState being called from DllMain (and its variants) and the AFX_MAINTAIN_STATE2 constructor and destructor.  Since you are already aware of the module state changing after the 20th, you may be able to identify unbalanced changes to the module state.

  AFX_MANAGE_STATE itself creates an object that will both set and restore the module state, and MFC itself has them in its runtime.  These are probably not the problem; it's the other cases where the module state is being set without restoration that might be the culprit.

  Brian

   

  
  
• What will cause AfxGetModuleState() return different values during DLL initialization?