Error en la ejecución de CLR de SQL Server con TypeInitializationException

Este artículo le ayuda a solucionar el problema en el que se produce un error en la ejecución de objetos CLR de SQL Server y devuelve una excepción System.TypeInitializationException .

Se aplica a: SQL Server
Número de KB original: 4576575

Síntomas

Importante

En este artículo se incluye información que le muestra cómo reducir la configuración de seguridad o cómo desactivar las características de seguridad en un equipo. Puede hacer estos cambios para solucionar de manera alternativa un problema concreto. Pero antes de realizarlos, recomendamos que evalúe los riesgos asociados a esta solución alternativa en su entorno concreto. Si decide implementar esta solución alternativa, tome las medidas adicionales oportunas para ayudar a proteger el equipo.

Después de instalar una actualización de .NET Framework aplicable para corregir una vulnerabilidad que se describe en CVE-2020-1147, se produce un error al ejecutar la compilación de objetos de base de datos con Common Language Runtime (CLR) Integration que leen XML en objetos de guía de seguridad DataSet y DataTable. Esto ocurre debido a una excepción System.TypeInitializationException que tiene una excepción FileNotFoundException anidada. Este problema indica que no se pudo cargar el ensamblado System.Drawing .

Para obtener referencia, consulte el ejemplo siguiente:

Msg 6522, Level 16, State 1, Procedure [your CLR object], Line 0 [Batch Start Line 0] Se produjo un error de .NET Framework durante la ejecución de la rutina definida por el usuario o el agregado "su objeto CLR":
System.TypeInitializationException: se produjo una excepción en el inicializador de tipo de 'Scope'. >--- System.IO.FileNotFoundException: no se pudo cargar el archivo o ensamblado 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=<Token>' o una de sus dependencias. El sistema no puede encontrar el archivo especificado.
System.TypeInitializationException:
at System.Data.TypeLimiter.Scope.IsTypeUnconditionallyAllowed(Type)
at System.Data.TypeLimiter.Scope.IsAllowedType(Type)
at System.Data.TypeLimiter.EnsureTypeIsAllowed(Type, TypeLimiter capturedLimiter) at System.Data.DataColumn.UpdateColumnType(Type, StorageType typeCode)
en System.Data.DataColumn.. ctor(String columnName, Type dataType, String expr, MappingType type)
at System.Data.XSDSchema.HandleElementColumn(XmlSchemaElement elem, DataTable table, Boolean isBase)
at System.Data.XSDSchema.HandleParticle(XmlSchemaParticle pt, DataTable table, ArrayList tableChildren, Boolean isBase)
at System.Data.XSDSchema.HandleComplexType(XmlSchemaComplexType ct, DataTable table, ArrayList tableChildren, Boolean isNillable)
at System.Data.XSDSchema.InstantiateTable(XmlSchemaElement node, XmlSchemaComplexType typeNode, Boolean isRef)
at System.Data.XSDSchema.HandleTable(Nodo XmlSchemaElement)
at System.Data.XSDSchema.HandleParticle(XmlSchemaParticle pt, DataTable table, ArrayList tableChildren, Boolean isBase)
at System.Data.XSDSchema.HandleComplexType(XmlSchemaComplexType ct, DataTable table, ArrayList tableChildren, Boolean isNillable)
at System.Data.XSDSchema.InstantiateTable(XmlSchemaElement node, XmlSchemaComplexType typeNode, Boolean isRef)
at System.Data.XSDSchema.HandleTable(Nodo XmlSchemaElement)
at System.Data.XSDSchema.LoadSchema(XmlSchemaSet schemaSet, DataSet ds)
en System.Data.DataSet.InferSchema(XmlDocument xdoc, String[] excludedNamespaces, modo XmlReadMode)
en System.Data.Data...

Solución

Este problema se ha corregido en la nueva publicación del 13 de octubre de 2020 de las actualizaciones de solo seguridad de .NET Framework de julio de 2020.

Para obtener más información, incluido cómo obtener la revisión, consulte La publicación de .NET Framework de actualizaciones solo de seguridad de julio de 2020.

Solución alternativa

Advertencia

Esta solución alternativa puede hacer que un equipo o una red sean más vulnerables a los ataques de usuarios o de software malintencionados, como los virus. No se recomienda esta solución alternativa, pero se proporciona esta información para que pueda implementar esta solución alternativa a su discreción. Use esta solución alternativa bajo su propia responsabilidad.

En el caso de las aplicaciones que deserializan datos XML que no son de confianza en una instancia de o DataSetDataTable de objetos, se recomienda usar un método alternativo para acceder a los datos. En el caso de las aplicaciones que solo leen datos XML de confianza, puede probar una de las siguientes soluciones alternativas.

Nota:

Se prefieren las soluciones 1 y 2 porque los cambios se realizan localmente. La solución alternativa 3 es para todo el sistema.

Advertencia

Estas soluciones alternativas quitan restricciones de tipo para deserializar XML en instancias de DataSet objetos y DataTable . Esto puede abrir un agujero de seguridad si la aplicación lee una entrada que no es de confianza.

Solución alternativa 1: Llamada a AppContext.SetSwitch

Cambie el inicio del código de objeto CLR de SQL para establecer el modificador Switch.System.Data.AllowArbitraryDataSetTypeInstantiation en true. Debe hacerlo para cada objeto CLR de SQL aplicable. Consulte el ejemplo siguiente.

Para obtener más información, vea Guía de seguridad de DataSet y DataTable.

Solución alternativa 2: Crear o cambiar el archivo Sqlservr.exe.config para cada instancia aplicable

Esta solución alternativa solo se aplica a la propia instancia.

Importante

No podemos garantizar que este cambio no se sobrescriba mediante actualizaciones de SQL Server ni actualizaciones de instancias. Se recomienda determinar si el cambio persiste después de una actualización o actualización de instancia.

1. Busque el archivo Sqlservr.exe.config en Las ubicaciones de archivo para las instancias predeterminadas y con nombre de SQL Server:

   %ProgramFiles%\Microsoft SQL Server\<Instance_ID>.<Instance Name>\MSSQL\Binn\

2. En el <runtime> nodo, pero fuera de los nodos anidados, agregue la siguiente línea:

   <AppContextSwitchOverrides value="Switch.System.Data. AllowArbitraryDataSetTypeInstantiation=true"/>
   

3. Guarde el archivo y reinicie la instancia.

   Vea el ejemplo siguiente de una instancia de SQL Server 2016.

   

Solución alternativa 3: Crear el ensamblado System.Drawing

Cree manualmente el ensamblado System.Drawing en SQL Server desde el archivo DLL en la caché global de ensamblados (GAC) y, a continuación, vuelva a crear ensamblados que usen DataSet.ReadXML o DataTable.ReadXML. Por ejemplo:

 CREATE ASSEMBLY [Drawing] FROM 'C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Drawing\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Drawing.dll' WITH PERMISSION_SET = UNSAFE GO

Solución alternativa 4: Creación de una subclave del Registro

Importante

Siga los pasos descritos en esta solución alternativa cuidadosamente. Pueden producirse problemas graves si modifica el Registro de manera incorrecta. Antes de modificarlo, haz una copia de seguridad del registro para restaurarlo, por si se produjeran problemas.

Esta solución alternativa afectará a todas las aplicaciones .NET del servidor. Por lo tanto, debe usar este método solo como último recurso si no puede usar las otras soluciones alternativas.

1. Abre el Editor del Registro.

2. Busque la siguiente subclave:

   KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext

3. Cree un REG_SZ valor, como se indica a continuación.

   Nombre	Switch.System.Data.AllowArbitraryDataSetTypeInstantiation
   Valor	true

4. Reinicie todas las instancias de SQL Server.

   Consulte el ejemplo siguiente.

   

Más información

Este problema se debe a la acción de una actualización de seguridad de .NET Framework reciente para corregir la validación de marcado de contenido XML de .NET Framework. Los objetos CLR de SQL Server que no leen XML en instancias de o DataSetDataTable objetos no se verán afectados.