Часто разработчики сталкиваются с ситуацией, когда серверная отладка, казалось бы, настроена: в списке предметов отладки виден серверный сеанс, он подключен, но при попытке зайти в серверную процедуру точка останова не срабатывает. Программа просто «пролетает» мимо кода, выполняемого на стороне сервера. Разберем по шагам, почему это происходит и как настроить стабильную работу отладчика.
Первым делом проанализируем настройки самой службы 1C:Enterprise 8.3 Server Agent. Для того чтобы отладка в принципе была возможна, служба должна быть запущена с определенным ключом. Выясним, как это проверить:
services.msc.-debug.debug стоит именно стандартный символ дефиса.-debug перед параметром -range.Если ключ был добавлен только что, необходимо перезапустить службу сервера 1С. Помним, что это прервет работу всех активных пользователей.
Даже если сервер настроен верно, Конфигуратор может «не знать», что ему нужно перехватывать управление в определенных моментах. Рассмотрим настройки подключения:
Зайдем в меню Отладка — Подключение.... Здесь мы должны видеть наш серверный сеанс. Однако простого наличия сеанса в списке недостаточно. Нажмем кнопку Настройка... и проанализируем установленные флажки в разделе «Автоматическое подключение»:
Также проверим настройку в самом сеансе отладки. Флаг Клиентские и внешние соединения на сервере должен быть активен. Без этого конфигуратор не сможет инициировать остановку на серверном коде.
Выясним разницу между протоколами отладки, так как это корень большинства проблем с «невидимыми» точками останова.
Режим TCP (Default): в этом режиме сервер должен иметь возможность сам инициировать соединение с компьютером разработчика. Если вы работаете в локальной сети, это обычно не вызывает проблем. Но если сервер находится в дата-центре, а вы — за NAT или используете VPN, сервер просто не «достучится» до вашего IP-адреса. В списке предметов отладки сеанс будет виден (так как клиент сообщил о себе серверу), но команда остановки не пройдет.
Режим HTTP: считается более современным и гибким. Здесь используется специальный сервис отладки (процесс dbgs.exe), который обычно слушает порт 1550. В этом режиме взаимодействие идет через центральный узел, что снимает проблему «обратного звонка» от сервера к клиенту.
Рассмотрим, как перейти на HTTP-отладку:
http://имя_сервера:1550.Проанализируем ситуацию с сетевыми блокировками. Для TCP-отладки требуется открытие диапазона портов не только на сервере, но и на локальной машине разработчика. Обычно это диапазон 1560–1591.
Если используется HTTP-отладка, убедимся, что порт 1550 открыт на сервере. Для проверки доступности порта воспользуемся командой в командной строке:
telnet адрес_сервера 1550
Если экран очистился — порт открыт. Если возникла ошибка подключения — порт блокируется брандмауэром или антивирусом на сервере.
Иногда причиной странного поведения отладчика становится замусоренный кеш или несоответствие версий метаданных. Разберем пошаговый алгоритм очистки:
%AppData%\1C\1cv8 и %LocalAppData%\1C\1cv8.snccntx, находящаяся внутри каталога данных службы (например, в C:\Program Files\1cv8\srvinfo\reg_1541\...). Внимание: это действие требует остановки службы сервера 1С.Если процедура, в которую мы пытаемся зайти, находится в Расширении конфигурации, проверим свойства этого расширения. Флаг Защита от опасных действий иногда может накладывать ограничения на выполнение или отладку кода. Попробуем временно отключить его для целей тестирования.
Также стоит проверить параметр Устанавливать режим разрешения отладки в файле default.vrd, если используется публикация на веб-сервере. Пример настройки в файле публикации:
<debug enable="true" url="tcp://localhost"/>
Или для HTTP:
<debug enable="true" url="http://имя_сервера:1550"/>
Соблюдение этих инструкций и последовательная проверка каждого узла — от ключей запуска службы до настроек сетевых экранов — позволяет решить проблему в 99% случаев.