MFCに動的にリンクされた通常のDLLをロードする際にappcore.cppのアサート

Question

MFCに動的にリンクされ、MFCに動的にリンクするWindowsサービス実行可能ファイルからロードされる通常のDLLで構成されるアプリケーションを継承しました。コードはMicrosoft Visual Studio 2008 Professionalを使用してコンパイルされています（古い、わかっています...）。このアプリケーションは数年前から「働いていました」が、私はappcore.cppで以下のアサーションのためにDebugビルドとして実行できないことが分かりました：

デバッグアサーションが失敗しました！ プログラム：C：F：\ DD \ vctools \ vc7libs \船\ atlmfc \ SRC \ MFC \ appcore.cpp ライン：の詳細については、380

プロジェクト\ CMM \デバッグ\ CMM.exe ファイル\あなたのプログラムがアサーションを引き起こす方法 失敗、アサーションに関するVisual C++ドキュメントを参照してください。

（押して再試行がアプリケーションをデバッグする）CWinAppコンストラクタに次のコードに対応

：

ASSERT(AfxGetThread() == NULL); 
pThreadState->m_pCurrentWinThread = this; 
ASSERT(AfxGetThread() == this); 

これはLoadLibrary経由でDLLをロードする際に発生していることを疑うに私をリードアプリケーションは、（リリースビルドの一部としてASSERTが含まれていないため）長年の判断よりも運が多く働いています。

MFCの理解では、一般にCWinAppという単一のインスタンスしか存在しませんが、この場合のようにMFCに動的にリンクする通常のDLLに追加のインスタンスを追加することは許されます。コードには、サービス実行可能ファイルに1つのインスタンスがあり、DLLに1つのインスタンスがあります。 CWinAppコンストラクタは、MFCフレームワーク内のいくつかの内部インスタンス用に1回、サービス実行可能ファイル内のインスタンス用に1回、DLL内のインスタンス用に3回呼び出されます。最初の2つはうまく動作し、3番目は爆発します。

エクスポートされた関数はすべてAFX_MANAGE_STATEで始まりますが（実行はこれまでにはなりませんが）、プリプロセッサのフラグは正しいと思います。 Microsoftのドキュメント（EXEの場合は_AFXDLL、DLLの場合は_AFXDLL、_USRDLLおよび_WINDLL）。

LoadLibraryの代わりにAfxLoadLibraryを使用してみました。私はLoadLibrary/AfxLoadLibrary関数呼び出しの開始時に

AFX_MANAGE_STATE(AfxGetStaticModuleState()) 

を含める場合は、CWinAppオブジェクトは実際に構築されているが、実行は、代わりにdllmodul.cppに吹きます。

これはなぜ起こっているのか、それを修正するために何をする必要があるのか​​誰にも分かりませんか？

EDIT

これは、アサーションが発生したときにコールスタックです：

mfc90d.dll!CWinApp::CWinApp(const char * lpszAppName=0x00000000) Line 380 + 0x1c bytes C++ 
cimdll.dll!CCimDllApp::CCimDllApp() Line 146 + 0x19 bytes C++ 
cimdll.dll!`dynamic initializer for 'theApp''() Line 129 + 0xd bytes C++ 
msvcr90d.dll!_initterm(void (void)* * pfbegin=0x1b887c88, void (void)* * pfend=0x1b887d6c) Line 903 C 
cimdll.dll!_CRT_INIT(void * hDllHandle=0x1b770000, unsigned long dwReason=1, void * lpreserved=0x00000000) Line 318 + 0xf bytes C 
cimdll.dll!__DllMainCRTStartup(void * hDllHandle=0x1b770000, unsigned long dwReason=1, void * lpreserved=0x00000000) Line 540 + 0x11 bytes C 
cimdll.dll!_DllMainCRTStartup(void * hDllHandle=0x1b770000, unsigned long dwReason=1, void * lpreserved=0x00000000) Line 510 + 0x11 bytes C 
ntdll.dll!_LdrxCallInitRoutine@16() + 0x16 bytes 
ntdll.dll!LdrpCallInitRoutine() + 0x43 bytes 
ntdll.dll!LdrpInitializeNode() + 0x101 bytes 
ntdll.dll!LdrpInitializeGraphRecurse() + 0x71 bytes  
ntdll.dll!LdrpPrepareModuleForExecution() + 0x8b bytes 
ntdll.dll!LdrpLoadDllInternal() + 0x121 bytes 
ntdll.dll!LdrpLoadDll() + 0x92 bytes 
ntdll.dll!_LdrLoadDll@16() + 0xd9 bytes  
KernelBase.dll!_LoadLibraryExW@12() + 0x138 bytes 
KernelBase.dll!_LoadLibraryExA@12() + 0x26 bytes 
KernelBase.dll!_LoadLibraryA@4() + 0x32 bytes 
mfc90d.dll!AfxCtxLoadLibraryA(const char * lpLibFileName=0x02a70ce0) Line 487 + 0x74 bytes C++ 
mfc90d.dll!AfxLoadLibrary(const char * lpszModuleName=0x02a70ce0) Line 193 + 0x9 bytes C++ 
CMM.exe!CMonDevDll::LoadDLL() Line 207 + 0x1b bytes C++ 
CMM.exe!CMonDevDll::LoadDllEntryPoints() Line 268 + 0x8 bytes C++ 
CMM.exe!CMonDevDll::Initialize(CMonDevRun * pMonDevRun=0x0019fe60) Line 186 + 0x8 bytes C++ 
CMM.exe!CCtcLinkMonDev::Initialize(CMonDevRun * pMonDevRun=0x0019fe60, CCtcRegistry & reg={...}, int nLinkId=1) Line 546 + 0x18 bytes C++ 
CMM.exe!CCtcLinkSwitchMgr::Initialize(CMonDevRun * pMonDevRun=0x0019fe60, CCtcRegistry & reg={...}) Line 188 + 0x14 bytes C++ 
CMM.exe!CMonDevRun::Initialize(ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > szServiceName="CimService") Line 257 + 0x16 bytes C++ 
CMM.exe!CMonDevService::Run() Line 202 + 0x2d bytes C++ 
CommonFilesD.dll!CCtcServiceBase::ParseStandardArgs(int argc=-1, char * * argv=0x02a51b44) Line 278 + 0xf bytes C++ 
CMM.exe!main(int argc=4, char * * argv=0x02a51b38) Line 126 + 0x16 bytes C++ 
CMM.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C 
CMM.exe!mainCRTStartup() Line 403 C 
kernel32.dll!@BaseThreadInitThunk@12() + 0x24 bytes  
ntdll.dll!__RtlUserThreadStart() + 0x2f bytes 
ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes  

Answer 1

私はようやく私のクラッシュの原因を突き止めることができました。私のDLLで使用されていたライブラリがBoost.Threadに静的にリンクしていたため、おそらくランタイムの不一致が原因でこの問題が発生していました。ライブラリをBoostに動的にリンクするように変更すると、問題が解決されたようです。