.NET Activex control access violation in MFC application

1

Background: I developed an Activex control in .NET, but found it was causing stability issues in various applications that used it. I managed to find a series of steps, from sample applications, similar unstabilities outlined below.

I have a sample Activex control that I've downloaded from the Dev-Center website called 'CSActivex' (http://code.msdn.microsoft.com/windowsdesktop/CSActiveX-b86194f8)

It was fairly easy to build, I just loaded the project up in VS2010 Express (C#) and it compiled into a .dll

I then created a sample MFC application from VS2008 C++ to model a legacy applications (it does not use any .NET). The target is the simple dialog based GUI that has an About box.

I registered the csactivex.dll with regasm and just copied the dll to the VS IDE folder, so I can insert the Activex control at design time, and then to the Debug folder, so it can be found during runtime.

At design time, I insert the CSActivex control onto the About dialog box, it appears with no surprises. After building and copying the dll to the Debug folder and run a debug session, if I continually navigate to the about box, click in various places on the control, close the about dialog and repeat a few times, I start to see messages in the output log about access violations, and it starts to look like this:

'CSActivexMFC.exe': Loaded 'C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System.Windows.Forms\63406259e94d5c0ff5b79401dfe113ce\System.Windows.Forms.ni.dll'
'CSActivexMFC.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorjit.dll'
'CSActivexMFC.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.2600.5581_x-ww_dfbc4fc4\GdiPlus.dll'
'CSActivexMFC.exe': Loaded 'C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\Accessibility\11eb4f6606ba01e5128805759121ea6c\Accessibility.ni.dll'
First-chance exception at 0x00000000 in CSActivexMFC.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x00000000 in CSActivexMFC.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x79f4c2f7 in CSActivexMFC.exe: 0xC0000005: Access violation reading location 0x0000000b.
First-chance exception at 0x79f4c2f7 in CSActivexMFC.exe: 0xC0000005: Access violation reading location 0x0000000b.

While it does not crash in the debugger, I can't help but think this in not good, and I have a feeling that it may be related to the instability of other .NET Activex controls. If I can figure out a way to solve this issue, the same resolution may help the original control.

I tried breaking on the exception, but it appears to happen in a few different places. one stack trace when I closed the applications is below:

mscorwks.dll!79f4c2f7() [Frames below may be incorrect and/or missing, no symbols loaded for mscorwks.dll]
mscorwks.dll!79f4c370() mscorwks.dll!79faaa91()
mscorwks.dll!79faa858() mscorwks.dll!79faa9ad()
mscorwks.dll!79faa9d9() mscorwks.dll!7a079480()
mscorwks.dll!7a0798e8() mscorwks.dll!7a043f25()
ole32.dll!77525834() rpcrt4.dll!77e799f4()
rpcrt4.dll!77ef421a() ntdll.dll!7c915239()
ntdll.dll!7c91542b() ntdll.dll!7c91534a()
ntdll.dll!7c915239() ntdll.dll!7c91542b()
ntdll.dll!7c91534a() ntdll.dll!7c915f75()
ntdll.dll!7c9155ed() ntdll.dll!7c915ce9()
ntdll.dll!7c96f07c() ole32.dll!77600c15()
ole32.dll!77600bbf() ole32.dll!7752ad31()
ole32.dll!7752ac56() ole32.dll!7752b771()
ole32.dll!77600e1f() ole32.dll!7752b7ab()
ole32.dll!7752b5e1() ole32.dll!7752b54e()
user32.dll!7e418734() ole32.dll!7752b54e()
ole32.dll!7752b54e() ole32.dll!7752b54e()
ole32.dll!7752b54e() ole32.dll!7752f2d0()
ole32.dll!7752f23e() ole32.dll!77557237()
mscorwks.dll!79f9e14d() mscorwks.dll!79f9e0b4()
mscorwks.dll!79f9e018() mscorwks.dll!79f4c879()
mscorwks.dll!79f3bb76() mscoreei.dll!603cc966()
mscoreei.dll!603d1f25() mscoree.dll!790186ad()

msvcr90d.dll!_crtCorExitProcess(int status=2) Line 716 C msvcr90d.dll!_crtExitProcess(int status=2) Line 722 + 0x9 bytes C msvcr90d.dll!doexit(int code=2, int quick=0, int retcaller=0) Line 644 + 0x9 bytes C msvcr90d.dll!exit(int code=2) Line 412 + 0xd bytes C CSActivexMFC.exe!__tmainCRTStartup() Line 595 C CSActivexMFC.exe!wWinMainCRTStartup() Line 399 C kernel32.dll!7c817077()

I was hoping someone may have run into this before, I'm running into this on mulitple machines (home and at work) and at least have it narrowed down to either a problem with CSActivex not doing something it should, or something in MFC.

so my question is how to get these samples working without the access violations?

Edit:

Just opening the about window and closing it repeatedly eventually results in a crash in the debugger (unhandled exception) with a stack trace below, to me it looks like an object that was destructed is being destroyed again?

First-chance exception at 0x00400003 in CSActivexMFC.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x00400003 in CSActivexMFC.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x003a005c in CSActivexMFC.exe: 0xC0000096: Privileged instruction.
First-chance exception at 0x00460020 in CSActivexMFC.exe: 0xC0000005: Access violation reading location 0x00460020.
First-chance exception at 0x78b6ba1d (mfc90ud.dll) in CSActivexMFC.exe: 0xC0000005: Access violation writing location 0x00000018.
Unhandled exception at 0x78b6ba1d (mfc90ud.dll) in CSActivexMFC.exe: 0xC0000005: Access violation writing location 0x00000018.


    mfc90ud.dll!CDataSourceControl::~CDataSourceControl()  Line 2431 + 0x2d bytes   C++
mfc90ud.dll!CDataSourceControl::`scalar deleting destructor'()  + 0x11 bytes    C++
mfc90ud.dll!COleControlSite::~COleControlSite()  Line 77 + 0x22 bytes   C++
mfc90ud.dll!COleControlSite::`scalar deleting destructor'()  + 0x11 bytes   C++
mfc90ud.dll!COleControlSiteOrWnd::~COleControlSiteOrWnd()  Line 161 + 0x24 bytes    C++
mfc90ud.dll!COleControlSiteOrWnd::`scalar deleting destructor'()  + 0x11 bytes  C++
mfc90ud.dll!COleControlContainer::~COleControlContainer()  Line 199 + 0x1c bytes    C++
mfc90ud.dll!COleControlContainer::`scalar deleting destructor'()  + 0x11 bytes  C++
mfc90ud.dll!CWnd::OnDestroy()  Line 786 + 0x24 bytes    C++
mfc90ud.dll!CWnd::OnWndMsg(unsigned int message=2, unsigned int wParam=0, long lParam=0, long * pResult=0x0012f510)  Line 2042  C++
mfc90ud.dll!CWnd::WindowProc(unsigned int message=2, unsigned int wParam=0, long lParam=0)  Line 1755 + 0x20 bytes  C++
mfc90ud.dll!AfxCallWndProc(CWnd * pWnd=0x0012f88c, HWND__ * hWnd=0x002c04fc, unsigned int nMsg=2, unsigned int wParam=0, long lParam=0)  Line 240 + 0x1c bytes  C++
mfc90ud.dll!AfxWndProc(HWND__ * hWnd=0x002c04fc, unsigned int nMsg=2, unsigned int wParam=0, long lParam=0)  Line 403   C++
mfc90ud.dll!AfxWndProcBase(HWND__ * hWnd=0x002c04fc, unsigned int nMsg=2, unsigned int wParam=0, long lParam=0)  Line 441 + 0x15 bytes  C++
user32.dll!7e418734()   
[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]    
user32.dll!7e418816()   
mfc90ud.dll!CThreadSlotData::GetThreadValue(int nSlot=6623744)  Line 268    C++
user32.dll!7e428eec()   
ntdll.dll!7c90e473()    
user32.dll!7e42b1a8()   
mfc90ud.dll!CWnd::DestroyWindow()  Line 1007 + 0xd bytes    C++
90909090()  
c#
c++
.net
mfc
activex
asked on Stack Overflow Jun 27, 2012 by PeskyGnat • edited Jun 27, 2012 by PeskyGnat

1 Answer

1

Take a look at this MSDN Blog by David Kline on What is a First Chance Exception.

From Blog

Does a first chance exception mean there is a problem in my code?

First chance exception messages most often do not mean there is a problem in the code. For applications / components which handle exceptions gracefully, first chance exception messages let the developer know that an exceptional situation was encountered and was handled.

For code without exception handling, the debugger will receive a second chance exception notification and will stop with a unhandled exception.

And by looking at another MSDN Blog by David Kline it will tell you how to Stop on a First Chance Exception to see what caused it.

And this MSDN Forum Posting

answered on Stack Overflow Jun 27, 2012 by Mark Hall • edited Jun 27, 2012 by Mark Hall

User contributions licensed under CC BY-SA 3.0