Preventing Exceptions from bringing down app

[Naveen]

Interprocess communication is very expensive. And if a process has to
be created for an addin then if a host has to load 1000 addins then as
per your advice it would create about 1000 process. In windows
createprocess is one of costliest API that's the reason App Domains
were created. For each process windows creates 10 threads then the
application would end up with 10000 threads.
Creating process for each addin is BAD, BAD idea. Read about the same
here http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx

 

[Michael Bray]

However; it clearly says you can catch them directly by putting a
catch block "at the top of your non-main thread, threadpool workitem,
or finalizer".

Have you experimented with that? Why is that not suitable for your
needs??

Because it relies on the plugin programmer to do that. If I was the plugin
programmer, then none of this would be a problem because I would guarantee
to myself that I would wrap everything in a try/catch. But I can't make
that guarantee about other programmers.

This ties into why I'm trying to prevent the plugin from creating new
threads. Because if they don't create threads, then I can guarantee that
the plugin host can capture any exceptions. But if they DO create threads,
then I cannot do this.

As a totally different approach... have you considered running the
"plug-ins" in a completley separate process. Then they can crash and
burn without their child threads throwing unhandled exceptions back
into your host application.

Yeah I thought about it briefly... But I'm doing this for my own personal
gratification as anything else, and I want to "do it the right way". I'm
sure I could probably force things to work if I did it this way, but it
wouldn't feel right.

Incidentally, I've been playing around with the ADMHost sample that Naveen
pointed out, and I feel like I'm close to what I want... like it's on the
other side of a wall that I just have to figure how to get around. I'm
still trying to wrap my head around exactly what is going on in ADMHost,
and there are a few things that are confounding me. Shawn Farkas' ADMHost
modifications feel like the right way to go - I just haven't yet been
successful in integrating it with my plugins library.

Right now, I can create a version of my application that can create
threads, or I can create one that cannot create threads. I'm trying to
figure out how to let plugin host create threads but not the plugins
themselves. I'm getting closer.

Here's the ADMHost discussion just for reference:
http://blogs.msdn.com/shawnfa/archive/2005/10/13/480210.aspx

-mdb

 

[42]

Interprocess communication is very expensive.

True, there is considerable overhead. But whether or not it matters is a
completely separate question. The application *might* need to do little
more than activate the add-in with some inital parameters and forget
about it for 20 minutes.

And if a process has to
be created for an addin then if a host has to load 1000 addins then as
per your advice it would create about 1000 process. In windows
createprocess is one of costliest API that's the reason App Domains
were created. For each process windows creates 10 threads then the
application would end up with 10000 threads.

1000 addins that each need to spawn potentially unstable child threads
to background processing is still a couple thousand threads. And if they
start flaking out and malfunctioning but the exceptions aren't getting
trapped you've still got a royal mess on your hands.

At any rate I'm sure we can come up with a worst case scenario for any
proposal.

Creating process for each addin is BAD, BAD idea.

That really depends on how many *active* addins there are expected to be
now doesn't it? Obviously in some cases it is a 'bad bad idea', but in
others where the number of addins will be quite small, or where there
may be a pile of addins but only one or two active at a given time, then
it wouldn't be much of an issue at all.

 

[Michael Bray]

This can be configured for the plugins alone. By this way the
host application would be able to create threads and manipulate with
them where as the plugins cannot do that. This is the whole idea of
Hosting Interfaces. So this is how when an application with Sql Server
crashes it wont crash the SQL Server. I hope i answered youre question.

OK So I have this working now - quite nicely actually. I used the ADMHost
sample and worked it out so that the host application can create threads on
the plugin's behalf, catching any exceptions that occur, but the plugins
can't create threads directly. This is EXACTLY what I was hoping for.

Now I only have one problem... The way that my application gets started is
that the ADMHost starts up, and then calls ExecuteAssembly on my EXE file.
This would be fine, except that ADMHost runs in a text command window. So
currently, in order to gain the benefit of these controlled AppDomains, I
have this DOS window floating on my desktop.

What can I do to prevent this window from appearing? Anyone have any
suggestions?

-mdb

 

[42]

Because it relies on the plugin programmer to do that.

Gotcha, I downloaded your example, and I see what you mean now.

If I was the plugin
programmer, then none of this would be a problem because I would guarantee
to myself that I would wrap everything in a try/catch. But I can't make
that guarantee about other programmers.

This ties into why I'm trying to prevent the plugin from creating new
threads. Because if they don't create threads, then I can guarantee that
the plugin host can capture any exceptions. But if they DO create threads,
then I cannot do this.


Yeah I thought about it briefly... But I'm doing this for my own personal
gratification as anything else, and I want to "do it the right way". I'm
sure I could probably force things to work if I did it this way, but it
wouldn't feel right.

Fair enough. Although I'm not sure what the 'right way' would be in this
case, short of being able to trap those exceptions. Anything else seems
a bit of a kludge.

FWIW, I also thought perhaps you could use the unhandled event handler
to record state and your programs last gasp would be to launch itself in
a new process where it could pick up the saved state and continue. But
that's no less a kludge than anything else.

Incidentally, I've been playing around with the ADMHost sample that Naveen
pointed out, and I feel like I'm close to what I want... like it's on the
other side of a wall that I just have to figure how to get around. I'm
still trying to wrap my head around exactly what is going on in ADMHost,
and there are a few things that are confounding me. Shawn Farkas' ADMHost
modifications feel like the right way to go - I just haven't yet been
successful in integrating it with my plugins library.

Right now, I can create a version of my application that can create
threads, or I can create one that cannot create threads. I'm trying to
figure out how to let plugin host create threads but not the plugins
themselves. I'm getting closer.

Yeah, it seems that you are close.

Here's the ADMHost discussion just for reference:
http://blogs.msdn.com/shawnfa/archive/2005/10/13/480210.aspx

I'm actually interested in this for a plugin architecture I'm working
with myself -- although in my case I'm not concerned about unhandled
exceptions, but more about malicious plugins. I'd like to restrict what
they can do; not that I think I am likely to make it totally secure, but
I was hoping to make some reasonable attempt at locking them down.

Good luck.

 

[Michael Bray]

Fair enough. Although I'm not sure what the 'right way' would be in
this case, short of being able to trap those exceptions. Anything else
seems a bit of a kludge.
Yeah, it seems that you are close.

I actually have a pretty fair working demo now... There's only a few
problems I'm currently experiencing:

1. The ADMHost starts up in a text window - more annoying than a problem
2. For some reason the plugin has to be in the same directory as the
application if I want to call back to the host to create a thread for the
plugin.

I'm actually interested in this for a plugin architecture I'm working
with myself -- although in my case I'm not concerned about unhandled
exceptions, but more about malicious plugins. I'd like to restrict
what they can do; not that I think I am likely to make it totally
secure, but I was hoping to make some reasonable attempt at locking
them down.

From what I've seen you should be able to utilize CAS pretty effectively
here. Part of the process of restricting the plugin's ability to create
threads is to grant it Execution permission but outside of a FullTrust
frame. You could easily add or modify the list of permissions that are
being given to match your local policy. Of course, there are only so many
things you can restrict, but it should cover most of the typical security
issues. (Access to file system, registry, etc.)

-mdb