Почему в 1С не работает серверная отладка и как обеспечить ее стабильность?

Проблема «пролетающих» точек останова в серверных процедурах и функциях — одна из самых досадных в практике разработчика 1С. Ситуация, когда отладка работает «через раз» или требует постоянного переподключения серверных предметов, часто связана с особенностями работы сетевых протоколов и багами конкретных релизов платформы, особенно в ветке 8.3.16. Разберем детально, как диагностировать и окончательно исправить эту проблему.

Анализ проблемы: почему TCP-отладка часто подводит

Традиционный механизм отладки в 1С использует протокол TCP. В этой схеме не только Конфигуратор подключается к серверу, но и сервер приложений (процесс rphost.exe) должен иметь возможность инициировать «обратное соединение» с компьютером разработчика. В условиях работы через терминальный сервер (RDP) или при наличии сложных сетевых экранов (Firewall) между сервером приложений и клиентом, этот механизм часто дает сбои.

Основные причины нестабильности TCP-отладки:

• Сложности с обратным IP: Серверу 1С бывает трудно определить корректный обратный адрес терминальной сессии для передачи данных отладчику.
• Зависшие порты: Соединения могут оставаться в состоянии TIME_WAIT, блокируя новые попытки подключения предметов отладки.
• Диапазон портов: Необходимо, чтобы на всех участках сети были открыты не только основные порты (1540, 1541), но и весь рабочий диапазон (по умолчанию 1560-1591).

Переход на HTTP-отладку — лучшее решение

Рассмотрим наиболее надежный способ — переход на протокол HTTP. Главное его преимущество в том, что он исключает необходимость «обратного вызова» от сервера к клиенту. В этой схеме появляется промежуточное звено — сервер отладки (dbgs), к которому и Конфигуратор, и серверные процессы подключаются самостоятельно.

Для активации HTTP-отладки нам не требуется установка веб-серверов вроде IIS или Apache. Все работает на встроенных средствах платформы. Выполним следующие шаги:

1. Остановим службу сервера 1С:Предприятие.
2. В реестре Windows или через оснастку служб отредактируем строку запуска службы ragent.exe.
3. Добавим ключи -debug -http. Важно использовать именно тире (минус), а не косую черту.

Пример корректной строки запуска службы:

"C:\Program Files\1cv8\8.3.16.1148\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug -http

После перезапуска службы в Конфигураторе необходимо зайти в меню Сервис — Параметры — Отладка, выбрать протокол HTTP и указать адрес вашего сервера приложений. Теперь предметы отладки будут подключаться гораздо стабильнее.

Очистка серверного и пользовательского кэша

Если отладка продолжает «глючить» даже после настройки ключей, проанализируем состояние кэш-файлов. Часто в каталоге srvinfo накапливаются поврежденные данные о сеансах, которые мешают корректной регистрации отладчика. Рассмотрим скрипт, который помогает радикально очистить окружение для «чистого листа».

Важно: Перед выполнением этих действий необходимо завершить все сеансы пользователей и остановить службу сервера.

rem Остановка службы сервера предприятия 1С x64
net stop "1C:Enterprise 8.3 Server Agent (x86-64)"

rem Принудительное завершение процессов, если они зависли
TASKKIll /F /FI "IMAGENAME eq rphost*"
TASKKIll /F /FI "IMAGENAME eq rmngr*"
TASKKIll /F /FI "IMAGENAME eq ragent*"

rem Удаление пользовательского кэша 1С для всех профилей
@FOR /D %%i in ("C:\Users\*") do (
    @FOR /D %%j in ("%%i\AppData\Local\1C\1Cv8\????????-????-????-????-????????????") do rd /s /q "%%j"
    @FOR /D %%j in ("%%i\AppData\Roaming\1C\1Cv8\????????-????-????-????-????????????") do rd /s /q "%%j"
)

rem Удаление сеансовых данных сервера (snccntx)
for /d %%a in ("c:\Program Files\1cv8\srvinfo\reg_1541\snccntx*") do rd /s /q "%%a"

rem Запуск службы
net start "1C:Enterprise 8.3 Server Agent (x86-64)"

Особое внимание уделим папкам snccntx. Именно в них хранятся данные о текущих соединениях и контексте отладки. Их удаление часто решает проблему, когда точка останова игнорируется без видимых причин.

Проблема релиза 8.3.16.1063

Проанализируем конкретную версию платформы, упомянутую в проблеме. Релиз 8.3.16.1063 признан сообществом достаточно нестабильным в плане отладочных механизмов. В нем наблюдались ошибки, при которых процесс rphost терял связь с менеджером отладки.

Если вышеописанные методы (HTTP-отладка и чистка кэша) помогают лишь на короткое время, выясним возможность обновления платформы. Рекомендуется использовать релизы не ниже 8.3.16.1148 или 8.3.16.1224, где многие ошибки взаимодействия с предметами отладки были исправлены разработчиками «1С».

Дополнительные настройки сетевой безопасности

Посмотрим на ситуацию со стороны системного администрирования. Даже при использовании HTTP-отладки, брандмауэр Windows может блокировать входящие пакеты. Проверим следующие моменты:

• Процесс dbgs.exe (или встроенный в ragent сервис) должен иметь разрешение на работу в сети.
• Для HTTP-отладки по умолчанию используется порт 1560. Если он занят другим приложением, система выберет следующий свободный из диапазона 1560-1591. Убедитесь, что этот диапазон полностью открыт.
• В настройках сетевых адаптеров на серверах желательно отключить протокол IPv6, если он не используется в вашей инфраструктуре. 1С иногда пытается инициировать отладочное соединение по IPv6, в то время как Конфигуратор ждет его по IPv4, что приводит к «невидимости» точек останова.

Подводя итог, наиболее эффективный алгоритм исправления отладки выглядит так: переход на -http в параметрах службы -> очистка snccntx на сервере -> обновление платформы до стабильного билда.