Что делать, если при сохранении расширения 1С отключился сервер и возникает ошибка формата потока?

Программист 1С v8.3 (Управляемые формы) 1С:Управление нашей фирмой IT и автоматизация бизнеса
← На главную

Аварийное завершение работы сервера или внезапное отключение электропитания в момент сохранения метаданных — один из самых опасных сценариев для любой базы данных. В случае с платформой 1С:Предприятие такая ситуация практически гарантированно приводит к разрушению структуры таблиц. Чаще всего пользователи сталкиваются с критической ошибкой «Ошибка формата потока», при которой база данных отказывается запускаться в режиме Предприятия, а стандартное тестирование утилитой chdbfl.exe либо не находит ошибок, либо исправляет заголовки таблиц, но не решает проблему запуска.

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

Почему замена таблицы CONFIGCAS из резервной копии не решает проблему?

Рассмотрим внутреннюю структуру хранения расширений в платформе 1С. Попытка восстановить базу данных путем частичной замены поврежденных таблиц (например, таблицы CONFIGCAS, в которой хранятся двоичные данные расширений) из недавней резервной копии часто приводит к тому, что Конфигуратор начинает открываться, но при запуске в режиме Предприятия происходит аварийное завершение работы процесса (падение платформы с предложением запустить отладку в Windows).

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

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

Единственный надежный способ вернуть базу к жизни в такой ситуации — полностью вырезать поврежденные расширения из структуры метаданных. Рассмотрим, как это сделать.

Способ 1. Удаление расширений через командную строку (Самый безопасный метод)

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

Для выполнения этой операции закроем все сеансы работы с базой данных и запустим командную строку Windows (cmd) от имени администратора. Нам понадобятся специальные параметры запуска конфигуратора.

Проанализируем команду для удаления всех расширений из базы данных:


"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F "D:\Put_K_Baze" /N "Admin" /P "Password" /DeleteCfg -AllExtensions

Разберем параметры этой команды подробнее:

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


"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F "D:\Put_K_Baze" /N "Admin" /P "Password" /DeleteCfg -Extension "ИмяПроблемногоРасширения"

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

Способ 2. Полная очистка таблиц в СУБД (Для клиент-серверного варианта)

Если поврежденная база данных развернута на SQL-сервере (MS SQL Server, PostgreSQL, IBM DB2), мы можем выполнить низкоуровневую очистку таблиц напрямую через консоль СУБД. Это позволяет быстро восстановить работоспособность без использования конфигуратора.

Важно: Перед выполнением любых прямых запросов к СУБД обязательно создайте резервную копию базы данных средствами самой СУБД!

Для полного удаления информации о расширениях нам необходимо очистить три таблицы одновременно, чтобы не нарушить ссылочную целостность метаданных. Запустим среду управления СУБД (например, SQL Server Management Studio или pgAdmin) и выполним следующий запрос:


DELETE FROM _ExtensionsInfo;
DELETE FROM ConfigCAS;
DELETE FROM ConfigCASSave;

Примечание: В зависимости от версии платформы 1С и особенностей ее установки, имена таблиц в СУБД могут иметь префиксы или незначительно отличаться регистрами букв. Перед выполнением запроса найдите эти таблицы в списке таблиц вашей базы данных, чтобы уточнить их точные названия.

После выполнения данного запроса и перезапуска службы сервера «1С:Предприятие» база данных запустится без расширений, как чистая типовая конфигурация.

Способ 3. Поиск и локализация битого расширения при диагностике

Что делать, если в базе данных установлено множество расширений, данные которых критически важно сохранить, и мы не хотим удалять все подряд? Нам нужно выяснить, какое именно расширение повреждено.

Разберем по шагам метод диагностики через процедуру Тестирования и исправления:

  1. Запустим базу данных в режиме Конфигуратора.
  2. Перейдем в меню Администрирование — Тестирование и исправление...
  3. В открывшемся окне снимем все флажки, кроме одного: «Проверка логической целостности расширений конфигураций».
  4. Установим переключатели в положение «Только тестирование» и нажмем кнопку «Выполнить».
  5. В процессе тестирования внимательно следим за нижней строкой состояния (status bar) платформы 1С. Платформа последовательно перебирает расширения. Перед тем как программа аварийно закроется с ошибкой формата потока, в строке состояния отобразится имя файла или имя расширения, которое проверяется в данный момент. Это и есть поврежденный объект, который нужно удалить точечно с помощью способа №1.

Важный этап: Очистка «мусорных» ссылок в метаданных (Post-recovery)

Даже после того как база данных успешно запустилась без расширений, радоваться рано. В самой конфигурации остаются «фантомные» или сиротские (orphan) записи, которые платформа создала при установке этих расширений. Эти записи хранятся в стандартных объектах базы данных.

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

Нам необходимо очистить два ключевых объекта:

Для этого запустим базу данных в режиме Предприятия, откроем внешнюю обработку или воспользуемся групповой обработкой данных и выполним следующий программный код для удаления устаревших записей:


// Очистка справочника идентификаторов объектов расширений
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	Идентификаторы.Ссылка КАК Ссылка
    |ИЗ
    |	Справочник.ИдентификаторыОбъектовРасширений КАК Идентификаторы";

Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
    Попытка
        Объект = Выборка.Ссылка.ПолучитьОбъект();
        Если Объект <> Неопределено Тогда
            Объект.ОбменДанными.Загрузка = Истина;
            Объект.Удалить();
        КонецЕсли;
    Исключение
        ЗаписьЖурналаРегистрации("ОчисткаРасширений", УровеньЖурналаРегистрации.Предупреждение, , , 
            "Не удалось удалить элемент: " + СокрЛП(Выборка.Ссылка));
    КонецПопытки;
КонецЦикла;

// Полная очистка регистра сведений версий расширений
НаборЗаписей = РегистрыСведений.ИдентификаторыОбъектовВерсийРасширений.СоздатьНаборЗаписей();
НаборЗаписей.Записать(Истина);

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

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

← На главную