LoaderLock error

J

Julie

I have an application that uses an ActiveX control DLL. I just started
getting a LoaderLock error, but only when I debug and attempt to stop
at a breakpoint. If I don’t stop at the breakpoint, I don’t get the
error.

I believe this only started happening once I changed my code to add a
new thread, which handles the ActiveX control, along with the Windows
Form that it sits on. When I used to have this logic on the original
thread, I was able to set breakpoints with no problem.

Does this make any sense? What do I do?
 
P

Peter Duniho

Julie said:
I have an application that uses an ActiveX control DLL. I just started
getting a LoaderLock error, but only when I debug and attempt to stop
at a breakpoint. If I don’t stop at the breakpoint, I don’t get the
error.

I believe this only started happening once I changed my code to add a
new thread, which handles the ActiveX control, along with the Windows
Form that it sits on. When I used to have this logic on the original
thread, I was able to set breakpoints with no problem.

Does this make any sense? What do I do?

Hard to say without seeing a concise-but-complete code example that
reliably demonstrates the problem.

As you may know, the "LoaderLock error" is a Managed Debug Assistant
exception, reporting a _possible_ error in which you've attempted to
execute something during the loading of a DLL that could be a problem
(mainly, which could in turn require another DLL to be loaded, creating
a deadlock condition).


Unfortunately, there are benign, false positives that can occur. So
without seeing the specific initialization code, it's hard to know for
sure what might be wrong, if anything.

Personally, I'd be more concerned about the use of an ActiveX control
created on a thread different from your main Form's thread, especially
if that ActiveX control is actually a child control of the Form.
Managing multiple GUI threads in a single process is tricky enough, and
mixing those threads in the same window could be especially problematic.

And of course, it's _possible_ that your mixing of two windows that have
different owner threads into the same control hierarchy has led to the
LoaderLock exception, through some problem in the ordering of
initialization of the controls. I don't know, and there's not really
any way to know without seeing the code.

But even if not, I think you should probably restructure your code so
that the GUI parts all happen on the same thread. Background tasks
started by those GUI parts can, of course, still occur on other threads;
you just need to make sure the code specific to the window is executed
on the main thread.

Pete
 
J

Julie

Hard to say without seeing a concise-but-complete code example that
reliably demonstrates the problem.

As you may know, the "LoaderLock error" is a Managed Debug Assistant
exception, reporting a _possible_ error in which you've attempted to
execute something during the loading of a DLL that could be a problem
(mainly, which could in turn require another DLL to be loaded, creating
a deadlock condition).

Unfortunately, there are benign, false positives that can occur.  So
without seeing the specific initialization code, it's hard to know for
sure what might be wrong, if anything.

Personally, I'd be more concerned about the use of an ActiveX control
created on a thread different from your main Form's thread, especially
if that ActiveX control is actually a child control of the Form.
Managing multiple GUI threads in a single process is tricky enough, and
mixing those threads in the same window could be especially problematic.

And of course, it's _possible_ that your mixing of two windows that have
different owner threads into the same control hierarchy has led to the
LoaderLock exception, through some problem in the ordering of
initialization of the controls.  I don't know, and there's not really
any way to know without seeing the code.

But even if not, I think you should probably restructure your code so
that the GUI parts all happen on the same thread.  Background tasks
started by those GUI parts can, of course, still occur on other threads;
you just need to make sure the code specific to the window is executed
on the main thread.

Pete


Thanks for the response. So, to clarify, I have one main Form, which
gets created on the primary thread. I have a second Form (on which
sits the ActiveX control) on a second thread. Originally, I did write
it such that all of this was on one thread. However, for some reason
the ActiveX control did not respond in the expected way to a
particular function call when I had it this way. And when I broke it
into two threads, it did. (???)

To clarify your concern, is it a bad idea to have one form on one
thread and one form on another? I am trying to be good about not
controlling either form from the wrong thread.

I restarted my computer, and now I no longer see the LoaderLock error.
So, it's not predictable. Would that indicate anything if it occurs
sometimes and not other times?
 
P

Peter Duniho

Julie said:
[...]
To clarify your concern, is it a bad idea to have one form on one
thread and one form on another?

No, not per se. As long as you're careful about which thread is which,
it's perfectly fine to have multiple threads that own controls. It's
just that it can make the maintenance of the program more difficult,
which can lead to other problems.
[...]
I restarted my computer, and now I no longer see the LoaderLock error.
So, it's not predictable. Would that indicate anything if it occurs
sometimes and not other times?

Unfortunately, since the exception is not based on some specific
observation of a problem in the first place, it's not possible to
predict what variations in the occurrence of the exception might mean.

That said, I'd say that if you are no longer seeing the exception and it
doesn't come back, you might as well not worry about it for the time
being. :)

Pete
 
J

Julie

Julie said:
[...]
To clarify your concern, is it a bad idea to have one form on one
thread and one form on another?

No, not per se. As long as you're careful about which thread is which,
it's perfectly fine to have multiple threads that own controls. It's
just that it can make the maintenance of the program more difficult,
which can lead to other problems.
I restarted my computer, and now I no longer see the LoaderLock error.
So, it's not predictable. Would that indicate anything if it occurs
sometimes and not other times?

Unfortunately, since the exception is not based on some specific
observation of a problem in the first place, it's not possible to
predict what variations in the occurrence of the exception might mean.

That said, I'd say that if you are no longer seeing the exception and it
doesn't come back, you might as well not worry about it for the time
being. :)

Pete

Okay, I guess I'll worry about it the next time it happens (I'm not
too optimistic). :)

Thanks for your help!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top