Разработка и сопровождение систем на платформе «1С:Предприятие 8» немыслимы без использования механизма отладки. Программисты ежедневно сталкиваются с необходимостью пошагового выполнения кода на стороне сервера. Однако часто возникает крайне неприятная ситуация: отладка на клиенте работает исправно, а точки останова в серверных модулях (например, при вызове процедур "НаСервере" или в общих модулях с флагом "Сервер") без видимых причин перестают срабатывать.
В этой статье мы подробно разберем, почему ломается серверная отладка, проанализируем неочевидные сетевые нюансы и предложим несколько надежных способов решения этой проблемы — от быстрых обходных путей до кардинального перехода на современный протокол отладки по HTTP.
При использовании классического протокола отладки по TCP/IP платформа 1С выделяет под каждый рабочий процесс rphost.exe и сеанс конфигуратора динамические порты из стандартного диапазона (по умолчанию это 1560–1591). В процессе работы службы сервера или при ее некорректном перезапуске (например, из-за аварийного завершения сеансов или блокировок СУБД) некоторые процессы rphost.exe могут зависнуть в памяти операционной системы в режиме «зомби».
Внешне служба сервера 1С перезапускается и работает нормально, но зависшие процессы продолжают невидимо удерживать назначенные им отладочные порты. В результате новые рабочие процессы инициализируют отладку на других портах, которые могут быть заблокированы брандмауэром, либо конфигуратор просто теряет связь с целевым процессом.
Как диагностировать и исправить:
netstat -ano | findstr 1560
rphost.exe, которого нет в списке активных процессов консоли кластера 1С, его необходимо завершить вручную.taskkill /F /PID <Идентификатор_процесса>
По умолчанию конфигуратор пытается обнаружить серверные предметы отладки автоматически в локальной сети. Однако механизмы широковещательного поиска могут давать сбой из-за особенностей сетевой инфраструктуры. Например, если в операционной системе сервера приоритет протокола IPv6 установлен выше, чем у IPv4, сервер 1С может опубликовать отладочные интерфейсы на IPv6-адресе, в то время как компьютер разработчика (клиент) ожидает подключения по IPv4.
Решение проблемы через принудительное подключение:
Если автоматическое обнаружение не работает, мы можем принудительно указать конфигуратору, где искать сетевые сеансы отладки. Для этого выполним следующие шаги:
192.168.1.100).Для жесткого закрепления портов за отладчиком часто используется конфигурационный файл debugcfg.xml. Однако администраторы и разработчики часто совершают распространенную ошибку, размещая его не в том каталоге. Например, если серверная платформа работает в 64-битной версии, а файл ошибочно помещают в каталог 32-битной версии C:\Program Files (x86)\1cv8\conf, система его просто проигнорирует.
Правила настройки debugcfg.xml:
conf активной платформы на сервере. Для 64-разрядного сервера стандартный путь: C:\Program Files\1cv8\conf\. Также допускается размещение в подкаталоге конкретной версии платформы (например, в C:\Program Files\1cv8\8.3.22.1709\bin\conf\).debugcfg.xml для фиксации диапазона портов:
<config xmlns="http://v8.1c.ru/v8/debugcfg">
<debugportrange start="1560" end="1591" />
</config>
Классическая TCP/IP-отладка требует двустороннего сетевого взаимодействия: не только клиент должен обращаться к серверу, но и сервер приложений 1С (процесс rphost.exe) должен иметь возможность инициировать обратное подключение к конфигуратору на рабочей станции программиста. Это соединение очень часто блокируется локальными брандмауэрами (Firewall), антивирусным ПО или правилами NAT при работе через VPN.
Начиная с версии платформы 8.3.7, компания 1С добавила поддержку HTTP-отладки. При этом режиме и конфигуратор, и серверные процессы подключаются к выделенной службе — серверу отладки (dbgs.exe). Все соединения идут в одну сторону («изнутри наружу») по стандартному веб-протоколу, что исключает проблемы с сетевыми экранами.
Пошаговый перевод сервера на HTTP-отладку:
regedit).HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent...
ImagePath. По умолчанию он выглядит примерно так:
"C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug
-http сразу после ключа -debug. Строка должна принять следующий вид:
"C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug -http
services.msc. Теперь на сервере автоматически поднимется служба отладки dbgs.exe, которая по умолчанию начнет слушать порт 1550.http://имя_сервера:1550.После выполнения этих настроек проблемы с доступностью серверных процедур для отладчика исчезнут раз и навсегда, даже если разработчики работают удаленно через VPN-подключения со строгими политиками безопасности.