dotnet interop: executionEngineException -- dotnet interop

executionEngineException

JB
4/20/2008 9:20:01 AM

dotnet interop:

Vb.net app with COM control. The COM control is an object framer used by
the vb.net app to treat other apps( eg. word) as embedded objects. Generally
this all works fine. One of the functions of this COM control is to search
embedded app data for text ( 'Find' this or that.) This also works ok in
its orginal form. I would like to run the search in the background because
in some cases, it will search through many files and the problem comes when I
try to run the search on a separate thread. In this case, I create a thread
and in the thread proc, create the com control. crtl = New MyComCtrl seems
to execute ok but if I then try ctrl.SomeMethod, I get an
ExecutionEngineException , First chance exception at Ox.... in MyApp.exe:
Access violation reading location 0x...-- Again, the same code works if I
don't try to run it on a separate thread.

It there some way to get around this problem? I have tried creating the
control before creating the tread and then calling the control inside the
threadproc but got the same error. Maybe I need to do some explicit
initialization of the .ocx in the thread??

RE: executionEngineException

JB
4/20/2008 9:58:00 AM

Stand down

I changed the registration of the .ocx from
Threadingmodel = Apartment
to
Threadingmodel = Both
and that fixed the problem
--
JB

[quoted text, click to view]

Re: executionEngineException

Willy Denoyette [MVP]
4/20/2008 7:40:25 PM

[quoted text, click to view]

No, this is not a solution, by doing this you are fooling the system by
pretending that the component can be loaded into the MTA and COM will load
it into the newly created thread which enters the MTA by default, but beware
you are fooling yourself, here is why:
An OCX is not designed to be hosted in the MTA, because:
- OCX's are not thread safe, their accesses must be serialized, which is
automatically done by instantiating them in an STA thread.
- OCX's must be hosted in a ActiveX control container, an MTA is not such
container, the UI thread running a Windows Form is a valid container.

What you should do is:
1. set the Threadingmodel back to apartment and initialize your thread to
enter an STA by setting the ApartmentState attribute to STA2.
2. you'll need to pump the message queue, else you will have problems when
finalizing the COM component when you are done using it. Running a message
pump is done automatically when you create a Form and call Application.Run.
Willy.

..

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the dotnet interop group.