Die Ausführung von SQL Server CLR schlägt mit TypeInitializationException fehl.

Dieser Artikel hilft Ihnen, das Problem zu umgehen, bei dem die Ausführung von SQL Server CLR-Objekten fehlschlägt und eine System.TypeInitializationException-Ausnahme zurückgibt.

Gilt für: SQL Server
Ursprüngliche KB-Nummer: 4576575

Problembeschreibung

Wichtig

Dieser Artikel enthält Informationen dazu, wie Sie Sicherheitseinstellungen herabsetzen oder Sicherheitsfunktionen auf einem Computer deaktivieren. Sie können diese Änderungen vornehmen, um ein bestimmtes Problem zu umgehen. Wir raten Ihnen jedoch, zunächst die Risiken dieser Problemumgehung für Ihre Umgebung abzuschätzen, bevor Sie die genannten Änderungen vornehmen. Falls Sie diese Problemumgehung einsetzen, sollten Sie entsprechende Maßnahmen treffen, um Ihren Computer zu schützen.

Nachdem Sie ein anwendbares .NET Framework-Update installiert haben, um eine Sicherheitsanfälligkeit zu beheben, die in CVE-2020-1147 beschrieben wird, führen Sie die Integration von Datenbankobjekten mit Common Language Runtime (CLR) aus, die XML in DataSet- und DataTable-Sicherheitsleitlinienobjekte lesen. Dies geschieht aufgrund einer System.TypeInitializationException-Ausnahme mit einer geschachtelten FileNotFoundException-Ausnahme . Dieses Problem weist darauf hin, dass die System.Drawing-Assembly nicht geladen werden konnte.

Referenz finden Sie im folgenden Beispiel:

Msg 6522, Level 16, State 1, Procedure [Your CLR object], Line 0 [Batch Start Line 0] Ein .NET Framework-Fehler ist während der Ausführung einer benutzerdefinierten Routine oder des Aggregats "Ihr CLR-Objekt" aufgetreten:
System.TypeInitializationException: Der Typinitialisierer für „Bereich“ hat eine Ausnahme ausgelöst. >--- System.IO.FileNotFoundException: Datei oder Assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=<Token>' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die angegebene Datei wurde nicht gefunden.
System.TypeInitializationException:
at System.Data.TypeLimiter.Scope.IsTypeUnconditionallyAllowed(Type type)
at System.Data.TypeLimiter.Scope.IsAllowedType(Type type)
at System.Data.TypeLimiter.EnsureTypeIsAllowed(Type type, TypeLimiter capturedLimiter) at System.Data.DataColumn.UpdateColumnType(Type type, StorageType typeCode)
at 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(XmlSchemaElement node)
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(XmlSchemaElement node)
at System.Data.XSDSchema.LoadSchema(XmlSchemaSet schemaSet, DataSet ds)
at System.Data.DataSet.InferSchema(XmlDocument xdoc, String[] excludedNamespaces, XmlReadMode mode)
bei System.Data.Data...

Lösung

Dieses Problem wurde im 13. Oktober 2020 zur erneuten Veröffentlichung von .NET Framework Juli 2020 Sicherheitsupdates behoben.

Weitere Informationen, einschließlich des Abrufens des Patches, finden Sie unter .NET Framework: erneute Veröffentlichung von Sicherheitsupdates vom Juli 2020.

Problemumgehung

Warnung

Durch diese Problemumgehung wird ein Computer oder ein Netzwerk möglicherweise anfälliger für Angriffe durch böswillige Benutzer oder Malware wie etwa Viren. Wir empfehlen diese Problemumgehung nicht, stellen aber diese Informationen bereit, damit Sie diese Problemumgehung nach eigenem Ermessen implementieren können. Die Verwendung dieser Problemumgehung erfolgt auf eigene Verantwortung.

Für Anwendungen, die nicht vertrauenswürdige XML-Daten in eine Instanz von DataSet oder DataTable Objekten deserialisieren, empfehlen wir, eine alternative Methode für den Zugriff auf die Daten zu verwenden. Für Anwendungen, die nur vertrauenswürdige XML-Daten lesen, können Sie eine der folgenden Problemumgehungen ausprobieren.

Notiz

Problemumgehungen 1 und 2 werden bevorzugt, da die Änderungen lokal vorgenommen werden. Problemumgehung 3 ist systemweit.

Warnung

Diese Problemumgehungen entfernen Typeinschränkungen zum Deserialisieren von XML in Instanzen und DataSet DataTable Objekten. Dies kann ein Sicherheitsloch öffnen, wenn die Anwendung nicht vertrauenswürdige Eingaben liest.

Problemumgehung 1: Aufrufen von AppContext.SetSwitch

Ändern Sie den Start des SQL CLR-Objektcodes, um den Switch.System.Data.AllowArbitraryDataSetTypeInstantiation-Schalter auf "true" festzulegen. Sie müssen dies für jedes anwendbare SQL CLR-Objekt tun. Siehe folgendes Beispiel.

Weitere Informationen finden Sie im Sicherheitsleitfaden für DataSet und DataTable.

Problemumgehung 2: Erstellen oder Ändern der Datei Sqlservr.exe.config für jede anwendbare Instanz

Diese Problemumgehung gilt nur für die Instanz selbst.

Wichtig

Wir können nicht garantieren, dass diese Änderung nicht von SQL Server-Updates oder Instanzupgrades überschrieben wird. Es wird empfohlen, festzustellen, ob die Änderung nach einer Instanzaktualisierung oder einem Upgrade beibehalten wird.

1. Suchen Sie die Datei Sqlservr.exe.config in den Dateispeicherorten für Standard- und benannte Instanzen von SQL Server:

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

2. Fügen Sie innerhalb des <runtime> Knotens, aber außerhalb geschachtelter Knoten die folgende Zeile hinzu:

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

3. Speichern Sie die Datei, und starten Sie die Instanz neu.

   Sehen Sie sich das folgende Beispiel einer SQL Server 2016-Instanz an.

   

Problemumgehung 3: Erstellen der System.Drawing-Assembly

Erstellen Sie die System.Drawing-Assembly in SQL Server manuell aus der DLL-Datei im globalen Assemblycache (GAC), und erstellen Sie dann Assemblys, die eine DataSet.ReadXML oder DataTable.ReadXMLmehrere Assemblys verwenden. Zum Beispiel:

 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

Problemumgehung 4: Erstellen eines Registrierungsunterschlüssels

Wichtig

Führen Sie die Schritte in dieser Problemumgehung sorgfältig aus. Wird die Registrierung falsch angepasst, können schwerwiegende Probleme auftreten. Bevor Sie sie ändern, sichern Sie die Registrierung zwecks Wiederherstellung für den Fall, dass Probleme auftreten.

Diese Problemumgehung wirkt sich auf alle .NET-Anwendungen auf dem Server aus. Daher sollten Sie diese Methode nur als letztes Mittel verwenden, wenn Sie die anderen Problemumgehungen nicht verwenden können.

1. Öffnen Sie den Registrierungs-Editor.

2. Suchen Sie den folgenden Unterschlüssel:

   KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext

3. Erstellen Sie wie folgt einen REG_SZ Wert.

   Name	Switch.System.Data.AllowArbitraryDataSetTypeInstantiation
   Wert	true

4. Starten Sie alle SQL Server-Instanzen neu.

   Siehe folgendes Beispiel.

   

Weitere Informationen

Dieses Problem wird durch die Aktion eines aktuellen .NET Framework-Sicherheitsupdates verursacht, um die XML-Inhaltsmarkupüberprüfung von .NET Framework zu korrigieren. SQL Server CLR-Objekte, die XML nicht in Instanzen von DataSet oder DataTable Objekten lesen, sind nicht betroffen.