Как устранить вылет конфигуратора (ошибка backbas.dll) при реструктуризации заимствованного справочника в расширении

← На главную

Процесс обновления крупных типовых конфигураций, таких как 1С:Комплексная автоматизация 2.4 или 1С:ERP, часто сопровождается значительными изменениями в структуре метаданных. Одной из наиболее болезненных проблем является аварийное завершение работы конфигуратора (краш 1cv8.exe) на этапе принятия изменений. Особенно часто это происходит, если в базе используются расширения, в которые заимствованы тяжелые справочники, например, НоменклатураКонтрагентов.

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

Анализ ситуации и диагностика ошибки

Рассмотрим типичный сценарий: выполняется обновление версии КА с 2.4.13.103 на 2.4.13.136. В системе установлено расширение, в которое заимствован справочник НоменклатураКонтрагентов. При попытке выполнить «Обновить конфигурацию базы данных» конфигуратор закрывается с системной ошибкой Windows.

Для начала проанализируем запись в журнале событий Windows (Application Error). Типичная картина выглядит следующим образом:

Имя сбойного модуля: backbas.dll
Код исключения: 0xc0000005 (Access Violation)
Версия платформы: 8.3.18.1334 (или аналогичные из веток 8.3.17, 8.3.19)

Код 0xc0000005 означает, что программа попыталась обратиться к защищенному участку памяти. В контексте 1С это часто происходит в момент работы механизма реструктуризации, когда платформа пытается сопоставить физические таблицы SQL с описанием объектов в основной конфигурации и расширениях.

Причина 1: Конфликт структуры данных в «теневых» таблицах

Выясним причину на уровне базы данных. Когда мы заимствуем объект в расширение (особенно с флагом «Изменять данные»), платформа создает в SQL-базе дополнительные таблицы или изменяет существующие для хранения реквизитов расширения. При обновлении основной конфигурации структура справочника НоменклатураКонтрагентов меняется (добавляются индексы, меняются типы реквизитов).

Если в расширении зафиксирована «старая» структура, механизм реструктуризации может войти в клинч при попытке выполнить команду ALTER TABLE. Опытным путем установлено, что если очистить данные в таблице НоменклатураКонтрагентов, ошибка исчезает. Это подтверждает, что проблема кроется в несовместимости текущих данных с новыми требованиями структуры (например, нарушение уникальности новых индексов), которые платформа не может корректно обработать и «падает» вместо вывода сообщения об ошибке.

Причина 2: Известные баги платформы (Baidu-эффект и другие)

Проанализируем программные ошибки самой платформы. Существует известный баг №40049115. Изначально он был связан с некорректным обращением платформы к внешним интернет-ресурсам при проверке лицензии, что вызывало падение backbas.dll. Однако, как показывает практика, аналогичные симптомы проявляются и при работе с расширениями в версиях ниже 8.3.18.1483.

Метод 1: Обновление платформы (Рекомендуемый)

Первым делом необходимо исключить ошибки самой платформы. Исправления для стабильной работы с реструктуризацией расширений были внесены в более поздние релизы.

Проверим текущую версию. Если это 8.3.18.1334 или 8.3.17.1851, риск вылета крайне высок.
Рекомендуется установить версию не ниже 8.3.19.1229, 8.3.20.2180 или актуальные релизы веток 8.3.22+.
После установки новой платформы обязательно очистим кэш сервера 1С (папки внутри reg_1541) и кэш пользователя.

Метод 2: Временное отключение расширения без потери структуры

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

Важно: Этот метод подходит, если в расширении справочник заимствован только для изменения логики (модули), а не для добавления новых реквизитов. Если добавлены уникальные реквизиты расширения, их данные могут быть потеряны при удалении.

Выполним следующие шаги:

Зайдем в список расширений и снимем флаг «Используется» у проблемного расширения.
Попробуем выполнить обновление конфигурации БД.
Если это не помогает, сохраним расширение в файл .cfe и удалим его из базы.
Произведем обновление конфигурации (F7). На этом этапе основная таблица НоменклатураКонтрагентов успешно реструктуризируется.
Добавим расширение обратно из файла.

Метод 3: Использование Технологического журнала для локализации

Если база данных клиент-серверная и причину падения выявить не удается, настроим технологический журнал (ТЖ). Нам нужно поймать событие непосредственно перед крашем.

Создадим файл logcfg.xml в папке conf на сервере со следующим содержанием:


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

После воспроизведения вылета проанализируем последние строки лога. Скорее всего, вы увидите SQL-запрос вида ALTER TABLE _ReferenceXXX. По имени таблицы _ReferenceXXX можно определить, какой именно объект (основной или из расширения) вызвал сбой, выполнив запрос в SQL Management Studio:


SELECT * FROM MyDatabase.dbo.Config WHERE FileName = 'metadata.uuid'
-- Или через просмотр соответствий в таблице _StructureStorage

Метод 4: Исправление данных через XML-выгрузку

Рассмотрим ситуацию, когда падение вызвано именно «кривыми» данными в справочнике, которые не проходят по новым правилам реструктуризации. Если вы не хотите терять данные, выполним следующее:

Создадим обработку для выгрузки справочника НоменклатураКонтрагентов в XML через СериализаторXDTO.
Очистим таблицу справочника (в тестовой базе можно использовать ОбменДанными.Загрузка = Истина).
Выполним обновление конфигурации. Теперь реструктуризация пройдет мгновенно, так как таблицы пусты.
Загрузим данные обратно из XML. При загрузке платформа проверит объекты по новым правилам, и если есть ошибки (например, дубли по новым индексам), вы сможете их исправить программно в процессе загрузки.

Пример кода для быстрой очистки (использовать с осторожностью):


Выборка = Справочники.НоменклатураКонтрагентов.Выбрать();
Пока Выборка.Следующий() Цикл
    Объект = Выборка.ПолучитьОбъект();
    Объект.ОбменДанными.Загрузка = Истина;
    Объект.Удалить();
КонецЦикла;

Дополнительные рекомендации

Проанализируем влияние сетевых настроек. В некоторых случаях (ошибка Baidu) помогает временное отключение сетевого адаптера на сервере или добавление записи в файл hosts:

127.0.0.1 baidu.cn

Хотя в случае со справочником НоменклатураКонтрагентов это скорее вспомогательная мера, исключающая влияние лицензионного модуля на стабильность работы backbas.dll.

Подведем итог: Основная стратегия при вылете конфигуратора на реструктуризации — это последовательное исключение факторов. Сначала обновляем платформу до стабильной (8.3.19+), затем пробуем обновиться без расширения, и в крайнем случае — прибегаем к временной очистке данных проблемного справочника. Помните, что перед любыми манипуляциями с таблицами через SQL или массовым удалением необходимо создать полную резервную копию базы данных.