I am trying, whenever possible, to post the final conclusions reached in
regard to my initial posts. In this post, my fundamental problem was related
to unmanaged code corrupting memory.
The story probably won't surprise some veterans. I had code (including
unmanaged code) that had been working for over a year. And it had been in
hard use under stressful situations. It never exhibited any problems. I
recently began calling it via an async delegate. We also made a lot of GUI
changes and the exceptions were always happening upon one of several
InitializeComponent method calls completing.
Naturally, the last place I searched for the problem was in the oldest, most
well-tested, unchanged code. However, that is in fact where the problem was.
We had a RCW on an OCX. One of the OCX methods returned an array thru a
short int pointer. The default interop wrapper marshalled this not as an
array, but as a single element. We only used the first element, so it didn't
matter. However, that incorrect parameter marshalling was the root cause of
all the problems -- but it only showed up when we started calling a method
many levels higher via the async delegate.
Anyway, the problem was solved without the use of a 2nd AppDomain.
My experience underscores the advice Willy gave me on another thread
('System.ExecutionEngineException' occurred in Unknown Module):
"'System.ExecutionEngineException' are mostly related to marshaling between
managed and unmanaged code, so maybe you should start to
inspect your PInvoke declarations."
"Mountain Bikn' Guy" <vc@attbi.com> wrote in message
news:qdUpb.76576$mZ5.488839@attbi_s54...
I need some advice on this. I am working on a fairly complex calculator
app (C#) with lots of functions (and these functions in turn use math
functions from an unmanaged C DLL). A calculation takes a lot of time (up to hours),
and should run on a separate thread from the one that the GUI uses. The
GUI also needs to display various properties for each function (such as
parameters that can be set). It does this with property grid and other
grids (there are lots of functions and some have thousands of properties). The
GUI also needs to display a progress bar, etc. while the calculation is
running.
Does it make sense to use two AppDomains? (I'm considering only MBR --
otherwise I don't believe I gain any fault protection.) Will this have any
significant effect on performance? Will the calculator app (server)
running in a 2nd AppDomain perform the same? Will the various property grids
(complex -- with thousands of properties) respond about the same in the
GUI? I'm afraid that updating the GUI as it accesses the calculator functions
by ref across the app domain and then refreshes various large grids will slow
down a lot.
However, I'm in favor of separateAppDomains because the calculator needs
to run on a separate thread and because it relies heavily on unmanaged code.
At the moment, something in this unmanaged code seems to be stepping on
memory the GUI is using. I'm looking for the best way to solve this problem and
isolating the unmanaged code in an AppDomain seems like a good foundation
to start with (as long as the performance will remain acceptable).