Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)


The error when the issue happens: (Related with legacyCAS issue)
Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)

Recently we have facing many issues with above exception .Effected products are SharePoint 2013 and SharePoint 2016.Mostly the cases are open as CritSit because of SharePoint down.

• We typically see these errors with non-SharePoint code running, such as SCOM’s APM agent or 3rd party monitoring software, or very unlikely .Net patches.
• Specifically in our case, we found the environment running APM monitoring Agent: APMAGT
• The most likely way that this issue came to be is that the CLR core was trying to optimize a reload of the instrumentation agent with an incompatible CAS grant set. This usually happens when the SharePoint site web.config is set to use the legacy CAS model, as introduced in .NET version 4 and provokes the error as described previously. Refer to https://msdn.microsoft.com/en-us/library/vstudio/dd984947(v=vs.100).aspx for a reference of CAS changes in ASP.NET 4.

I have seen many misredirected articles even in technet blogs and incorrect resolutions are suggested for resolving this problem.

One of them changing legacy cas model settings.
Which is out of the box for SharePoint products the Legacy CAS model is a requirement.So we have this value in every SharePoint web sites.
trust level="Full" originUrl="" legacyCasModel="true"
(This is correct!!!)
People are resolving this problem by setting legacyCasModel=”false” which is NOT SUPPORTED .

You shouldn’t change it because of backward compatibility and dependancy reasons we need that. Disabling this property cause anomalies.

Please be aware meaning of NOT SUPPORTED ,does not mean your SharePoint not work. It may work but  we may not give support unless you rollback your changes or can not forseen any other anomalies .

Another incorrect resolution.
Create a new registry DWORD value called LoaderOptimization and give it the value 1 within the key
“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework”
Perform IISRESET and check Web Apps behavior.

In key ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework’, create a new ‘DWORD (32-bit) Value’ named “LoaderOptimization” with a value 1 (either in decimal or hexadecimal as they are the same).
In key ‘HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework‘, create a new ‘DWORD (32-bit) Value’ named “LoaderOptimization” with a value 1 (either in decimal or hexadecimal as they are the same).

This configuration will disable the loader optimization of assemblies that provoke the aforementioned behaviour by setting assembly loading into SingleDomain mode.

And this is also NOT SUPPORTED for SharePoint by Microsoft.
There is two reason for this.
1) These settings are not tested by product group. (It is not design to work in SingleDomain mode)
2) Let’s have look what is LoaderOptimization enumeration
https://msdn.microsoft.com/en-us/library/system.loaderoptimization(v=vs.100).aspx
We have setting “LoaderOptimization” as 1 which means the “SingleDomain” mode.
“Indicates that the application will probably have a single domain, and loader must not share internal resources across application domains.”
SharePoint have many assemblies with many different locations and permission, also have a very complex loading models depend on logic and fallbacks to CAS to GAC or vise versa.
Forcing SharePoint to use singledomain mode prevents the power of shareing loaded images and assembilies with different inter processes operations which effects performance and loading times and
SharePoint uses different permissions sets for appdomain level , multi domain is a requirement to provide all functionalities for SharePoint by security concerns.

And another one , this registry change may also effect your other .net applications (any kind of) because it is .net level change.

So what we should do ?
– First you should find it out which Dll(s) causing this problem. And verify the issue resolved when you uninstall related product.
Like
“Microsoft.EnterpriseManagement.OperationsManager.Apm.Instrumentation, Version=7.0.5000.0”
“Microsoft.EnterpriseManagement.OperationsManager.Apm.InstrumentationUtils, Version=7.0.5000.0”
– This is mostly a Third Party Monitoring tool or even Microsoft SCOM.
These kind of tools or a component belong these tools have inject their assemblies in SharePoint worker process.
And SharePoint is very special,complex blackbox what ever you say that we can not support if you do this.
For SCOM 2012/2016 we know the reason that APM component causing this.
And we have following article that you can not deploy APM for SharePoint servers. It is NOT SUPPORTED .

https://technet.microsoft.com/en-us/library/jj614617.aspx?tduid=(1dfb939b69d4a5ed09b44f51992a8b97)(256380)(2459594)(TnL5HPStwNw-v0X_tBOK3jzpbtaadMW8RA)()
Client-side .NET Application Performance Monitoring (APM) is not supported for SharePoint. Enabling client-side .NET Application Performance Monitoring for SharePoint can result in unpredictable application behavior and failures.

Well , i am not a SCOM expert but following action help you deploy SCOM without APM.

NOTE ! Workaround – Installing the SCOM Agent with the NOAPM=1 switch prevents the copy of the .NET APM related DLL’s as a result w3wp.exe process cannot load the problematic components which are available under C:\Program Files\Microsoft Monitoring Agent\Agent\APMDOTNETAgent\*.

1) Uninstall the SCOM Agent manually on the SharePoint Servers.
2) Delete the “C:\Program Files\Microsoft Monitoring Agent” folder on your SharePoint Servers.
3) Copy the SCOM Agent folder from your SCOM Management Server to the SharePoint Servers. The Agent folder can be found under C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\amd64 on your SCOM Management Servers.
4) Open an elevated cmd window and on your SharePoint Server and install the SCOM Agent manually with the NOAPM=1 switch like in the example below.
Example : msiexec /i momagent.msi NOAPM=1
5) Afterwards please kindly install your Update Rollups. The current installed Update Rollup on your SCOM Management Server is also inside the Agent folder available.
C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\amd64

Recently we face some other issues with SCOM , even you have not deploy APM, it is still injecting some code in SharePoint which breaking our workerprocess.
In this condition please open a ticket for MS SCOM support team.
Related DLLs was;
“C:\Program Files\Microsoft Monitoring Agent\Agent\APMDOTNETAgent\V7.1.10184.0\PerfMon64.dll”

Another APM issue: “System Center 2016 Operations Manager APM Agent causing heap corruption in SharePoint”
https://support.microsoft.com/en-us/help/3216459/system-center-2016-operations-manager-apm-agent-causing-heap-corruptio

I hope this helps for correct actions.

Advertisements

About bpostaci
Escalation Engineer in Microsoft.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: