Debug Assertion Failed...
-
Hi, I have an ActiveX component that I build using MFC. I use this component in my C# application. Every time I close my C# application, it generated this error:
Debug Assertion Failed!
Program: ...
File: f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp
Line: 1007
etc..
etc..
etc..I do the debugging and it fails on this line:
#ifdef _DEBUG
ASSERT(pMap->LookupPermanent(hWndOrig) == NULL);
#endifI know it is not an important question, because if it is in release, it works perfectly. But I was wondering, what can cause this problem? Please note: 1. This error only occurs on my specific application. 2. When I build a new C# application. It works fine. Any idea?
-
Hi, I have an ActiveX component that I build using MFC. I use this component in my C# application. Every time I close my C# application, it generated this error:
Debug Assertion Failed!
Program: ...
File: f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp
Line: 1007
etc..
etc..
etc..I do the debugging and it fails on this line:
#ifdef _DEBUG
ASSERT(pMap->LookupPermanent(hWndOrig) == NULL);
#endifI know it is not an important question, because if it is in release, it works perfectly. But I was wondering, what can cause this problem? Please note: 1. This error only occurs on my specific application. 2. When I build a new C# application. It works fine. Any idea?
RYU^^ wrote:
I know it is not an important question, because if it is in release, it works perfectly.
Probably not. The
ASSERTmacro is disabled when you're building for release, which means that the problem is only disguised in release mode. If you have a look at the surrounding comments in the wincore.cpp file, you'll find that this assertion is due to that the window handle has not been detached from the object handle map. When you use wizards to generate code for your application, as I assume you have, this assertion won't be triggered by the generated code. My point is that this is something else and I would bet my money on COM-related stuff. If you put some breakpoints to check which window it is that's causing problems, I would expect it to be an unknown window from your point of view. Some things to check up on:- Make sure that you release all interface references to your ActiveX when the application is closed.
- Make sure you calling
::CoUninitialize()for each time you've called::CoInitialize()or similar. - If you're using a secondary thread that operates on the ActiveX, you have to set up the COM library for that thread as well by calling
::CoInitialize() / ::CoUninitialize(). Remember that you also have to marshal the interfaces to the secondary thread.
You may find this article[^] to be interesting as well.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
RYU^^ wrote:
I know it is not an important question, because if it is in release, it works perfectly.
Probably not. The
ASSERTmacro is disabled when you're building for release, which means that the problem is only disguised in release mode. If you have a look at the surrounding comments in the wincore.cpp file, you'll find that this assertion is due to that the window handle has not been detached from the object handle map. When you use wizards to generate code for your application, as I assume you have, this assertion won't be triggered by the generated code. My point is that this is something else and I would bet my money on COM-related stuff. If you put some breakpoints to check which window it is that's causing problems, I would expect it to be an unknown window from your point of view. Some things to check up on:- Make sure that you release all interface references to your ActiveX when the application is closed.
- Make sure you calling
::CoUninitialize()for each time you've called::CoInitialize()or similar. - If you're using a secondary thread that operates on the ActiveX, you have to set up the COM library for that thread as well by calling
::CoInitialize() / ::CoUninitialize(). Remember that you also have to marshal the interfaces to the secondary thread.
You may find this article[^] to be interesting as well.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownHi Roger, I can call Dispose(). I think that is similar with ::CoUninitialize(); but where can I put that function? There is no Disposing event in the user control. I tried to put in Disposed event, but it still doesn't work :( Any idea? Thanks for your help again... :)
-
Hi Roger, I can call Dispose(). I think that is similar with ::CoUninitialize(); but where can I put that function? There is no Disposing event in the user control. I tried to put in Disposed event, but it still doesn't work :( Any idea? Thanks for your help again... :)
What is
Dispose()and what does it do? Do you have a link to it in MSDN? I thinkDispose()may be C# specific, so perhaps you should ask in that forum instead to get better suited answers."It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown