Почему файловая база 1С падает в дамп при обновлении курсов валют или проведении документов на новой платформе

← На главную

Часто при эксплуатации устаревших конфигураций, таких как Бухгалтерия предприятия 2.0, работающих в режиме совместимости 8.2.16, системные администраторы и программисты сталкиваются с критической ошибкой. При попытке запустить базу на современной платформе (версии 8.3.5 и выше) программа аварийно завершает работу с созданием дампа памяти. Это происходит при выполнении конкретных операций: обновлении курсов валют, записи в регистры сведений или проведении документов. Примечательно, что стандартные средства диагностики, такие как chdbfl.exe и «Тестирование и исправление» (ТиИ), не находят никаких повреждений. Разберем подробно, почему это происходит и как восстановить работоспособность базы.

Проанализируем причину возникновения ошибки

Основная причина кроется в глубоких изменениях механизмов работы платформы с памятью и индексами, начиная с версии 8.3.5. В старых версиях (8.2 и ранние 8.3) менеджер памяти был более «терпим» к логическим несоответствиям в файле .1CD. Если в системных таблицах планов обмена или в индексах регистров сведений появлялись «битые» ссылки или некорректные идентификаторы (GUID), старая платформа могла их просто игнорировать.

Новые версии платформы работают значительно строже. При попытке обращения к таблице, содержащей некорректную структуру записи, или при попытке десериализации данных через XDTO, платформа наталкивается на исключение, которое не может обработать, и «вылетает». Ситуация осложняется тем, что chdbfl проверяет только физическую целостность страниц файла, а ТиИ — логическую связность объектов, но ни одна из них не заглядывает в низкоуровневые системные таблицы регистрации изменений или внутренние индексы, которые могут быть повреждены.

Метод 1. Пересоздание проблемного объекта метаданных

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

Запустим базу на старой версии платформы (например, 8.3.4 или 8.2), на которой она работает стабильно.
Снимем конфигурацию с поддержки (если она на ней стоит), чтобы разрешить редактирование.
Выполним удаление проблемного регистра (предварительно сохранив данные, если они критичны).
Применим изменения в конфигурации БД.
Создадим регистр заново с теми же реквизитами и измерениями или просто вернем конфигурацию из бэкапа (через сравнение/объединение), чтобы объект пересоздался в базе данных «с чистого листа».

Этот метод помогает избавиться от «фантомных» записей в индексах конкретной таблицы.

Метод 2. Очистка таблиц регистрации изменений (Планы обмена)

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

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


УзлыОбмена = ПланыОбмена.Выбрать();
Пока УзлыОбмена.Следующий() Цикл
    Если УзлыОбмена.Ссылка = ПланыОбмена.ЭтотУзел() Тогда
        Продолжить;
    КонецЕсли;
    ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена.Ссылка);
КонецЦикла;

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

Метод 3. Полная перегрузка данных через XML (радикальный способ)

Если выгрузка/загрузка через .dt не помогает, это означает, что ошибка переносится на логическом уровне. Единственный способ полностью избавиться от мусора в структурах данных — это выгрузить все объекты в XML-формат и загрузить их в абсолютно пустую базу, созданную на новой платформе. Это гарантирует, что все таблицы и индексы будут созданы по правилам новой версии 8.3.

Разберем шаги выполнения этой операции:

Создадим новую пустую базу на платформе 8.3.12 или выше.
Загрузим в нее конфигурацию (файл .cf) из исходной базы.
В исходной базе запустим обработку «Выгрузка и загрузка данных XML» (обычно входит в состав состава БСП или ИТС).
Выгрузим все данные. Важно: этот процесс может занять много времени и потребовать большого объема оперативной памяти.
В новой базе выполним загрузку этого XML-файла.

Поскольку при загрузке через XML платформа создает новые записи через ОбменДанными.Загрузка = Истина, она заново формирует все внутренние идентификаторы и записи в таблицах, исключая перенос системного мусора.

Метод 4. Поэтапное повышение режима совместимости

Иногда «прыжок» с режима совместимости 8.2.16 сразу на платформу 8.3.12 слишком велик для внутренних механизмов реструктуризации. Проанализируем ситуацию и попробуем двигаться шагами:

Установим промежуточную версию платформы, например 8.3.6.
В конфигураторе сменим режим совместимости на Версия 8.3.1.
Выполним обновление конфигурации базы данных и обязательно запустим процедуру «Тестирование и исправление» со всеми включенными галочками (реиндексация, реструктуризация).
Если база стабильна, повторим процедуру, повышая режим совместимости до Версия 8.3.3 и так далее, пока не дойдем до актуального значения.

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

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

Если база продолжает падать, посмотрим на использование сторонних утилит, таких как Tool1CD. Она позволяет просматривать физическую структуру таблиц .1CD напрямую. Особое внимание следует уделить полям с типом IDRRef (ссылки на объекты). Если в полях, которые не должны быть пустыми, обнаруживаются нулевые значения или некорректная длина данных, это явный признак повреждения, который не лечится стандартным chdbfl.

Также важно проверить кэш пользователя. Перед каждым тестированием на новой платформе необходимо полностью удалять базу из списка и добавлять её заново, либо вручную очищать папки %AppData%\1C\1Cv8. Часто дамп памяти — это не ошибка в данных, а конфликт старого кэша метаданных с новыми бинарными файлами платформы.

Подводя итог, можно сказать: падение в дамп — это всегда признак того, что платформа встретила данные, которые противоречат её внутренним правилам проверки целостности. Используя последовательную очистку регистраций обмена и пересоздание таблиц через XML, мы сможем подготовить базу к переходу на современные версии платформы и последующему обновлению до Бухгалтерии предприятия 3.0.