Каждый разработчик 1С рано или поздно сталкивается с ситуацией, когда точки останова в клиентских процедурах срабатывают без проблем, но стоит коду уйти на сервер (в серверный модуль, фоновое задание или подписку на событие), как отладчик начинает их игнорировать. Системный администратор при этом уверяет, что перезапустил службу сервера с заветным ключом -debug, но отладка в Конфигураторе всё равно «не цепляет» серверный контекст. В этой статье мы подробно разберем, почему возникает эта проблема, как провести глубокую диагностику и правильно настроить окружение, не прибегая к небезопасному отключению сетевой защиты.
Доверять словам коллег — это хорошо, но профессиональная диагностика требует точных фактов. Выясним, действительно ли служба сервера 1С:Предприятие запущена в режиме отладки. Для этого нам понадобится доступ к серверу (через удаленный рабочий стол RDP или с помощью администратора).
Рассмотрим по шагам, как проверить параметры запуска:
ragent.exe. Если процессов несколько, обратим внимание на тот, который отвечает за нужную нам службу.ragent.exe. В тексте команды обязательно должен присутствовать параметр -debug.Если этого параметра в командной строке нет, то, как бы вас ни уверяли, служба запущена в обычном режиме. В таком случае необходимо открыть редактор реестра Windows на сервере, перейти в ветку:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\1C:Enterprise 8.3 Server Agent...
И в параметре ImagePath дописать ключ -debug в самый конец строки, после чего перезапустить службу из оснастки «Службы».
Очень часто разработчики решают проблему радикальным и небезопасным способом — полным отключением брандмауэра на сервере или локальном компьютере. В реальном корпоративном секторе это грубейшее нарушение политик безопасности. Выясним, как настроить сетевой экран правильно.
При использовании классического протокола TCP/IP Конфигуратор и рабочий процесс сервера 1С (rphost.exe) общаются друг с другом напрямую по динамическим портам. Для обеспечения стабильной связи выполним следующие настройки:
ragent.exe, rmngr.exe и rphost.exe. Это более гибкий подход, который защитит от сбоев при изменении сетевых настроек кластера.1cv8.exe (или 1cv8c.exe для тонкого клиента). При первом запуске отладки операционная система обычно выводит предупреждение с запросом на разрешение доступа — здесь крайне важно нажать «Разрешить доступ» для всех типов сетей (частных и публичных).Если классическая отладка по TCP/IP продолжает давать сбои из-за сложной сетевой топологии (например, когда разработчик работает через VPN, NAT или сложную систему маршрутизации), лучшим решением будет переход на протокол HTTP. Он гораздо стабильнее держит соединение и требует открытия всего одного фиксированного порта.
Разберем процесс настройки HTTP-отладки по шагам:
ImagePath нашей службы сервера. Вместо ключа -debug пропишем связку параметров -debug -http. Это укажет серверу, что отладочную информацию нужно транслировать по протоколу HTTP.dbgs.exe. По умолчанию он резервирует фиксированный TCP-порт 1550.http://имя_сервера:1550.Бывают ситуации, когда брандмауэр настроен корректно, ключ -debug прописан, но серверные точки останова упорно игнорируются. Проанализируем причину этого явления. Если на одном сервере крутится большое количество информационных баз или настроен агрессивный перезапуск рабочих процессов, новые процессы rphost.exe могут быстро исчерпать стандартный диапазон портов отладки (1560–1591). Конфигуратор при попытке подключения выдаст ошибку о невозможности зарегистрировать предмет отладки.
Для решения этой проблемы мы можем расширить диапазон портов вручную. Выполним следующие действия:
C:\Program Files\1cv8\conf (или соответствующий каталог версии, например C:\Program Files\1cv8\8.3.22.XXX\bin\conf).debugcfg.xml.
<config xmlns="http://v8.1c.ru/v8/debugcfg">
<debugports range="1560:1690" />
</config>
После создания файла перезапустим службу сервера 1С. Теперь процессы будут иметь гораздо больше свободных портов для инициализации сессий отладки.
В процессе активной разработки конфигурация базы данных на сервере кэшируется. Иногда возникает рассинхронизация между версией кода в Конфигураторе разработчика и версией, исполняемой рабочим процессом сервера. Из-за этого отладчик «не видит» актуальные строки кода и пропускает точки останова. Обычная чистка локального кэша пользователя здесь не поможет — требуется сбросить серверный кэш.
Рассмотрим безопасную процедуру очистки кэша на сервере 1С:
C:\Program Files\1cv8\srvinfo.reg_1541.1CV8Reg.lst и папки с логами регистрации 1Cv8Log. Это приведет к утере настроек списка баз данных и истории действий пользователей.В современных конфигурациях 1С (особенно на базе БСП, таких как «1С:Документооборот», «1С:ERP» и др.) многие длительные серверные операции принудительно выполняются в фоновом режиме. Если вы пытаетесь поймать точку останова при проведении документа или формировании отчета, а она пролетает мимо — проверьте, не выполняется ли этот код в фоновом задании.
Для отладки фоновых заданий выполним простые шаги в Конфигураторе:
Теперь при запуске фонового процесса Конфигуратор автоматически перехватит управление, и выполнение кода остановится на вашей точке останова.