Поделиться через


Выполнение СРЕДЫ CLR SQL Server завершается сбоем с TypeInitializationException

В этой статье описана проблема, из-за которой выполнение объектов СРЕДЫ CLR SQL Server завершается сбоем и возвращает исключение System.TypeInitializationException .

Применяется к: SQL Server
Исходный номер базы знаний: 4576575

Симптомы

Внимание

В этой статье содержатся сведения о том, как снизить параметры безопасности или отключить функции безопасности на компьютере. Эти изменения можно внести для решения конкретной проблемы. Перед внесением этих изменений рекомендуется оценить риски, связанные с реализацией этого обходного решения в конкретной среде. При реализации этого обходного решения выполните все необходимые дополнительные действия, чтобы защитить компьютер.

После установки применимого платформа .NET Framework обновления для устранения уязвимости, описанной в CVE-2020-1147, выполняется интеграция создания объектов базы данных с средой CLR, которая считывает XML-код в объекты рекомендаций по безопасности DataSet и DataTable. Это происходит из-за исключения System.TypeInitializationException с вложенным исключением FileNotFoundException. Эта проблема означает, что сборка System.Drawing не может быть загружена.

Дополнительные сведения см. в следующем примере:

Msg 6522, Level 16, State 1, Procedure [ваш объект CLR], Строка 0 [Начальная строка пакетной службы 0] Ошибка платформа .NET Framework произошла во время выполнения определяемой пользователем подпрограммы или агрегата "объект CLR":
System.TypeInitializationException: инициализатор типов для "Scope" вызвал исключение. >--- System.IO.FileNotFoundException: не удалось загрузить файл или сборку System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=<Token> или одну из зависимостей. Системе не удается найти указанный файл.
System.TypeInitializationException:
at System.Data.TypeLimiter.Scope.IsTypeUnconditionallyAllowed(Type)
в System.Data.TypeLimiter.Scope.IsAllowedType(type)
at System.Data.TypeLimiter.EnsureTypeIsAllowed(Type, TypeLimiter capturedLimiter) в System.Data.DataColumn.UpdateColumnType(type, StorageType type)
в 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)
в System.Data.XSDSchema.InstantiateTable(узел XmlSchemaElement, ТипNode XmlSchemaComplexType, boolean isRef)
на узле System.Data.XSDSchema.HandleTable(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)
в System.Data.XSDSchema.InstantiateTable(узел XmlSchemaElement, ТипNode XmlSchemaComplexType, boolean isRef)
на узле System.Data.XSDSchema.HandleTable(XmlSchemaElement)
в System.Data.XSDSchema.LoadSchema(XmlSchemaSet schemaSet, DataSet ds)
at System.DataSet.InferSchema(xmlDocument xdoc, String[] excludedNamespaces, XmlReadMode mode)
в System.Data.Data...

Решение

Эта проблема устранена в повторной публикации обновлений платформа .NET Framework июля 2020 г. только для системы безопасности 13 октября 2020 г.

Дополнительные сведения о том, как получить исправление, см. в платформа .NET Framework повторной публикации обновлений только для системы безопасности за июль 2020 г.

Обходное решение

Предупреждение

Это обходное решение повышает уязвимость компьютера или сети к атакам пользователей-злоумышленников или вредоносных программ, например вирусов. Мы не рекомендуем использовать это решение, но предоставляют эти сведения, чтобы реализовать это решение по своему усмотрению. Ответственность за использование этого обходного пути несет пользователь.

Для приложений, которые десериализируют ненадежные XML-данные в экземпляре или DataSet DataTable объектах, рекомендуется использовать альтернативный метод для доступа к данным. Для приложений, которые считывают только доверенные XML-данные, можно попробовать одно из следующих обходных решений.

Примечание.

Решение 1 и 2 предпочтительнее, так как изменения вносятся локально. Обходное решение 3 — это системное решение.

Предупреждение

Эти обходные пути удаляют ограничения типов для десериализации XML в экземпляры DataSet и DataTable объекты. Это может открыть отверстие безопасности, если приложение считывает ненадежные входные данные.

Обходное решение 1. Вызов AppContext.SetSwitch

Измените начало кода объекта СРЕДЫ CLR SQL, чтобы задать для параметра Switch.System.Data.AllowArbitraryDataSetTypeInstantiation значение true. Это необходимо сделать для каждого применимого объекта СРЕДЫ CLR SQL. См. следующий пример.

Снимок экрана: пример изменения кода объекта SQL CLR.

Дополнительные сведения см. в статье Руководство по безопасности для DataSet и DataTable.

Решение 2. Создание или изменение файла конфигурации Sqlservr.exe.config для каждого применимого экземпляра

Это обходное решение применяется только к самому экземпляру.

Внимание

Мы не можем гарантировать, что это изменение не будет перезаписано обновлениями SQL Server или обновлениями экземпляров. Мы рекомендуем определить, сохраняется ли изменение после обновления или обновления экземпляра.

  1. Найдите файл Sqlservr.exe.config в расположениях файлов для именованных экземпляров SQL Server по умолчанию и именованных экземпляров:

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

  2. <runtime> В узле, но за пределами вложенных узлов добавьте следующую строку:

    <AppContextSwitchOverrides value="Switch.System.Data. AllowArbitraryDataSetTypeInstantiation=true"/>
    
  3. Сохраните файл и перезапустите экземпляр.

    См. следующий пример экземпляра SQL Server 2016.

    Снимок экрана: пример экземпляра SQL Server 2016.

Решение 3. Создание сборки System.Drawing

Вручную создайте сборку System.Drawing в SQL Server из DLL-файла в глобальном кэше сборок (GAC), а затем повторно создайте сборки, использующие либоDataSet.ReadXML.DataTable.ReadXML Например:

 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

Решение 4. Создание подраздела реестра

Внимание

Следуйте инструкциям, описанным в этом обходном пути, тщательно. Неправильное изменение реестра может привести к серьезным проблемам. Прежде чем приступить к изменениям, создайте резервную копию реестра для восстановления на случай возникновения проблем.

Это решение повлияет на все приложения .NET на сервере. Поэтому этот метод следует использовать только в качестве последнего способа, если вы не можете использовать другие обходные пути.

  1. Откройте редактор реестра.

  2. Найдите следующий подраздел.

    KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext

  3. REG_SZ Создайте значение, как показано ниже.

    Имя. Switch.System.Data.AllowArbitraryDataSetTypeInstantiation
    Значение true
  4. Перезапустите все экземпляры SQL Server.

    См. следующий пример.

    Снимок экрана: раздел реестра AppContext в редакторе реестра.

Дополнительная информация

Эта проблема вызвана действием недавнего обновления системы безопасности платформа .NET Framework для исправления проверки разметки содержимого XML платформа .NET Framework. Объекты СРЕДЫ CLR SQL Server, которые не считывают XML в экземпляры DataSet объектов или DataTable объектов, не будут затронуты.