Share via

Error: "The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request" (Ricky Kirkham)

  • Article

Some developers are getting this error whenever they try to use a sandboxed solution, or sometimes when they add a sandboxed Web Part to a page, even in circumstances in which the service could not be busy.  There seem to be multiple things that can cause this. The following are some solutions that have worked for others.  If you find a different solution, please report it as a comment to this post. Be sure to double-verify it: undo your solution and verify that the problem comes back, then redo it and verify that the problem goes away.

I. Be sure the sandboxed host service is running on the appropriate servers. The service is called Microsoft SharePoint Foundation Sandboxed Code Service in Central Admnistration. It is called SharePoint 2010 User Code Host in Windows Services. It can be started in either place. 

If you have configured the sandbox to run in local mode, then the service must be running on every front-end web server. If you have configured it to run in remote mode (sometimes called affinity mode), then it must be running on at least one server in the farm. To determine which mode is being used open Central Administration and navigate to System Settings | Manage User Solutions. Scroll down to the Load Balancing section where the mode is set.

II.  A second known cause is certain values in the local computer policy of the servers running the sandboxed host service. The following values should not be enabled.

Computer Configuration -> Administrative Templates -> System -> Remote Procedure Call -> RPC Endpoint Mapper Client Authentication

Computer Configuration -> Administrative Templates -> System -> Remote Procedure Call -> Restrictions for Unauthenticated RPC clients

III.  A third known cause is the presence of the following key in the registry of the servers that are running the sandboxed host service. (An additional symptom of this cause is that the service stops a few seconds after starting.)

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindows NTRPC

It does not matter what the value of the key is, or even if the key has any value. If the key is present, the user account in which the sandboxed host process runs must be able to read it because the process tries to when it starts up. By default, the user account does not have permission to read it (because, by default, the key is not present). You must give the Users group of the computer permission to read the key.

Note: It is not sufficient to give such permission to the Authenticated Users group, because the sandboxed process removes the Authenticated User token from the the user account in which the sandboxed host process runs. This also makes that account a restricted account which means it is not sufficient to give permission to read the key to that account alone. Since the account is not considered authenticated, doing this would have no effect. However, the account does inherit the permissions of the computer’s User group.

Take the following steps on every server which has the key and which is running the sandboxed host service.

  1. Open the registry editor and navigate to the key.
  2. Right-click the key and select Permissions.
  3. On the dialog that opens, click Add.
  4. In the dialog that opens, enter the following in the Enter the object names to select box: computernameUsers.
  5. Click Check Names.
  6. After the name has resolved, click OK.
  7. Restart the sandboxed host service on all servers on which it is to run. It cannot hurt to do an iisreset as well.

IV.  A fourth known cause is that SharePoint is trying to check for certificate revocations at crl.microsoft.com. The following are workarounds:

A. There is a registry key that is used by the sandboxed solution infrastructure and sometimes gets the wrong value. To ensure that it is set to the correct value, take these steps on all servers that are running the sandboxed host service :

  1. On the server, click Start | Administrative Tools | Services.
  2. On the Services dialog, scroll to SharePoint 2010 User Code Host.
  3. Note the full user name in the Log On As column. You will need this information later.
  4. Open SharePoint Management Shell.
  5. Enter the following at the command prompt, including all punctuation.

(Get-SPManagedAccount –Identity “username”).Sid.Value

Replace username with the name you obtained in step 3. E.g., CorpDomainFarmAdmin

This will return the user’s SID (Security ID), which you will use in a later step.

    6.    Open the registry editor and navigate to:

HKEY_USERSSID you obtained earlierSOFTWAREMicrosoftWindowsCurrentVersionWinTrustTrust ProvidersSoftwarePublishing

    7.     Be sure the State key value is set to 0x00023e00 .

    8.    Restart the sandboxed host service on all servers on which it is to run. It cannot hurt to do an iisreset as well.

B.  You can redirect these attempts by adding the following line to the end of the hosts file located at C:WindowsSystem32driversetc:

127.0.0.1 crl.microsoft.com 

This must be done on all servers running the sandboxed host service. Then restart the SharePoint 2010 User Code Host service on all these servers. It cannot hurt to do an iisreset as well.

C.  The following workaround changes configuration files which ship with the product which means you may have to redo these steps if the files are ever overwritten by a service pack or other reinstallation.

  1. Navigate to %SHAREPOINTROOT%UserCode

  2. Open each of the three *.exe.config files and add the following element as a child of the <runtime>element:

    <generatePublisherEvidence enabled=”false”/>

  3. Steps 1- 2 must be done on all servers running the sandboxed host service. Then restart the SharePoint 2010 User Code Host service on all servers. It cannot hurt to do an iisreset as well.

     See <generatePublisherElement> for more information.

Comments

  • Anonymous
    February 08, 2011
    Really didn't know all the possibilities to fix this, thanks for sharing. Restarting the sandboxed host service always solves it for me.

  • Anonymous
    March 22, 2011
    Thanks.. B - Registry change worked for me.

  • Anonymous
    April 18, 2011
    it worked for me the first time have tried it. Then I installed a Exchange 2010 on the same machine. After this it has stopped working again and non of the provided solutions work. Any suggestions? Many thanks in advance.

  • Anonymous
    June 06, 2011
    Tried them all...none working for me :(

  • Anonymous
    July 20, 2011
    You rock! I have been struggling with this since last couple of days. The one with 0x00023e00 change worked for me. The value was 0x00023c00 originally. Thanks a lot for article. Also, for people who might still be struggling I suggest that you have a Non Farm administrator account configured for SPUserCodeV4(Windows Service) and then try the changes suggested above one by one.

  • Anonymous
    July 20, 2011
    Super! Worked! Helped me change from 0x00023e00 to 0x00023e00.

  • Anonymous
    September 26, 2011
    Thanks for the article.  Option III apprears to work in my enviornment however when group policy refreshes the permissions get reset back to default removing the users group.  Is there a way to prevent this from occuring?

  • Anonymous
    September 26, 2011
    @Jeremy: Group policy is not a SharePoint thing, so there's nothing you can do in SharePoint to block the refresh. This is something you need to bring up with your network administrators. They can adjust the policies.

  • Anonymous
    September 29, 2011
    @Rickee Thanks. I was able to get my AD folks to apply the permissions for option III via group policy and am now working.

  • Anonymous
    October 24, 2011
    Thanks...Registry change from 0x00023c00 to 0x00023e00 worked for me as well.

  • Anonymous
    November 10, 2011
    If need a PowerShell script to perform step IV.A (WinTrust registry), you can check Approach #2 as described in this post: www.pdfsharepoint.com/error-sandboxed-too-busy-handle-request Also, there is a technical explanation of WinTrust and value '0x00023e00'

  • Anonymous
    April 16, 2012
    Thanks.. Registry change helped me resolve the issue.

  • Anonymous
    May 13, 2012
    The comment has been removed

  • Anonymous
    May 16, 2012
    The comment has been removed

  • Anonymous
    September 13, 2012
    Another vote for the registry key change. :) Thanks!

  • Anonymous
    October 26, 2012
    This did the trick for me.. read it on another blog. $uc = [Microsoft.SharePoint.Administration.SPUserCodeService]::Local $uc.WorkerProcessExecutionTimeout = 5000 $uc.Update() $tier = $uc.Tiers[""]   # default Tier has no Name $tier.MaximumWorkerProcesses = 2    # number of CPU Cores + 1 $tier.Update()

  • Anonymous
    November 20, 2012
    The comment has been removed

  • Anonymous
    November 21, 2012
    @Mikael Carlevigg If raising the WorkerProcessExecutionTimeout value solves the problem, then the sandboxed service really was too busy. This post is concerned with puzzling cases where the error message is not literally true.

  • Anonymous
    December 18, 2012
    edit reg to 0x00023e00 and did all above steps but no luck for me please help me.

  • Anonymous
    January 08, 2013
    IV solved it for us. Thank you

  • Anonymous
    April 08, 2013
    It solved the problem for us on one environment wherein we have just two web front servers and sandbox is enabled on both but not on the other one wherein we have plenty of web front end servers and sandbox is enabled only on app servers.

  • Anonymous
    August 29, 2013
    The comment has been removed