Почему периодически вылетает 1С:Предприятие 8.3.19 на терминальных серверах и как это исправить

← На главную

При обновлении платформы 1С:Предприятие до версии 8.3.19 многие системные администраторы сталкиваются с нестабильной работой программы в терминальной среде. Проблема проявляется в виде внезапных завершений работы процесса 1cv8.exe с ошибками в системных библиотеках. В этой статье мы подробно проанализируем ситуацию, разберем причины возникновения ошибок в модулях ntdll.dll и bsl.dll, а также выработаем пошаговый план стабилизации системы.

Анализ системных ошибок ntdll.dll и bsl.dll

Рассмотрим природу возникающих ошибок. Если в журналах событий Windows вы видите записи, указывающие на модуль ntdll.dll, это чаще всего свидетельствует о низкоуровневом конфликте между приложением и ядром операционной системы. ntdll.dll — это библиотека, через которую 1С взаимодействует с функциями Windows. Ошибка по адресу 0x0000000000035d23 может возникать из-за попытки обращения к защищенному участку памяти или несовместимости вызовов платформы с устаревшей версией ОС (например, Windows Server 2003 или 2012 без обновлений).

Вторая распространенная ошибка связана с модулем bsl.dll. Данная библиотека отвечает за работу встроенного языка 1С (Business Soft Language). Сбои в ней означают, что платформа падает непосредственно в момент выполнения программного кода конфигурации или при попытке его компиляции в кэше. Разберем по шагам, какие действия помогут устранить эти проблемы.

Решение 1: Переход на 32-разрядный клиент (x86)

Как показывает практика эксплуатации версии 8.3.19.1351, 64-разрядный клиент на терминальных серверах ведет себя менее стабильно, особенно при работе с обычными формами (БП 2.0). Проанализируем, почему переход на x86 часто решает проблему:

Меньшее потребление ресурсов: 32-битные процессы имеют жесткое ограничение по памяти, что заставляет платформу более агрессивно очищать неиспользуемые объекты.
Совместимость с драйверами: Многие компоненты (особенно драйверы торгового оборудования и принтеров) в терминальных сессиях лучше работают с x86 процессами.

Для реализации этого решения выполним следующие шаги:

Установим на сервер 32-разрядную версию платформы той же ревизии. В настройках запуска информационной базы (окно списка баз — Изменить — Далее) в поле "Разрядность" выберем принудительный запуск 32 (x86). Это позволит запускать именно 32-битный клиент, даже если на сервере установлены обе версии.

Решение 2: Настройка предотвращения выполнения данных (DEP)

Ошибки в модуле ntdll.dll часто инициируются защитными механизмами Windows. Система DEP (Data Execution Prevention) может ошибочно блокировать участки памяти, которые 1С использует для динамической компиляции модулей. Выясним, как настроить исключения:

Откроем "Свойства системы" — "Дополнительно" — "Быстродействие" — "Параметры".
Перейдем на вкладку "Предотвращение выполнения данных".
Рассмотрим два варианта: либо включить DEP только для основных программ Windows, либо добавить исполняемые файлы 1cv8.exe и 1cv8c.exe в список исключений.
Для старых систем (Windows Server 2003) проверим файл boot.ini на наличие параметра /noexecute. Изменение этого режима на AlwaysOff (только в целях тестирования!) поможет понять, является ли DEP причиной вылетов.

Решение 3: Отключение аппаратного ускорения графики

Версия 8.3.19 активно использует ресурсы видеоадаптера для отрисовки интерфейса. В терминальных сессиях RDP эмулирует графический адаптер, что часто приводит к конфликтам в стеке ntdll.dll. Разберем, как минимизировать графическую нагрузку:

Попробуем запустить 1С с параметром /AppAutoSettingDisable. Также в настройках реестра Windows на терминальном сервере можно принудительно отключить использование аппаратного ускорения для всех RDP-сессий. Это снизит вероятность падения графической подсистемы при отрисовке сложных динамических списков.

Решение 4: Локальная установка платформы и отказ от сетевых ярлыков

В сообщении автора упоминается запуск с сетевого ярлыка. Проанализируем риски такого подхода. При запуске 1С из сетевой папки библиотеки (включая bsl.dll) подгружаются по протоколу SMB. Любая микрозадержка сети или блокировка файла другим пользователем приводит к "вылету" приложения без объяснения причин.

Рекомендация: Установим платформу локально на системный диск каждого терминального сервера (обычно это C:\Program Files\1cv8\...). Это гарантирует монопольный доступ процесса к своим критически важным библиотекам и исключает влияние сетевых лагов.

Решение 5: Настройка Технологического Журнала (ТЖ) для глубокого анализа

Если вышеописанные методы не помогли, нам необходимо выяснить, какой именно программный код вызывает сбой в bsl.dll. Для этого настроим технологический журнал. Создадим в папке C:\Program Files\1cv8\conf (или аналогичной для x86) файл logcfg.xml следующего содержания:


<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
  <log location="C:\1C_Logs" history="24">
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <event>
      <eq property="Name" value="PROC"/>
    </event>
    <property name="All"/>
  </log>
</config>

После этого проанализируем файлы логов в папке C:\1C_Logs непосредственно после очередного вылета. Мы увидим последнее событие перед ошибкой (EXCP), что позволит понять, на каком объекте метаданных или строке кода происходит сбой.

Решение 6: Проверка драйверов принтеров и подсистемы печати

Часто вылет в ntdll.dll происходит в момент инициализации интерфейса, когда 1С опрашивает доступные в системе принтеры. Если в терминальную сессию проброшен некорректный драйвер с локального компьютера пользователя, это вызывает критический сбой. Рассмотрим действия для проверки этой гипотезы:

Попробуем запустить 1С в сессии, где отключен проброс локальных принтеров (настраивается в свойствах RDP-подключения на стороне клиента).
Если вылеты прекратились, заменим драйверы на сервере на универсальные (например, HP Universal Print Driver) или используем штатный Easy Print от Microsoft.

Резюме и дополнительные рекомендации

Проанализировав ситуацию, можно сделать вывод, что релиз 8.3.19.1351 имеет специфические проблемы со стабильностью на старых ОС. Если требования франчайзи жестко ограничивают вас версией 8.3.19, рекомендуем обновиться до последних исправленных релизов в этой ветке (например, 8.3.19.1723 и выше). В них исправлено множество утечек памяти и ошибок взаимодействия с ntdll.dll. Также не забывайте регулярно очищать кэш конфигураций в папках %AppData%\1C\1cv8 и %LocalAppData%\1C\1cv8, так как поврежденный кэш является первопричиной 90% ошибок в модуле bsl.dll.