High number of sandbox worker processes – Dynamics 365

By | June 30, 2017

Issue with Dynamics 365 update 2.1

This is the latest update for Dynamics 365 on-premise released April 2017. We deployed this latest update a couple of weeks ago across all our hosted dynamics environments and like many others we were hit by a critical issue with the sandbox service in this latest update.

If you don’t have any plugins running in the sandbox you might not notice this right away because this only affects the sandbox service. Something that can catch your attention is that your crmQualTech Dynamics CRM custom development services | QualTech360Development users start reporting that crm is running slower than usual. Mainly if you have the front end and back end roles deployed in the same server.

There are two items that will tell you whether you are being affected by this problem or not:

  • if you check the windows event log where your sandbox is running you will see multiple errors logged by MSCMTracing with “Invalid Trace Directory”.
  • from our research it seems that this exception is thrown by the sandbox service and with that it causes a fault in the sandbox service causing it to spawn a new instance of the service.

If you notice these symptoms and a sluggish server open the Task manager in that server and you should see multiple instances of the sandbox service running and the processor usage close to 100%.

This should immediately tell you that you are dealing with this problem and you need to apply the workaround recommended by Microsoft.

In order to stop the error with tracing from being logged you need to make sure the tracing folder for crm is specified and that tracing is enabled. You can use the deployment level tracing using Powershell like below:

Add-PSSnapin Microsoft.Crm.PowerShell
$Setting = Get-CrmSetting TraceSettings
$Setting.Enabled = $True 
$Setting.CallStack=$True 
$Setting.Categories="*:Error" 
$Setting.Directory="C:\Program Files\Microsoft Dynamics CRM\Trace"
Set-CrmSetting $Setting

or you can update the settings in the registry like so:

registry: HKLM\Software\Microsoft\MSCRM\

TraceDirectory String “c:\Path_ToTraceLogs”

TraceEnabled DWORD 1

TraceEnabled must be 1, otherwise you will get errors.

Understand that tracing must remain on otherwise the error will continue to be logged and again according to our research the sandbox will continue to spawn additional instances of the service. The second part of the workaround will force the sandbox service to run only one service at all times. You do that by adding the following setting to the crm registry:

HKLM\Software\Microsoft\MSCRM

SandboxHostMinWorkerProcesses DWORD 1

There’s only one issue I see with this work around. If you use the deployment level script to add and turn on tracing you’ll have all the crm services logging continuously and depending on the amount of activity in your crm deployment this can have a substantial impact in the performance.

If you have the back end role deployed in a separate server my recommendation is for you to just add the TraceDirectory and TraceEnabled settings in that server so logging is running in that server only in order to reduce the impact on the performance.

#QualTech360Care #QualTech360Dynamics #QualTech360Solutions #QualTech360Development

 


											

Leave a Reply