← На главную

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

Причины возникновения сбоя и ошибки дампа

Проанализируем механику работы платформы при изменении состава фоновых и регламентных процессов:

1. Рассинхронизация клиентского кэша метаданных: При добавлении нового предопределенного регламентного задания или изменении его признака использования клиентское приложение может обращаться к устаревшим описаниям структуры базы данных, сохраненным в локальном кэше. При вызове функций чтения списка заданий (например, метода РегламентныеЗадания.ПолучитьРегламентныеЗадания()) возникает критическое исключение, приводящее к аварийному завершению процесса.
2. Зависшие потоки рабочих процессов rphost: Если во время реструктуризации конфигурации базы данных выполнялись фоновые задания, они могут перейти в «зависшее» состояние. В консоли кластера серверов такие сеансы могут не отображаться, однако при попытке повторного сохранения конфигуратор сообщает о наличии активных фоновых заданий, блокирующих применение изменений.
3. Повреждение серверного кэша сеансов: В каталоге данных кластера серверов 1С (srvinfo) накапливаются контекстные данные сеансов (каталоги snccntx*), несоответствие которых новой версии метаданных вызывает падение рабочего процесса сервера.

Способ 1. Полная очистка локального кэша и передобавление базы

Самый быстрый и действенный способ устранить сбой при запуске консоли заданий и падении сеансов — пересоздать связку клиентского приложения с базой данных:

1. Закроем все запущенные сеансы «1С:Предприятия» и конфигуратора на рабочем месте.
2. В окне запуска 1С выделим проблемную информационную базу, запомним или скопируем путь к ней (или параметры подключения к серверу).
3. Нажмем кнопку «Удалить» и удалим базу из списка. При этом физические данные базы не затрагиваются, но очищаются все локальные привязки кэша по ее старому внутреннему идентификатору (GUID).
4. Нажмем кнопку «Добавить», выберем добавление существующей информационной базы и укажем ее параметры заново.
5. Запустим режим «1С:Предприятие» и повторно откроем «Консоль заданий».

Также полезно выполнить ручную очистку каталогов временных файлов пользователя, удалив папки со сложными буквенно-цифровыми именами из каталогов %LocalAppData%\1C\1cv8\ и %AppData%\1C\1cv8\.

Способ 2. Очистка серверного кэша и сброс зависших сеансов

Если ошибка возникает у множества пользователей одновременно, включая подключение через RemoteApp, или конфигуратор не дает применить изменения из-за «фантомных» фоновых процессов, выполним регламентные действия на сервере:

1. Откроем оснастку администрирования кластера серверов 1С и в свойствах нужной информационной базы временно установим флаг «Блокировка регламентных заданий включена», а также заблокируем начало новых сеансов.
2. Остановим службу агента сервера 1С (служба 1C:Enterprise Server Agent или ragent).
3. Перейдем в рабочий каталог сервера (по умолчанию C:\Program Files\1cv8\srvinfo\reg_xxxx\) и очистим содержимое подпапок сеансовых контекстов snccntx*. Важно: не удаляйте конфигурационные файлы кластера (1CV8Clst.lst, 1cv8wsregistry.lst).
4. Запустим службу агента сервера 1С.
5. Снимем блокировки в консоли администрирования кластера.

Способ 3. Проверка логической целостности базы данных

Если после очистки кэша ошибка сохраняется, выполним регламентные процедуры по восстановлению целостности внутренних таблиц:

1. Запустим конфигуратор в монопольном режиме и откроем меню «Администрирование» → «Тестирование и исправление...».
2. Отметим обязательные пункты:
   • Реиндексация таблиц информационной базы;
   • Проверка логической целостности информационной базы;
   • Проверка ссылочной целостности информационной базы.
3. Выполним операцию и проанализируем сформированный отчет на наличие поврежденных служебных записей.

Для предотвращения подобных ошибок в будущем рекомендуется избегать изменения состава и свойств регламентных заданий в режиме динамического обновления, а также использовать типовые механизмы управления заданиями Библиотеки стандартных подсистем (БСП) без установки признака «Предопределенное» в дереве метаданных.