Debug Assertion failed error while using an mfc dll via import library in an managed console application
Wednesday, March 25, 2009 4:38 AMI have compiled the libtorrent library in an Visual Studio 2008 mfc dll project. I want to use this dll via an import library in a managed exe console application also developed in VS 2008.
The managed application project compiles ok. But when I try to run it I get the following assertion failed error message:
Debug Assertion Failed!
And when I press ignore I get the the following assertion failed error message
Debug Assertion Failed!
After I press the ignore button again the rest of the application works fine.
Althogh the path for the above files given by VS 2008 environment is not correct these files do exist in the following folder on my system
C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc
The following line in dllinit.cpp is cuasing the first assertion failiure:
ASSERT(AfxGetModuleState() != AfxGetAppModuleState());
And the following line in dllmodul.cpp is cuasing the second assertion failure:
Can any one help me out as to why these assertion failures are ocurring and how to resolve them?
- Moved by nobugzMVP, Moderator Wednesday, March 25, 2009 12:34 PM not a clr q (Moved from Common Language Runtime to Visual C++ General)
Wednesday, March 25, 2009 5:52 PMDebug asserts flags bugs for you. Maybe you did not initialize MFC's module state or CWinApp. Check http://www.codeproject.com/KB/miscctrl/HostMFC.aspx for an example.
- Marked As Answer by Nancy ShaoModerator Tuesday, March 31, 2009 3:30 AM
Wednesday, April 01, 2009 7:04 AMI am now certain that the problem is due a bug in the Libtorrent Library. Any ideas on how I can trace the source (or location) of the error.
Friday, April 10, 2009 8:23 PMI am having a similar problem. Part way through compilation (actually its during the linking phase), I get the debug assertion thrown on line 587 of dllinit.cpp.
I am pretty sure its not that I didn't initialize MFC's module state or CWinApp, since the assertion is thrown before the application actually runs.
Some background: we are using the CGAL 3.4 libraries which depend on the Boost libraries. Everything works just fine, until we upgraded to the latest version of Boost (1.38.0). With this version, CGAL compiles as expected, and most portions of our code that use CGAL or Boost compile as normal. Then, one portion of code that uses CGAL (but not Boost explicitly) throws this odd assertion at link time.
If you press Ignore or Retry, linking/compilation continues as if nothing went wrong, although the resulting binary falls quickly over due to heap corruption.
If you press Abort linking fails with the message "Error Code: Performing Registration".
Other than rolling back to the old version of Boost, does anybody have any ideas about how we might track down the source of our problem/get this working correctly?
Friday, April 10, 2009 8:28 PMDebug asserts flags bugs. If a linker throw a debug assert on you, then your linker has bugs. Find another linker instead.
Saturday, April 11, 2009 5:26 AMWe could not find the solution of our problem for mfc enabled dll project. So we tried another dll project (non mfc dll project) and we were able to successfully build the dll. But still we dont know what caused the assertion failiure and how to fix it in the mfc enabled dll. The error results in the built in dllmain function of mfc. Perhaps you can try to use a dll project where you can write your own dllmain function. In this way you will have greater control over the dll initialization process.
Saturday, April 11, 2009 5:10 PMI am using Visual Studio 2008 with the latest service pack. You are telling me that Microsoft's linker is broken and I need to use another one? I find it somewhat hard to believe that the linker shipped with VS2008 simply doesn't work, but what would you suggest instead?
EDIT: I should also add that the documentation for both of Boost 1.38.0 and CGAL 3.4 explicitly state that they are compatible with VS2008.
Saturday, April 11, 2009 6:00 PMThen you should not get a debug assert in compile or link time. Maybe you are confusing runtime and compile/link time.
Saturday, April 11, 2009 6:19 PMI agree that I should not be getting a debug assertion at compile time or link time. That's why I am here asking the question.
I am quite certain that I know the distinction between run time and compile/link time.
As I stated in my original posting, the problem occurs during link time and pressing "Abort" on the assertion causes linking to fail with the message "Error Code: Performing Registration". In this case NO EXECUTABLE IS PRODUCED AT ALL.
With no executable produced, it is hard to imaging how we could possibly be in run time yet.
As I also stated in my first post, if you press 'Retry' or 'Ignore' on the assertion, then visual studio continues to compile/link as if nothing went wrong. In this case it eventually produces an executable, which falls over very quickly due to heap corruption.
So, now that we are clear that the debug assertion is thrown BEFORE ANY EXECUTABLE HAS BEEN PRODUCED, does anybody have any suggestions?
Saturday, April 11, 2009 11:57 PMAh, now the problem is clear. The building process is registering your COM component via REGSVR32.EXE, and your DllRegisterServer function throws an error. To find out why, debug your project with REGSVR32.EXE as the target. Search "regsvr32 debug" in this forum for previous discussions about debugging a COM component via RegSvr32.
Sunday, April 12, 2009 2:46 AMOkay, now this is starting to sound promising. I will give it a try either tomorrow or Monday. Thanks for the advice.
Thursday, July 23, 2009 1:29 PMI have similar problem. When i upgrade boost form 1.33.1 up to 1.39 I get the following assertion failed error message:
Debug Assertion Failed!
when i rollback boost all run ok.
There are breaking changes in boost.thread http://www.boost.org/doc/libs/1_39_0/doc/html/thread/changes.html since 1.33
Interface of scoped_lock has been changed and boost::mutex now is boost::recursive_mutex.
Any help is appreciated.
Monday, August 03, 2009 10:23 AM
We had the same problem, it is problably because boost.thread overwrites the _pRawDllMain pointer. To fix this you need to patch your boost.thread library, in the file boost_1_39_0/libs/thread/src/win32/tss_pe.cpp comment the line which overwrites the pointer:
< // extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD, LPVOID)=&dll_callback;
> extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD, LPVOID)=&dll_callback;
and make suyre that you call the on_process_exit(); function when you exit/unload your library.
you need to include the following for this call:
Don't forget to recompile your boost.thread library after patching :-)
This issue is known by the boost.thread author and will be fixed in an upcomming release of boost, the fix above is suggested by the author here:
- Proposed As Answer by Willem de Jonge Monday, August 03, 2009 10:24 AM