TL;DR: How do you isolate add-in exceptions from killing the main process?
I want to have a very stable .Net application that runs less stable code in an AppDomain. This would appear to be one of the prime purposes of the AppDomain in the first place (well, that and security sandboxing) but it doesn't appear to work.
For instance in AddIn.exe:
public static class Program
{
public static void Main(string[] args)
{
throw new Exception("test")
}
}
Called in my 'stable' code with:
var domain = AppDomain.CreateDomain("sandbox");
domain.UnhandledException += (sender, e) => {
Console.WriteLine("\r\n ## Unhandled: " + ((Exception) e.ExceptionObject).Message);
};
domain.ExecuteAssemblyByName("AddIn.exe", "arg A", "arg B")
The exception thrown in the AppDomain gets passed straight to the application that created the domain. I can log these with domain.UnhandledException and catch them in the wrapper application.
However, there are more problematic exceptions thrown, for instance:
public static class Program
{
public static void Main(string[] args)
{
Stackoverflow(1);
}
static int Stackoverflow(int x)
{
return Stackoverflow(++x);
}
}
This will throw a stackoverflow exception that kills the entire application every time. It doesn't even fire domain.UnhandledException - it just goes straight to killing the entire application.
In addition calling things like Environment.Exit() from inside the AppDomain also kill the parent application, do not pass GO, do not collect £200 and don't run any ~Finialiser or Dispose().
It seems from this that AppDomain fundamentally doesn't do what it claims (or at lease what it appears to claim) to do, as it just passes all exceptions straight to the parent domain, making it useless for isolation and pretty weak for any kind of security (if I can take out the parent process I can probably compromise the machine). That would be a pretty fundamental failure in .Net, so I must be missing something in my code.
Am I missing something? Is there some way to make AppDomain actually isolate the code that it's running and unload when something bad happens? Am I using the wrong thing and is there some other .Net feature that does provide exception isolation?
I'll throw on some random thoughts, but what #Will has said is correct regarding permissions, CAS, security transparency, and sandboxing. AppDomains are not quite superman. Regarding exceptions though, an AppDomain is capable of handling most unhandled exceptions. The category of exceptions that they are not is called an asynchronous exception. Finding documentation on such exceptions is a little more difficult now that we have async/await, but it exists, and they come in three common forms:
StackOverflowException
OutOfMemoryException
ThreadAbortException
These exceptions are said to be asynchronous because they can be thrown anywhere, even between CIL opcodes. The first two are about the whole environment dying. The CLR lacks the powers of a Phoenix, it cannot handle these exceptions because the means of doing so are already dead. Note that these rules only exist when the CLR throws them. If you just new-up and instance and throw it yourself, they behave like normal exceptions.
Sidenote: If you ever peek at a memory dump of a process that is hosting the CLR, you will see there are always OutOfMemoryException, ThreadAbortException, and StackOverflowException on the heap, but they have no roots you can see, and they never get GCed. What gives? The reason they are there is because the CLR preallocates them - it wouldn't be able to allocate them at the time they are needed. It wouldn't be able to allocate an OutOfMemoryException when we're out of memory.
There is a piece of software that is able to handle all of these exceptions. Starting in 2005, SQL has had the ability to run .NET assemblies with a feature called SQLCLR. SQL server is a rather important process, and having a .NET assembly throw an OutOfMemoryException and it bringing down the entire SQL process seemed tremendously undesirable, so the SQL team doesn't let that happen.
They do this using a .NET 2.0 feature called constrained execution and critical regions. This is where things like ExecuteCodeWithGuaranteedCleanup come into play. If you are able to host the CLR yourself, start with native code and spin up the CLR yourself, you are then able to change the escalation policy: from native code you are able to handle those managed exceptions. This is how SQL CLR handles those situations.
You can't do anything about Environment.Exit(), just like you can't prevent a user from killing your process in Task Manager. Static analysis for this could be circumvented, as well. I wouldn't worry too much about that. There are things you can do, and things you really can't.
The AppDomain does do what it claims to do. However, what it actually claims to do and what you believe it claims to do are two different things.
Unhandled exceptions anywhere will take down your application. AppDomains don't protect against these. But you can prevent unhandled exceptions from crossing AppDomain boundaries by the following (sorry, no code)
Create your AppDomain
Load and unwrap your plugin controller in this AppDomain
Control plugins through this controller, which
Isolates calls to 3rd party plugins by wrapping them in try/catch blocks.
Really, the only thing an AppDomain gives you is the ability to load, isolate and unload assemblies that you do not fully trust during runtime. You cannot do this within the executing AppDomain. All loaded assemblies stay until execution halts, and they enjoy the same permission set as all other code in the AppDomain.
To be a touch clearer, here's some pseudocode that looks like c# that prevents 3rd-party code from throwing exceptions across the AppDomain boundary.
public class PluginHost : IPluginHost, IPlugin
{
private IPlugin _wrapped;
void IPluginHost.Load(string filename, string typename)
{
// load the assembly (filename) into the AppDomain.
// Activator.CreateInstance the typename to create 3rd party plugin
// _wrapped = the plugin instance
}
void IPlugin.DoWork()
{
try
{
_wrapped.DoWork();
}catch(Exception ex)
// log
// unload plugin whatevs
}
}
This type would be created in your Plugin AppDomain, and its proxy unwrapped in the application AppDomain. You use it to puppet the plugin within the Plugin AppDomain. It prevents exceptions from crossing AppDomain boundaries, performs loading tasks, etc etc. Pulling a proxy of the plugin type into the application AppDomain is very risky, as any object types that are NOT MarshalByRefObject that the proxy can somehow get into your hands (e.g., Throw new MyCustomException()) will result in the plugin assembly being loaded in the application AppDomain, thus rendering your isolation efforts null and void.
(this is a bit oversimplified)
Related
I'm calling a native library that might be unstable and I want to make sure my C# app can survive a potential AccessViolationException. I found a way to catch the exceptions using <legacyCorruptedStateExceptionsPolicy enabled="true" /> in my App.config. Since the crash happens on a separate thread that I don't care about (I don't care if it dies), is it safe to keep my application running? If not, are there any mechanisms that would allow me to sandbox the native code to prevent crashes?
I don't just want to log the crash, I'm really trying to survive AccessViolationException.
I've tried executing the code in another AppDomain but it doesn't really help since it runs in the same process. I also already have a backup solution that relies on a new Process, and an IPC channel to communicate, but that's hard to maintain and debug. If I could do it in the main process that would simplify things a lot.
If you want to create an environment to test, just create a simple Win32 library with a single function that causes a crash (AccessViolationException).
C Header:
__declspec(dllexport) void do_crash();
C Source:
void do_crash()
{
int *b = NULL;
int c = b[3000];
}
C# source:
[DllImport("CrashLib.dll", EntryPoint = "do_crash")]
extern static void DoCrash();
static void Main(string[] args)
{
ExecuteSandboxed(delegate
{
DoCrash();
});
// Even if there's a AccessViolationException, I can keep going
Console.ReadLine();
}
private static void ExecuteSandboxed(Action action)
{
try
{
Task.Run(action).Wait();
Console.WriteLine("Success");
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
Exceptions in a Nutshell
The very basic idea behind exceptions is to say "This cannot be done" and to prevent the application from continuing with a corrupted state. When an exception is raised it usually allows for the application to current the situation and continue execution. This is done by rewinding the call stack and looking for exception handlers (try-catch blocks).
Exceptions can come from 3 major sources:
The application itself (using throw ...)
The OS - Exceptions such as FileNotFoundException
The CPU - Exception such as DivideByZeroException (which is raised because ALU can't preform such calculation)
The scariest exceptions by far are those raised by the CPU since they can leave it in an invalid state.
Furthermore exceptions can classified into one of three kinds:
Invalid Operation - Such exceptions are thrown when the application attempts to preform an invalid operation. Actions such as accessing nonexistent files, dividing by zero and so on.
Invalid thread state - Such exceptions are thrown when the state of a given thread is corrupted. Situations such as runtime-stack corruption are a possible cause.
Invalid process (application) state - Such exception are thrown when the entire application is in an invalid state. Running out of memory is a good example.
Each kind of exception is more severe then the one before. The first will terminate the current procedure and start call-stack rewind. The second will terminate the entire thread. And the last will terminate the entire application.
Note: The termination process is much more involved and exceptions are not really divided into the three kinds.
Understanding AccessViolationException
Now that we have a basic understanding of exceptions we can predict the state an AccessViolationException will leave our application in.
First of all, who throws the exception? This is kind of a trick question* but in practice it is thrown by the OS when it realizes that the address is not yet allocated to the process.
What kind of exception is it? Since the exception has nothing to do with the state of the thread nor the application; we just attempted to access "nonexistent" memory (much like we may attempt to access nonexistent files). This is clearly an Invalid Operation exception.
AccessViolationException is an Invalid Operation exception from the OS. Now that we know that we can safely continue execution sine we know for certain that we didn't invalided the CPU state, nor the Application state, nor the Thread state; we just attempted something illegal.
I'm loading in a dll that spawns a few threads within itself. Every now and then the program crashes with an unhandled exception. I can't wrap all my library calls in try/catch statements because the exceptions are being thrown on separate threads, and I don't have access to the library's source to debug/fix the bad error handling. I'd like the program to keep doing other things when these exceptions happen, is there a graceful way to handle these exceptions? Or is the only thing I can do to do a global catch all exceptions method?
If you load the DLL into a separate appdomain, you should be able to isolate exceptions generated with a AppDomain.UnhandledException, but, be aware that this is not fool proof and there are certain situations where it will still take your process out too and there is nothing you can do about it (stack overflow, out of memory etc).
The best you can do in that case is load them in a separate process completely with some kind of dll communication harness and using some form of remoting to talk to that process.
I would recommend to implement a separate process (EXE) which your application launches and which in turn loads the DLL.
This allows you to kill/restart the process whenever need be...
I see several options on how to communicate - for example:
you could use COM (if you implement it as an out-of-process COM server)
you could use shared memory (very high performance, see this for a walkthrough and this for a .NET 2 wrapper)
IF the method must be compatible with several Windows versions THEN I would refrain from using anything "networky" for the IPC (since some come with a desktop firewall).
"The isolation provided by application domains has the following benefits:
Faults in one application cannot affect other applications. Because type-safe code cannot cause memory faults, using application domains ensures that code running in one domain cannot affect other applications in the process."##
http://msdn.microsoft.com/en-us/library/2bh4z9hs.aspx
The above words was got from The MSDN,
My questions are,
1, The "Faults" in the sentence refer to the exception ,or something else?
2, what is The "Faults in one application cannot affect other applications" means?,
Does it means if there throw an exception in one Application Domain ,that exception will not crash other Application Domains, right?
Can you give me an example ?
The article talks about memory isolation. Managed code can't arbitraty modify memory (without unsafe) unlike C/C++ thus managed code running in one AppDomain will not corrupt memory in other AppDomain. I.e. buffer overflow kind of errors are prevented by managed runtime, while easy to achieve in C/C++ like int arr[4]; arr[-1]=2;.
Exceptions are not scoped to AppDomain (or rather behave similar with/without AppDomains) - most exceptions will only impact code that called method that throws exception, some (i.e. StackOverflow) by default will terminate the process. If normal exception is unhandled it normally will cause process termination. Exceptions are free to cross AppDomain boundaries if code on the stack bekongs to multiple AppDomains.
I am writing a chess game which allows two programs compete, the player needs to write a DLL and expose a function to tell the main application where his player will move next, suppose the function looks like this
public static void MoveNext(out int x, out int y, out int discKind);
The player's DLL can be written using C# or C++.
In the chess game application, I start a new thread to call the function that the player's DLL exposed to get where he will move in a turn, and I start a timer to prevent the player timeouts, if a player timesout i will kill the corresponding thread by following APIs
thread.Abort();
thread.Join();
I have the following issues as described below:
The thread cannot be killed with 100% assurance (it depends on the player's code)
During test I found that, if the player uses a deep recursions (and if there is memory leak in the player's program), the memory usage of the host application will increase and then the host application will be terminated without any exceptions.
Are there any techniques, ideas or methods that can handle the above issues?
From this CodeInChaos suggested to load player's DLL into separate domain and then unload it when necessary, I am not sure if it still works for the unmanaged DLL (C++) and if it will cause a low efficiency?
An unhandled exception in their AppDomain will still cause your program to terminate in .Net 2.0. You get a chance to respond to the exception through an event handler but not the ability to handle it.
Your best bet is to use processes for the kind of isolation you're looking for.
If you can ensure your plugin DLL's are always managed code, then you have the option of createing a new application domain in your main application logic and loading the assembly containing the plugin into that domain.
This then gives you the option of trapping unhandled excpetions in that specific app domain and you then have the option of Unloading that whole app domain. That way you can cope with other peoples application plugins misbehaving and throwing exceptions. you also gain the option of specifying partial trust to further restrict what a plugin can do.
However this will not help if you cannot enforce the use of managed code plugins, and the earlier option of a set of seperate processes would be more apropriate.
Reading your post agin it seems you have some quality issues with the plugins you have to use. If you must cope with such buggy plugins I would take the previous advice and go with seperate processes.
How do I catch a StackOverflowException?
I have a program that allows the user to write scripts, and when running arbitrary user-code I may get a StackOverflowException. The piece running user code is obviously surrounded with a try-catch, but stack overflows are uncatchable under normal circumstances.
I've looked around and this is the most informative answer I could find, but still led me to a dead end; from an article in the BCL team's blog I found that I should use RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup to call the code and the delegate that would get called even after a stack overflow, but when trying, the process gets terminated with the stack overflow message without the delegate ever getting called. I've tried adding PrePrepareMethodAttribute on the handler method but that didn't change anything.
I've also tried using an AppDomain and handling both the UnhandledException and the DomainUnload event - but the entire process gets killed on stack overflows. The same happens even if I throw new StackOverflowException(); manually and not get an actual stack overflow.
To handle an exception that is not handled by your code, you can subscribe to the AppDomains UnhandledException -- which is what the operating system handles when it displays the dialog that says the program exited unexpectedly.
In the Main method of your program use
var currentDomain = AppDomain.CurrentDomain;
and then add a handler to the event
currentDomain.UnhandledException += handler;
In the handler you can do anything you want, such as log, display an error, or even reinitializing the program if desired.
Program your script engine to trace the level of recursion in the script. If the recursion goes above some arbitrarily large number then kill the script before it kills your program. Alternatively you could program the script engine to operate in a stackless manner and store all of the script's stack data in a System.Collections.Generic.Stack<T>. Even if you do use a separate stack you will still want to limit the level of recursion that a script can have, but stack collection will give you a few hundred times more stack space.
You need to run the code in a separate process.
You must load the user script, or any external 3rd party plugin, in a different app domain, so that you can safely unload the domain should an unrecoverable error occurs.
You must create a different AppDomain since you cannot unload an assembly from a loaded domain, and you don't want to shutdown your main application domain.
You create a new application domain like this:
var scriptDomain = AppDomain.CreateDomain("User Scripts");
You can then load any type from an assembly that you need to create. You have to be sure that the object that you will load inherits from MarshalByRefObject.
I assume that your user script is wrapped inside an object defined like this:
public abstract UserScriptBase : MarshaByRefObject
{
public abstract void Execute();
}
You can therefore load any user script like this:
object script = domain.CreateInstanceFromAndUnwrap(type.Location, type.FullName);
After all that, you can subscribe to the scriptDomain.UnhandledException and monitor any unrecoverable error.
Using a different application domain is not easy and you will most likely encounter some loading/unloading problem (DLL is referenced by both domain).
I recommend that you fellow some tutorial that you could find online.