Ситуация, когда процедура Тестирование и исправление (ТиИ) вместо исправления ошибок приводит к аварийному завершению работы платформы, является критической. Особенно часто это происходит с ошибкой в модуле config.dll и кодом исключения 0xc0000005 (Access Violation). В данной статье мы подробно разберем, как локализовать причину падения и восстановить работоспособность базы данных на примере конкретного случая с поврежденными метаданными.
Прежде всего, проанализируем технические данные об ошибке. Сообщение в журнале событий Windows обычно выглядит следующим образом:
1CV8.execonfig.dll0xc0000005Этот код означает ошибку нарушения прав доступа к памяти. В контексте 1С при выполнении ТиИ это почти всегда указывает на то, что программный код платформы пытается обработать данные, структура которых в СУБД (SQL или файловой базе) не соответствует логическому описанию в конфигурации. Рассмотрим основные этапы диагностики, которые помогут нам сузить круг поиска.
Когда мы запускаем процедуру ТиИ, мы часто отмечаем все флажки сразу. Однако для поиска ошибки нам необходимо выяснить, на каком именно пункте происходит вылет. Разберем процесс пошагово:
config.dll.Проанализируем «бегущую строку» в нижней части окна конфигуратора в момент вылета. Хотя платформа закрывается быстро, часто можно успеть заметить имя объекта (справочника или регистра), на котором процесс прервался.
Если визуально определить объект не удается, воспользуемся технологическим журналом. Создадим файл конфигурации logcfg.xml в папке conf (обычно C:\Program Files\1cv8\conf) со следующим содержанием:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\Logs\1C_Error" history="24">
<event>
<eq property="name" value="EXCP"/>
</event>
<event>
<eq property="name" value="DBMSSQL"/>
</event>
<property name="all"/>
</log>
</config>
После этого повторим процедуру тестирования. Последняя запись в логе перед падением укажет на конкретную таблицу базы данных. Например, если в логе фигурирует таблица _InfoReg20541, мы можем вычислить имя регистра, выполнив в консоли запросов или обработке код:
Структура = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого СтрокаТТ Из Структура Цикл
Если СтрокаТТ.ИмяТаблицыХранения = "_InfoReg20541" Тогда
Сообщить("Проблемный объект: " + СтрокаТТ.ИмяТаблицы);
КонецЕсли;
КонецЦикла;
Как показывает практика и разбор конкретных кейсов, частой причиной падения ТиИ является служебный регистр сведений ДатыВступленияВСилуНА. Ошибка возникает из-за появления в нем «дублей» — записей с идентичными измерениями. Платформа при реструктуризации пытается создать уникальный индекс, натыкается на дубль и аварийно завершается.
Рассмотрим, как исправить ситуацию, если виновником оказался этот или аналогичный служебный регистр:
Многие служебные регистры в типовых конфигурациях (ERP, КА, БП 3.0) имеют встроенные механизмы самовосстановления. Выполним следующие действия:
ДатыВступленияВСилуНА и откроем его.Если форма списка не открывается или кнопка отсутствует, выполним очистку программно через внешнюю обработку. Разберем пример кода для полной очистки набора записей:
Процедура ОчиститьРегистр()
Набор = РегистрыСведений.ДатыВступленияВСилуНА.СоздатьНаборЗаписей();
// Мы не устанавливаем отборы, чтобы очистить весь регистр
Набор.Записать(Истина);
Сообщить("Регистр успешно очищен. Теперь запустите ТиИ снова.");
КонецПроцедуры
Если база данных находится на MS SQL Server и вылет происходит даже при попытке открыть регистр в интерфейсе, можно прибегнуть к очистке на уровне СУБД. Выясним имя физической таблицы (как описано в Шаге 2) и выполним команду в SQL Server Management Studio:
TRUNCATE TABLE _InfoReg20541; -- Замените на ваше имя таблицы
Важно: Данный метод допустим только для вспомогательных регистров, данные в которых могут быть восстановлены автоматически или не являются критически важными учетными данными.
Проанализируем важный нюанс: часто пользователи пытаются решить проблему через выгрузку и загрузку файла .dt. Однако формат .dt — это логический дамп базы. Если в базе уже существуют записи, нарушающие логическую целостность (те самые дубли), они будут выгружены и загружены обратно. Реструктуризация при загрузке .dt может пройти успешно, но последующее ТиИ все равно упадет, так как проблема «переехала» в новую базу. Поэтому исправление всегда должно проводиться на уровне данных внутри самой базы.
Выясним еще несколько факторов, которые могут влиять на стабильность ТиИ:
chdbfl.exe для файловой базы не находит ошибок, это не гарантирует отсутствие проблем в кеше сервера 1С. Обязательно выполните полную чистку серверного кеша перед началом работ.Таким образом, комбинируя методы анализа технологического журнала и программную очистку проблемных регистров, мы можем успешно завершить тестирование и исправление даже в самых сложных случаях падения платформы.