В процессе разработки в среде 1С:Предприятие 8.3 часто возникает неприятная ситуация: при первом запуске точки останова срабатывают штатно, однако после внесения изменений в код, повторного обновления или просто повторного запуска клиентского сеанса отладчик перестает перехватывать выполнение. При этом Конфигуратор не выдает явных ошибок, а сами точки останова остаются активными. Рассмотрим подробнее, почему так происходит, и разберем по шагам практические способы решения этой проблемы.
Анализ причин сбоя отладки
Основная причина такого поведения кроется в архитектуре взаимодействия между Конфигуратором и исполняемыми процессами 1С. Выделим ключевые факторы, приводящие к потере связи с отладчиком:
Завершение и пересоздание рабочих процессов сервера: При классическом механизме отладки Конфигуратор подключается к конкретному процессу rphost.exe. Если рабочий процесс завершается (например, по таймауту, из-за превышения лимитов памяти или при перезапуске кластера), серверный предмет отладки пропадает. Новый процесс автоматически может не подключиться к текущей сессии Конфигуратора.
Ограничения классического протокола DBGS (TCP/IP): Традиционный протокол отладки по TCP требует выделения пула портов и чувствителен к разрывам сессий. При частых перезапусках клиентов старые соединения могут зависать в состоянии ожидания закрытия, из-за чего исчерпывается доступный пул портов.
Сброс флагов автоматического подключения: При повторном старте клиентского приложения Конфигуратор не всегда успевает или может автоматически переподключить новые предметы отладки без явного указания соответствующих параметров.
Рассинхронизация версий модулей при динамическом обновлении: Если применялось динамическое обновление («демонобновление»), в памяти сервера и клиента могут оставаться закэшированные копии старых версий модулей. Отладчик сравнивает контрольные суммы строк, и при несовпадении контрольных сумм точка останова просто игнорируется.
Способ 1. Переход на протокол HTTP-отладки
Наиболее надежный и современный способ устранить нестабильность отладки в платформе 8.3 — перевести сервер и Конфигуратор на протокол HTTP. Данный протокол лишен проблем с блокировкой TCP-портов и корректно обрабатывает смену клиентских и серверных сеансов.
Разберем порядок перевода на HTTP-отладку:
Остановим службу сервера 1С:Предприятия через оснастку управления службами (services.msc).
Откроем реестр Windows (или конфигурационный файл службы в Linux) и найдем параметры запуска службы ragent.exe.
В параметрах запуска укажем ключ -http вместе с ключом разрешения отладки -debug:
В Конфигураторе перейдем в меню Сервис — Параметры — Отладка, выберем протокол HTTP и укажем адрес сервера отладки (по умолчанию используется порт 1550).
Способ 2. Проверка настроек автоматического подключения предметов отладки
Если отладка отваливается именно при повторном запуске сеансов, проанализируем параметры перехвата сессий в Конфигураторе. Выполним следующие действия:
В главном меню Конфигуратора откроем Отладка — Подключение....
Убедимся, что включены флаги для всех необходимых типов соединений:
Клиентские и внешние соединения (для перехвата тонкого и толстого клиентов);
Сервер (для отладки серверных модулей и общих модулей с признаком «Вызов сервера»);
Фоновые задания (для отладки регламентных и длительных операций).
В меню Сервис — Параметры — Запуск 1С:Предприятия — Дополнительные проверим активность флагов Устанавливать режим разрешения отладки и Начинать отладку при запуске.
Способ 3. Настройка брандмауэра и сети
Классический механизм TCP-отладки является двунаправленным: клиент и сервер 1С должны иметь возможность открывать обратные сокеты к Конфигуратору. Локальный брандмауэр может успешно пропускать первое соединение, но блокировать повторные входящие пакеты к процессу 1cv8.exe.
Для исключения сетевых блокировок выполним следующие шаги:
Добавим исполняемые файлы 1cv8.exe, 1cv8c.exe, rphost.exe и ragent.exe в список исключений брандмауэра Windows с разрешением всех входящих и исходящих TCP-соединений.
Исключим конфликты адресации между протоколами IPv4 и IPv6. При разрешении имени localhost клиент может подключаться к адресу ::1, тогда как отладчик слушает 127.0.0.1. В строке соединения и настройках отладки рекомендуется явно указывать IPv4-адрес.
Способ 4. Корректировка параметров перезапуска рабочих процессов в кластере
Если на сервере разработки настроен автоматический перезапуск рабочих процессов, отладка будет регулярно сбрасываться. Проверим параметры кластера в консоли администрирования 1С:
Перейдем в свойства кластера или рабочего сервера.
Проверим параметры Интервал перезапуска рабочих процессов, Допустимый объем памяти и Интервал превышения допустимого объема памяти.
На серверах, предназначенных для разработки и отладки, установим эти интервалы в значение 0, чтобы исключить принудительное завершение процессов rphost.exe во время отладочных сессий.
Способ 5. Очистка локального и серверного кэша
При активном использовании динамического обновления в кэше сохраняются устаревшие структуры модулей. Для гарантированного восстановления работы точек останова выполним очистку кэша:
Закроем все запущенные сеансы Конфигуратора и клиентов 1С.
Выполним полное обновление конфигурации базы данных через меню Конфигурация — Обновить конфигурацию базы данных (без использования динамического режима).