Почему 1С не загружает внешнюю компоненту (DLL) из макета без отладочной информации?

В этой статье разберем достаточно специфичную, но важную проблему, с которой сталкиваются разработчики внешних компонент для 1С. Начиная с версий платформы 8.3.20 и выше, может возникнуть ситуация, когда внешняя компонента, загружаемая из макета на стороне клиента, перестает работать. При этом компонента, собранная с отладочной информацией, загружается успешно, а та же самая компонента в release-сборке (без отладочной информации) — нет. Диагностика показывает, что процесс 1С считывает последние 32 КБ файла DLL и после этого прекращает попытку загрузки. Давайте выясним, что происходит и как это исправить.

Основной вопрос, который мы проанализируем: что именно 1С ищет в конце файла DLL и почему наличие отладочной информации влияет на этот процесс?

Анализ проблемы: новые механизмы безопасности платформы 1С

Наблюдаемое поведение — это не ошибка, а следствие усиления механизмов безопасности в платформе «1С:Предприятие» и операционной системе Windows. Платформа стремится защитить пользователей от запуска потенциально вредоносного или неподтвержденного кода. Для этого она проводит ряд проверок перед загрузкой динамической библиотеки (DLL) в свое адресное пространство. Чтение последних 32 КБ файла — ключевой элемент этой проверки.

Рассмотрим, что может находиться в конце исполняемого файла формата PE (Portable Executable), к которому относятся и DLL:

1. Секция отладочной информации (.debug). В этой секции содержатся данные, необходимые отладчику: имена функций, номера строк, информация о переменных. Когда вы собираете DLL с отладочной информацией, эта секция добавляется в файл, увеличивая его размер.
2. Секция ресурсов (.rsrc). Здесь хранятся иконки, строки, диалоги, а также важный элемент — манифест приложения. Манифест может определять требования к уровню привилегий (UAC), совместимость с версиями Windows и другие параметры безопасности.
3. Таблица релокаций (.reloc). Содержит информацию для настройки указателей в коде, если DLL загружается не по предпочтительному адресу в памяти.
4. Цифровая подпись (Authenticode). Это наиболее вероятная причина проблемы. Данные цифровой подписи, включая сертификат и хеш-суммы секций файла, добавляются в самый конец файла, уже после всех его секций.

Когда 1С читает последние 32 КБ, она, скорее всего, ищет именно структуру цифровой подписи. Начиная с определенных версий, платформа может требовать, чтобы внешние компоненты, загружаемые на клиенте, были подписаны доверенным цифровым сертификатом. Это стандартная практика для обеспечения безопасности: подпись гарантирует, что файл не был изменен после того, как его выпустил разработчик, и подтверждает личность самого разработчика.

Почему версия с отладочной информацией работает?

Тот факт, что DLL с отладочной информацией загружается, является "случайным" побочным эффектом. Дело не в том, что 1С требует именно отладочную информацию. Причина в другом:

• Изменение структуры файла: Добавление секции .debug меняет общую структуру, смещения и размер файла. Возможно, из-за этого измененная структура файла случайно проходит внутреннюю эвристическую проверку платформы. Алгоритм проверки может быть несовершенен и в некоторых случаях ошибочно принимать неподписанный, но "утяжеленный" отладочной информацией файл за корректный.
• Отключение проверки: В некоторых сценариях наличие определенных секций может служить для платформы сигналом, что это "отладочная" сборка, для которой проверки безопасности можно ослабить.

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

Правильное решение: цифровая подпись внешней компоненты

Единственным надежным и правильным решением проблемы является подписание вашей DLL-компоненты валидным цифровым сертификатом для подписи кода (Code Signing Certificate).

Разберем процесс по шагам:

Шаг 1. Получение сертификата

У вас есть два основных пути:

1. Приобретение сертификата у доверенного центра сертификации (CA). Это коммерческие организации, такие как Sectigo, DigiCert, GlobalSign и др. Сертификат, выданный таким центром, будет автоматически считаться доверенным на большинстве компьютеров с Windows. Это предпочтительный вариант для коммерческого распространения компоненты.
2. Создание самоподписанного сертификата (self-signed). Этот вариант подходит для внутреннего использования или для этапа разработки и тестирования. Такой сертификат не будет доверенным по умолчанию. Чтобы система ему доверяла, его (и его корневой сертификат) нужно вручную установить в хранилище "Доверенные корневые центры сертификации" и/или "Доверенные издатели" на каждом клиентском компьютере, где будет использоваться компонента.

Создать самоподписанный сертификат можно с помощью PowerShell:

# Создаем самоподписанный корневой сертификат (делается один раз)
$rootCert = New-SelfSignedCertificate -Subject "CN=My Company Root CA, O=My Company, C=RU" -CertStoreLocation "Cert:\CurrentUser\My" -KeyExportPolicy Exportable -KeyUsage CertSign, CRLSign -KeyLength 2048 -Type Custom -NotAfter (Get-Date).AddYears(10)

# Создаем сертификат для подписи кода, подписанный нашим корневым сертификатом
New-SelfSignedCertificate -Subject "CN=My Company Code Signing, O=My Company, C=RU" -CertStoreLocation "Cert:\CurrentUser\My" -KeyExportPolicy Exportable -KeyUsage DigitalSignature -Type CodeSigningCert -Signer $rootCert -NotAfter (Get-Date).AddYears(2)

После выполнения этих команд в вашем личном хранилище сертификатов появятся два новых сертификата.

Шаг 2. Подписание DLL-файла

Для подписи файлов используется утилита signtool.exe, которая входит в состав Windows SDK. Его можно установить вместе с Visual Studio или как отдельный компонент.

Команда для подписи выглядит следующим образом:

signtool.exe sign /f "путь_к_файлу_сертификата.pfx" /p "пароль_от_сертификата" /tr http://timestamp.digicert.com /td sha256 "путь_к_вашей.dll"

Разберем параметры:

• sign — команда на подписание.
• /f "путь_к_файлу_сертификата.pfx" — указывает путь к вашему сертификату в формате PFX. Если вы создали сертификат через PowerShell, его нужно сначала экспортировать из хранилища в файл PFX.
• /p "пароль_от_сертификата" — пароль, который вы задали при экспорте PFX.
• /tr http://timestamp.digicert.com — очень важный параметр! Он указывает адрес сервера временных меток (timestamping). Сервер ставит метку времени в момент подписи. Это позволяет системе считать подпись действительной даже после истечения срока действия самого сертификата, при условии что на момент подписи он был действителен.
• /td sha256 — указывает алгоритм хеширования для временной метки.
• "путь_к_вашей.dll" — путь к файлу, который вы подписываете.

Если сертификат находится в хранилище, можно использовать его оттуда, указав отпечаток (thumbprint):

signtool.exe sign /tr http://timestamp.digicert.com /td sha256 /sha1 "хэш_сертификата" "путь_к_вашей.dll"

Шаг 3. Проверка подписи

После выполнения команды убедитесь, что подпись применена успешно. Для этого откройте свойства файла DLL в Проводнике Windows. Если все прошло хорошо, появится новая вкладка "Цифровые подписи". На этой вкладке вы сможете увидеть информацию о подписи и сертификате.

Заключение

Подведем итог. Проблема с загрузкой release-версии DLL на клиенте 1С, которая решается добавлением отладочной информации, вызвана усилением политик безопасности платформы. 1С проверяет наличие цифровой подписи, данные которой находятся в конце файла. Это современный и правильный подход к обеспечению безопасности.

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