L’exécution du CLR SQL Server échoue avec TypeInitializationException

Cet article vous aide à contourner le problème où l’exécution des objets CLR SQL Server échoue et retourne une exception System.TypeInitializationException .

S'applique à : SQL Server
Numéro de la base de connaissances d’origine : 4576575

Symptômes

Important

Cet article contient des informations expliquant comment abaisser les paramètres de sécurité ou comment désactiver les fonctions de sécurité sur un ordinateur. Vous pouvez être amené à procéder à ces modifications pour contourner un problème spécifique. Avant de procéder à ces modifications, nous vous recommandons d’évaluer les risques associés à l’implémentation de cette solution de contournement dans votre environnement propre. Si vous implémentez cette solution de contournement, veillez à prendre toutes les mesures appropriées pour protéger l'ordinateur.

Après avoir installé une mise à jour .NET Framework applicable pour corriger une vulnérabilité décrite dans CVE-2020-1147, l’exécution de la génération d’objets de base de données avec l’intégration CLR (Common Language Runtime) qui lit du code XML dans les objets d’aide de sécurité DataSet et DataTable échoue. Cela se produit en raison d’une exception System.TypeInitializationException qui a une exception FileNotFoundException imbriquée. Ce problème indique que l’assembly System.Drawing n’a pas pu être chargé.

Pour référence, consultez l’exemple suivant :

Msg 6522, Level 16, State 1, Procedure [your CLR object], Line 0 [Batch Start Line 0] Une erreur .NET Framework s’est produite pendant l’exécution de la routine définie par l’utilisateur ou agrège « votre objet CLR » :
System.TypeInitializationException : une exception a été levée par l’initialiseur de type pour « Étendue ». >--- System.IO.FileNotFoundException : Impossible de charger le fichier ou l’assembly « System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=<Token> » ou l’une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.
System.TypeInitializationException :
sur System.Data.TypeLimiter.Scope.IsTypeUnconditionallyAllowed(Type)
sur System.Data.TypeLimiter.Scope.IsAllowedType(Type)
sur System.Data.TypeLimiter.EnsureTypeIsAllowed(Type type, TypeLimiter capturedLimiter) sur System.Data.DataColumn.UpdateColumnType(Type type, StorageType typeCode)
sur System.Data.DataColumn.. ctor(String columnName, Type dataType, String expr, Type MappingType)
à System.Data.XSDSchema.HandleElementColumn(XmlSchemaElement elem, table DataTable, 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)
sur System.Data.XSDSchema.HandleTable(Nœud 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)
sur System.Data.XSDSchema.HandleTable(Nœud XmlSchemaElement)
sur System.Data.XSDSchema.LoadSchema(XmlSchemaSet schemaSet, DataSet ds)
sur System.Data.DataSet.InferSchema(XmlDocument xdoc, String[] excludedNamespaces, mode XmlReadMode)
sur System.Data.Data...

Résolution

Ce problème a été résolu dans la republiation du 13 octobre 2020 des mises à jour de sécurité uniquement du .NET Framework en juillet 2020.

Pour plus d’informations, notamment sur la façon d’obtenir le correctif, consultez la republiation de .NET Framework des mises à jour de sécurité uniquement de juillet 2020.

Solution de contournement

Avertissement

Cette solution de contournement peut rendre votre ordinateur ou réseau plus vulnérable aux attaques par des utilisateurs ou des logiciels malveillants comme des virus. Nous vous déconseillons cette solution de contournement, mais vous fournissez ces informations pour pouvoir implémenter cette solution à votre discrétion. Son utilisation relève de votre responsabilité.

Pour les applications qui désérialisent des données XML non approuvées dans une instance d’un ou DataSet DataTable des objets, nous vous recommandons d’utiliser une autre méthode pour accéder aux données. Pour les applications qui lisent uniquement les données XML approuvées, vous pouvez essayer l’une des solutions de contournement suivantes.

Note

Les solutions de contournement 1 et 2 sont préférées, car les modifications sont apportées localement. La solution de contournement 3 est à l’échelle du système.

Avertissement

Ces solutions de contournement suppriment les restrictions de type pour désérialiser du code XML dans des instances d’objets et DataTable des DataSet instances. Cela peut ouvrir un trou de sécurité si l’application lit une entrée non approuvée.

Solution de contournement 1 : Appeler AppContext.SetSwitch

Modifiez le début du code objet SQL CLR pour définir le commutateur Switch.System.Data.AllowArbitraryDataSetTypeInstantiation sur true. Pour chaque objet SQL CLR applicable, vous devez le faire. Consultez l’exemple qui suit.

Pour plus d’informations, consultez les conseils de sécurité DataSet et DataTable.

Solution de contournement 2 : Créer ou modifier le fichier Sqlservr.exe.config pour chaque instance applicable

Cette solution de contournement s’applique uniquement à l’instance elle-même.

Important

Nous ne pouvons pas garantir que cette modification ne sera pas remplacée par les mises à jour sql Server ou les mises à niveau d’instance. Nous vous recommandons de déterminer si la modification persiste après une mise à jour ou une mise à niveau d’instance.

1. Recherchez le fichier Sqlservr.exe.config dans les emplacements de fichier pour les instances par défaut et nommées de SQL Server :

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

2. Dans le <runtime> nœud, mais en dehors des nœuds imbriqués, ajoutez la ligne suivante :

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

3. Enregistrez le fichier et redémarrez l’instance.

   Consultez l’exemple suivant d’une instance SQL Server 2016.

   

Solution de contournement 3 : Créer l’assembly System.Drawing

Créez manuellement l’assembly System.Drawing dans SQL Server à partir du fichier DLL dans le Global Assembly Cache (GAC), puis recréez des assemblys qui utilisent ou DataTable.ReadXMLDataSet.ReadXML . Par exemple :

 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

Solution de contournement 4 : Créer une sous-clé de Registre

Important

Suivez attentivement les étapes de cette solution de contournement. De graves problèmes peuvent se produire si vous modifiez le Registre de façon incorrecte. Avant de le modifier, sauvegardez le Registre afin de pouvoir le restaurer en cas de problème.

Cette solution de contournement affecte toutes les applications .NET sur le serveur. Par conséquent, vous devez utiliser cette méthode uniquement comme dernier recours si vous ne pouvez pas utiliser les autres solutions de contournement.

1. Ouvrez l'Éditeur du Registre.

2. Recherchez la sous-clé suivante :

   KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext

3. Créez une REG_SZ valeur, comme suit.

   Nom	Switch.System.Data.AllowArbitraryDataSetTypeInstantiation
   Valeur	true

4. Redémarrez toutes les instances SQL Server.

   Consultez l’exemple qui suit.

   

Plus d’informations

Ce problème est dû à l’action d’une mise à jour de sécurité .NET Framework récente pour corriger la validation du balisage de contenu XML .NET Framework. Les objets CLR SQL Server qui ne lisent pas du code XML dans des instances d’un ou DataSet DataTable d’autres objets ne seront pas affectés.