В процессе эксплуатации систем на базе 1С:Предприятие 8.3 (особенно на платформе ветки 8.3.24) системные администраторы и разработчики часто сталкиваются с неприятной ситуацией: Конфигуратор отказывается запускаться. Процесс отображается в диспетчере задач, потребляет ресурсы, но окно авторизации или выбора базы так и не появляется. При этом в консоли администрирования сеанс может отсутствовать, а пользователи в режиме предприятия получают уведомления о том, что конфигурация была изменена. Разберем подробно, почему это происходит и как восстановить работоспособность системы.
Прежде чем приступать к активным действиям, проанализируем ситуацию. Основная проблема часто кроется в механизме динамического обновления или автоматической загрузки исправлений (патчей). Платформа может пометить конфигурация как измененную в фоновом режиме, что создает блокировку в таблицах базы данных. Рассмотрим по шагам, как локализовать проблему:
1cv8.exe в диспетчере задач. Если процесс "висит" с потреблением памяти, но без активности диска, он, скорее всего, ожидает ответа от СУБД или заблокирован кэшем.EF_).Config заблокирована процессом rphost, Конфигуратор не сможет инициализироваться.Если штатные методы очистки кэша не помогают, а перезагрузка сервера дает лишь временный эффект, необходимо проверить целостность метаданных в SQL. Посмотрим на примеры запросов, которые помогут выявить следы динамических обновлений, мешающих запуску. Для начала проверим таблицу Config:
SELECT Modified
FROM [ИмяВашейБазы].[dbo].[Config]
WHERE Filename Like '%dyn%'
Если запрос возвращает строки, значит, динамическое обновление все же имело место. Для исправления ситуации и синхронизации основной конфигурации с конфигурацией базы данных можно использовать следующий алгоритм (предварительно обязательно сделайте бэкап!):
-- Удаляем записи о динамическом обновлении
DELETE FROM [ИмяВашейБазы].[dbo].[Config] WHERE [FileName] LIKE 'DynamicallyUpdated';
DELETE FROM [ИмяВашейБазы].[dbo].[Params] WHERE [FileName] LIKE 'DynamicallyUpdated';
-- Если есть эталонная (тестовая) база с той же версией, можно восстановить таблицы из нее
DELETE FROM [ИмяВашейБазы].[dbo].[ConfigSave];
INSERT INTO [ИмяВашейБазы].[dbo].[ConfigSave] SELECT * FROM [ТестоваяБаза].[dbo].[Config];
DELETE FROM [ИмяВашейБазы].[dbo].[Config];
INSERT INTO [ИмяВашейБазы].[dbo].[Config] SELECT * FROM [ТестоваяБаза].[dbo].[Config];
Эти действия позволяют принудительно "успокоить" систему, устранив рассогласование между состоянием базы и ожиданиями платформы.
Разберем ситуацию, когда проблема кроется не в SQL, а в файловой системе сервера приложений. В новых версиях платформы 1С реализован обновленный механизм кэширования метаданных. Обычный параметр запуска /ClearCache очищает только локальный кэш пользователя, но не затрагивает серверный. Проанализируем содержимое папки srvinfo на сервере 1С.
Существует специфический кэш, известный как snacc. При некорректном завершении фоновых заданий или сбоях при обновлении расширений данные в нем могут повредиться. Выполним следующие шаги для очистки:
C:\Program Files\1cv8\srvinfo\reg_1541\...).snacc.Для предотвращения подобных проблем в будущем можно настроить автоматическую очистку серверного кэша скриптом, что заставит сервер корректно пересобирать кэш метаданных при возникновении сбоев.
Рассмотрим подробнее влияние фоновых процессов. Иногда Конфигуратор не запускается из-за того, что база занята регламентными операциями, такими как Обновление индексов полнотекстового поиска или Извлечение текстов. В платформе 8.3.24.1548 замечена особенность: если фоновое задание обращается к расширению, которое в этот момент проверяется Конфигуратором на предмет связи с хранилищем, возникает "тупиковая" блокировка.
Выясним причину через консоль администрирования или более функциональную консоль регламентных и фоновых заданий. Если вы видите активные сеансы, которые невозможно завершить обычным способом, воспользуйтесь утилитой SQL sp_who2 для поиска блокирующих процессов. В некоторых случаях помогает временное отключение всех регламентных заданий через консоль кластера перед запуском Конфигуратора.
Проанализируем ситуацию с версиями платформы. Ветка 8.3.24 (в частности релиз 1548) получила много отзывов о нестабильной работе Конфигуратора. Если вышеуказанные меры помогают ненадолго, рассмотрим вариант перехода на более стабильные сборки. Для этого можно использовать консольное переключение между платформами, что значительно упрощает администрирование служб. Опыт многих администраторов показывает следующее:
Config.EF_.Важный момент: если вы используете Хранилище конфигурации, убедитесь, что у всех разработчиков установлена идентичная версия платформы. Различие даже в последних цифрах сборки может приводить к ошибкам формата потока при чтении метаданных, что блокирует запуск Конфигуратора у других участников процесса.
Мы рассмотрели комплексный подход к решению проблемы. Подведем итоги: залог стабильной работы Конфигуратора — это отсутствие "динамических хвостов" в SQL, чистый серверный кэш и контроль над автоматическими исправлениями конфигурации. Если вы столкнулись с зависанием, начните с проверки SQL-таблиц и очистки папки snacc, а если проблема повторяется — планируйте обновление платформы до актуальных стабильных релизов.