by
Adrian Lorentz , Principal IT officer (analyst-programmer) , A.N.P.
First of all, when it comes to sandbox in the world of computers it must be understood that is a safe zone inside a hosting environment where code can be executed without damaging that hosting environment. This is implemented by imposing certain restrictions such as interdiction to modify the file system on host during execution.
The sandbox is implemented in SharePoint as a separate process from w3wp.exe (IIS Worker Process) where a sandbox solution code will run and the code can only affect the site collection of the solution.
In fact, there are three processes not only one. First is SPUCHostService.exe, aka the Sandboxed Code Service, runs on each server on the farm that is allowed to work in the sandbox. Activation on every front end in the farm will conduct to low administrative overhead, also to a low scalability because of load balancing aspects, for example. Running the service and sandbox solutions only on certain web front ends would be a significantly better choice.
The second process is SPUCWorkerProcess.exe, which is the process where the code runs and inside of which could be executed only a subset of the Microsoft.SharePoint namespace (out of the box Code Access Security policy).
The last process is the sandbox worker process proxy, SPUCWorkerProcessProxy.exe, which make calls to resources and objects that the sandboxed solution can't reach (external databases, Web services so on) and deliver to it.
