Окно 1С «Не отвечает»: как найти причину и вернуть базу в работу

Утро закрытия месяца. Бухгалтер жмёт «Провести», окно 1С белеет, в заголовке появляется «Не отвечает». Через минуту то же самое у соседки. Первый вопрос, который стоит задать: зависло у одного человека или у всех. От ответа зависит, куда идти дальше: на рабочее место, на сервер или в сеть.

Если 1С не отвечает только у одного пользователя, причина почти всегда локальная: кэш, антивирус, тяжёлый отчёт или нехватка памяти. Если зависание у всех, ищите на сервере, в сети или в блокировках базы. Ниже порядок проверок от безопасных к тем, что прерывают работу людей.

Сначала определите масштаб: один пользователь или вся база

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

Отдельно отличайте зависание от долгой работы. Если закрытие месяца идёт на большом объёме, окно может “не отвечать” честно минут десять, а потом закончить. Откройте диспетчер задач: если процесс 1cv8.exe грузит процессор или диск, он считает. Если нагрузки нет вообще и так уже несколько минут, он действительно ждёт.

Что проверить на компьютере пользователя

Начните с того, что не затрагивает чужую работу.

1. Откройте диспетчер задач и посмотрите на 1cv8.exe: процессор, память, диск. Память под 2 ГБ у 32-разрядного клиента на тяжёлых отчётах — частая причина.
2. Проверьте свободное место на системном диске. Когда его меньше нескольких гигабайт, Windows начинает тормозить на любой записи, а у 1С много записи во временные файлы.
3. Посмотрите, не грузит ли процессор антивирус. Если да, добавьте каталоги базы и каталог данных 1С пользователя в исключения.
4. Закройте лишние сеансы 1С на этом компьютере. Три открытых окна с разными базами заметно давят на память.
5. Перезагрузите компьютер, если он не выключался неделями.

Если помогло только это, значит, дело было в ресурсах рабочего места. Если нет, переходите к кэшу.

Очистка локального кэша

1С хранит на клиенте служебные данные: списки, настройки форм, кэш метаданных. Повреждённый кэш даёт зависание при открытии конкретной формы или при запуске.

Самый безопасный способ — запуск с ключом очистки. В свойствах информационной базы в списке баз, в строке дополнительных параметров запуска, можно указать /ClearCache. Второй способ ручной: закрыть 1С и удалить папки с длинными именами вида GUID в каталогах %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8.

Сервер 1С и службы Windows (клиент-серверный режим)

Когда висят все, зайдите на сервер. В диспетчере задач должны быть процессы ragent.exe, rmngr.exe и несколько rphost.exe. Первый — агент сервера, второй — менеджер кластера, третьи — рабочие процессы, которые и выполняют код.

Проверьте по порядку:

• 🖥️ Служба. В оснастке «Службы» найдите «Агент сервера 1С:Предприятия 8.3» и убедитесь, что она запущена.
• 📈 Нагрузка. Если один rphost.exe занял всё доступное процессор или память, значит, какой-то сеанс гоняет тяжёлый запрос. Это видно по консоли кластера.
• 💾 Диск. Пустое место на диске с данными, журналами и временными файлами. Полный диск останавливает всё.
• 🧠 Память. Если сервер ушёл в подкачку, всё замирает одновременно.

Консоль администрирования серверов 1С покажет, кто и что делает. Раскройте кластер, затем «Сеансы» и «Соединения». Среди сеансов ищите тот, у которого огромное время вызова или потребление памяти. Консоль работает только с серверной версией; для запросов из командной строки есть утилита rac, например rac cluster list. Остальные подкоманды смотрите в справке rac help.

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

Ещё два пункта по серверу, о которых вспоминают редко:

• СУБД. Если база лежит в PostgreSQL или MS SQL Server, а она стала отвечать медленно, посмотрите нагрузку самой СУБД и время последнего обслуживания: обновления статистики и перестройки индексов. Без них запросы выбирают плохие планы и работают в разы дольше.
• Антивирус на сервере. Сканирование каталогов кластера и файлов СУБД даёт те же симптомы, что и неисправный диск.

Сеть: когда сервер жив, а связь тормозит

Если процессы живы и нагрузки нет, а пользователи всё равно висят, проверьте сеть. Для клиент-серверного режима нужны открытые порты: по умолчанию агент слушает 1540, менеджер кластера 1541, рабочие процессы занимают диапазон 1560–1591. Если админ закрыл их на межсетевом экране или поменял правила, соединение будет прерываться или не устанавливаться.

Быстрые проверки с клиентского компьютера:

1. ping имя_сервера — смотрите не только на ответ, но и на время и потери. Скачки от 1 до 300 мс говорят о нестабильном канале.
2. Test-NetConnection имя_сервера -Port 1540 в PowerShell — проверка порта.
3. Сравните скорость работы по проводу и по Wi-Fi. Если по проводу нормально, а по Wi-Fi виснет, виноват беспроводной канал.
4. Проверьте разрешение имён. Если имя сервера то находится быстро, то с задержкой, 1С будет подключаться медленно. В таком случае обратитесь к DNS-настройкам.

Отдельный случай — доступ по VPN или из удалённого офиса. Задержка в 50–80 мс сама по себе делает форму с десятками обращений к серверу вялой. В таких условиях надёжнее работать через терминальный сервер , чем напрямую по VPN.

Для файловой базы сеть критична вдвойне: клиент читает и пишет файл базы по сети, и любая задержка отражается на каждом действии. Никогда не открывайте файловую базу по Wi-Fi или VPN.

Блокировки и взаимоблокировки в базе

Это классическая причина «висит у всех, но нагрузки нет». Один сеанс держит блокировку и ждёт, второй ждёт первого, а третий и четвёртый встали в очередь.

Признаки:

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

Где смотреть, кто виноват. Первое — журнал регистрации: в нём видны ошибки транзакций и блокировок с именем пользователя и временем. В конфигурациях на управляемых формах открывается через раздел «Администрирование» (подраздел поддержки и обслуживания). Второе — консоль кластера со списком сеансов. Третье, для сложных случаев, — технологический журнал, который настраивается файлом logconfig.xml. События TLOCK, TTIMEOUT и TDEADLOCK покажут, кто кого ждал. Технологический журнал при подробной настройке растёт очень быстро, поэтому включайте его на короткое время и с фильтром.

Нужно отличать пессимистичные блокировки СУБД от управляемых блокировок самой 1С. Первые лечатся индексами и оптимизацией запросов, вторые — исправлением кода. Это работа для программиста; админ же может найти виновный сеанс и время.

Файловая база: целостность и утилита chdbfl

Файловая база — это файл 1Cv8.1CD в каталоге. Если во время записи пропало питание, связь с сетевой папкой или процесс убили, файл может оказаться с логическими ошибками. Симптомы: база виснет при открытии определённого справочника или при проведении, иногда сообщения об ошибках чтения.

Для проверки используется утилита chdbfl.exe, которая лежит в каталоге bin установленной платформы.

1. Все пользователи закрывают базу. Проверьте, что в каталоге базы нет активных процессов 1cv8.exe, которые держат файл.
2. Сделайте копию файла 1Cv8.1CD целиком, пока база закрыта.
3. Запустите chdbfl.exe, выберите файл базы.
4. Сначала запустите проверку без галочки исправления: утилита покажет, есть ли ошибки.
5. Если ошибки есть, поставьте флажок исправления и запустите повторно.

Есть и второй инструмент: «Тестирование и исправление» в Конфигураторе. Он требует монопольного доступа и работает глубже: проверяет структуру, ссылки и логическую целостность. Запускайте его после chdbfl, а не вместо него. Отметьте только нужные режимы и не включайте всё подряд на большой базе без запаса времени.

Для файловой базы есть и бытовые причины торможения:

• размер файла перевалил за несколько гигабайт, а работают десять человек одновременно;
• база лежит на сетевой папке с медленным диском;
• кроме базы, на этом же компьютере работает ещё что-то тяжёлое.

Когда одновременно работает больше 10–15 человек или база заметно выросла, пора переезжать на клиент-серверный вариант. Это не лечение зависания, но оно убирает класс проблем.

Как сделать, чтобы 1С отвечала стабильно

Нет смысла разбираться с каждым зависанием отдельно, если можно убрать типовые причины.

• 🧹 Регламентное обслуживание СУБД. Обновление статистики и перестройка индексов хотя бы раз в неделю.
• 🕒 Регламентные задания по ночам. Тяжёлые обмены, пересчёты и закрытие периода — вне рабочего времени.
• 🛡️ Исключения для антивируса. Каталоги кластера, СУБД и базы не должны сканироваться на лету.
• 📊 Мониторинг. Следите за свободным местом, памятью и размером журналов. Чаще всего зависание начинается с переполненного диска.
• 🔄 Обновления платформы. Если у вас старая платформа и нестабильная работа, посмотрите список исправлений в новых релизах: часть зависаний лечится именно ими.
• 🧾 Тяжёлые отчёты. Отчёты за год по всем контрагентам выносите в фон или на ночь.

Чтобы не искать каждый раз по памяти, держите короткий порядок действий под рукой:

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