Программа 1С перестала отвечать: от клиента до сервера и СУБД

Если 1С завис, сначала подождите 2-3 минуты и посмотрите в диспетчере задач на процесс 1cv8c.exe (тонкий клиент) или 1cv8.exe (толстый клиент, Конфигуратор). Процессор занят — программа считает, её лучше не трогать. Нагрузка 0% и окно «Не отвечает» — снимайте процесс, а если зависание повторяется у всех пользователей, ищите причину на сервере: висящий сеанс, блокировку или проблему в СУБД.

Что делать, зависит от масштаба. Завис один компьютер — хватает перезапуска клиента и очистки кэша. Зависли все — работают с консолью кластера, техжурналом и СУБД. Для файловой базы путь короче: проверка файла блокировки и тестирование утилитой chdbfl.exe.

Первые действия на компьютере пользователя

Пользователь видит одно и то же: окно не реагирует, курсор крутится. Причин у этого несколько, и первые шаги их разделяют.

1. Подождите 2-3 минуты. Закрытие месяца , большой отчёт или групповое перепроведение спокойно идут 10-20 минут.
2. Откройте диспетчер задач: Ctrl+Shift+Esc. Найдите процесс клиента 1С и посмотрите на столбцы «ЦП» и «Диск».
3. Если процесс нагружает процессор, программа работает. Попробуйте прервать операцию сочетанием Ctrl+Break — в 1С оно прерывает выполнение кода на клиенте, если операция это допускает.
4. Если нагрузка нулевая несколько минут подряд, клиент чего-то ждёт: ответа сервера, сети или снятия блокировки. Запомните, что делал пользователь в момент зависания, — это понадобится дальше.
5. Снимите процесс: правой кнопкой по нему → «Снять задачу».

После перезапуска запустите 1С с очисткой кэша. В окне запуска выберите базу → «Изменить» → пройдите до последнего шага → в поле «Дополнительные параметры запуска» впишите:

/ClearCache

Если не помогло, закройте 1С и удалите вручную папки с длинными именами вида GUID в каталогах:

%APPDATA%\1C\1cv8
%LOCALAPPDATA%\1C\1cv8

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

💡 Если виснет только один компьютер, проверьте ещё антивирус и свободное место на системном диске. Антивирус, который проверяет каждый файл кэша 1С, даёт задержки по 10-30 секунд на открытие форм.

Сеансы в консоли администрирования: найти и завершить зависший

Для клиент-серверной базы главный инструмент — «Администрирование серверов 1С Предприятия» (консоль кластера). Её ставят вместе с платформой, если выбран компонент администрирования.

Порядок действий:

1. Откройте консоль и подключитесь к центральному серверу кластера. Консоль работает через агент сервера, порт по умолчанию 1540.
2. Раскройте Кластеры → <кластер> → Информационные базы → <ваша база> → Сеансы.
3. Отсортируйте сеансы. Подозрительные признаки: сеанс пользователя, который давно ушёл; большое время вызова; сеанс фонового задания, который висит часами.
4. Посмотрите на соседний узел «Блокировки» той же базы — там видно, какие сеансы держат блокировки объектов.
5. Выделите зависший сеанс → правая кнопка → «Удалить».

Если консоль не открывается или виснет сама, используйте утилиту командной строки rac. Она обращается к сервису ras, который должен быть запущен. Посмотреть кластеры и сеансы с лицензиями:

rac cluster list
rac session list --cluster=<UUID_кластера> --licenses

Синтаксис команды завершения сеанса смотрите в справке: rac help session.

Когда завис весь сервер, а не отдельный сеанс, загляните в диспетчер задач на сервере. Процессы rphost.exe — рабочие процессы кластера. Если один из них занял почти всю память или весь процессор, это и есть узкое место. Перезапуск службы «Агент сервера 1С:Предприятия 8.3» лечит такую ситуацию, но перезапуск службы обрывает сеансы всех пользователей всех баз кластера. Делайте это после предупреждения или в нерабочее время.

Блокировки и технологический журнал: кто кого ждёт

Частый сценарий зависания «у всех» — не поломка, а ожидание блокировки. Один пользователь проводит большой документ, фоновое задание пересчитывает итоги, остальные ждут, пока освободятся те же записи регистров.

Типичные тексты ошибок, которые появляются после такого ожидания:

• 🔒 Превышено максимальное время ожидания предоставления блокировки — управляемая блокировка не была получена за отведённое время (по умолчанию 20 секунд);
• 🔁 Конфликт блокировок при выполнении транзакции — взаимоблокировка, две транзакции ждут друг друга;
• ⏳ окно висит без ошибки — ожидание идёт на уровне СУБД.

Найти виновника помогает технологический журнал. Он включается файлом logcfg.xml, который кладут в каталог conf платформы на сервере, обычно C:\Program Files\1cv8\conf\. Пример настройки для поиска блокировок:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog" history="24">
    <event><eq property="name" value="TLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <property name="all"/>
  </log>
</config>

Сервер подхватывает файл без перезапуска, в течение минуты. Дождитесь повторения зависания и откройте логи в папке D:\techlog:

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

Когда зависание идёт со стороны СУБД (SQL Server и PostgreSQL)

Если в консоли кластера всё спокойно, а запросы висят, смотрят на сервер СУБД. Там видна блокировка на уровне таблиц и строк, которую 1С не всегда показывает.

Microsoft SQL Server. В SQL Server Management Studio выполните запрос — он покажет, кто кого блокирует:

SELECT session_id, blocking_session_id, status,
       wait_type, wait_time, command
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Значение в blocking_session_id — номер сессии-блокировщика. Если она сама ничего не делает и висит в открытой транзакции, это и есть причина.

PostgreSQL. Долгие запросы и цепочки ожиданий:

SELECT pid, usename, state, wait_event_type,
       now() - query_start AS duration,
       left(query, 80) AS query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY duration DESC;

SELECT pid, pg_blocking_pids(pid) AS blocked_by
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

Что ещё проверить на сервере СУБД:

• 💾 свободное место на дисках с файлами базы, журналом транзакций и tempdb;
• 🧠 память: если SQL Server без ограничения памяти съел всю ОЗУ, сервер 1С на той же машине начинает тормозить;
• 📊 давно ли обновлялась статистика и перестраивались индексы.

Сброс блокировок и проверка базы на ошибки

Иногда база продолжает «висеть» и после того, как все сеансы закрыты. Тогда чистят следы аварийного завершения и проверяют саму базу.

Перед любым из этих действий сделайте резервную копию базы : выгрузку .dt или бэкап средствами СУБД.

Файловая база

1. Убедитесь, что в базе никто не работает , и закройте все окна 1С на всех компьютерах.
2. Откройте папку базы. Рядом с файлом 1Cv8.1CD может лежать файл 1Cv8.1CL — это файл блокировки.
3. Если файл остался после аварийного выключения и его не удаётся открыть никаким процессом, удалите его.
4. Запустите утилиту chdbfl.exe из каталога bin платформы, укажите путь к 1Cv8.1CD, отметьте «Исправлять обнаруженные ошибки».

Если файл 1Cv8.1CL не удаляется, значит, его держит живой процесс — на сервере, где лежит база, или на одном из клиентов. Ищите его, а не перезагружайте всё подряд.

Клиент-серверная база

Здесь «таблица блокировок» — это сеансовые данные кластера. Когда сеансы висят в консоли и не удаляются, чистят кэш кластера:

1. Предупредите пользователей: все сеансы всех баз этого сервера будут оборваны.
2. Остановите службу «Агент сервера 1С:Предприятия 8.3».
3. Откройте каталог srvinfo\reg_1541 и удалите папки, имя которых начинается на snccntx.
4. Запустите службу заново.

Остальные файлы в reg_1541 не трогайте: там хранится реестр кластера со списком баз.

Тестирование в Конфигураторе

Если зависания идут на одних и тех же документах, проверьте логическую целостность. В Конфигураторе: Администрирование → Тестирование и исправление. Отметьте проверку логической и ссылочной целостности и пересчёт итогов. Для этого режима нужен монопольный доступ: в базе не должно быть других пользователей.

💡 Пересчёт итогов на большой базе идёт часами. Запускайте его вечером или в выходные, а не посреди рабочего дня.

Если ничего не помогло

Бывает, что все шаги пройдены, а 1С продолжает виснуть. Тогда проверьте вещи, о которых вспоминают последними:

• 🌐 Сеть. Файловая база в общей папке очень чувствительна к потерям пакетов и Wi-Fi. Проверьте, виснет ли 1С на компьютере, подключённом кабелем.
• 🔢 Версии платформы. Номер версии клиента должен совпадать с номером версии сервера. Несовпадение даёт ошибки при подключении, а иногда — странные зависания.
• 🧩 Внешние обработки и расширения. Отключите расширения и запустите базу. Если зависания пропали, виновато расширение.
• 🕒 Регламентные задания. Обмен, загрузка курсов или полнотекстовый индекс могут стартовать в рабочее время и держать базу. Посмотрите расписание в Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания.
• 🖥️ Железо. Нехватка ОЗУ, медленный HDD под базой, перегретый процессор на сервере.

Если зависание воспроизводится на конкретной операции, сохраните техжурнал за этот момент и передайте его разработчику конфигурации или обслуживающей организации. С логом причину находят за час, без него — за дни.

Как не допустить зависаний в будущем

Профилактика проще, чем разбор аварии. Основные меры:

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

Частые вопросы