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

Отладка на сервере 1С перестаёт работать чаще всего из-за того, что агент сервера запущен без ключа -debug. Это самая распространённая причина: конфигуратор подключается к базе, точки останова расставлены, но выполнение не останавливается, потому что сервер просто не собирает отладочную информацию. Вторая по частоте причина — отладка включена, но по другому протоколу, чем ожидает конфигуратор (TCP вместо HTTP или наоборот).

Проблема усугубляется тем, что в клиент-серверном режиме код выполняется в трёх местах: на клиенте, на сервере и в фоновых заданиях. Конфигуратор по умолчанию подключает только те предметы отладки, которые указаны в настройках, и если фоновое задание или серверный вызов не попадает в список, точка останова молча игнорируется.

Ниже разобраны все типовые причины: от ключей запуска службы агента до блокировки портов фаерволом и особенностей отладки HTTP-сервисов. Материал применим к платформе 8.3 в клиент-серверном варианте работы с СУБД (MS SQL, PostgreSQL и другими).

Как устроена серверная отладка и почему она отключается

В клиент-серверном режиме исполнение кода на сервере контролирует рабочий процесс rphost. Чтобы он мог взаимодействовать с конфигуратором, агент сервера (ragent) должен быть запущен в отладочном режиме. Без ключа -debug сервер работает в штатном режиме и игнорирует все запросы на отладку — при этом никаких ошибок пользователь не видит, точки останова просто не срабатывают.

Важно понимать: включение отладки снижает производительность сервера, потому что рабочие процессы начинают обмениваться дополнительной служебной информацией. Поэтому на продуктивных серверах отладку держат выключенной и включают только на время поиска проблемы или на тестовом контуре.

Начиная с определённых версий платформы доступны два протокола отладки: классический по TCP и отладка по HTTP через сервер отладки (dbgs). Если конфигуратор настроен на один протокол, а сервер — на другой, соединение не установится. Проверить текущий протокол можно в настройках конфигуратора: меню «Сервис» → «Параметры» → вкладка «Отладка».

Включение ключа -debug на службе агента сервера

Основное действие — перезапуск службы агента сервера с ключом -debug. На Windows параметры запуска службы хранятся в реестре: ветка HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services, подраздел агента сервера 1С (имя содержит версию платформы, например «1C:Enterprise 8.3 Server Agent»). В параметре ImagePath в строку запуска добавляется -debug после остальных ключей.

Альтернативный способ без правки реестра — перерегистрировать службу через утилиту sc или запустить агент вручную из командной строки для теста. Ручной запуск удобен для быстрой проверки: если отладка заработала при ручном запуске с ключом, значит проблема точно в параметрах службы.

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

После изменения параметров службу нужно перезапустить. Учтите, что перезапуск агента разорвёт сеансы пользователей, поэтому на продуктивном сервере работу выполняют вне рабочего времени или предупреждают пользователей.

1. 1
   Откройте реестр и найдите службу агента сервера 1С в ветке Services
2. 2
   В параметре ImagePath добавьте ключ -debug в строку запуска
3. 3
   Перезапустите службу агента сервера (net stop / net start или оснастка services.msc)
4. 4
   В конфигураторе откройте Отладка → Подключение и включите автоматическое подключение нужных предметов отладки
5. 5
   Поставьте точку останова в серверной процедуре и выполните действие в клиенте
6. 6
   Убедитесь, что выполнение остановилось, затем после завершения работ уберите ключ -debug и снова перезапустите службу

Настройка подключения предметов отладки в конфигураторе

Даже при правильно запущенном сервере отладка не сработает, если конфигуратор не подключается к нужным предметам отладки. Откройте «Отладка» → «Подключение» → кнопка «Автоматическое подключение» и отметьте типы, которые должны отлаживаться: «Сервер», «Фоновое задание», «HTTP-сервис» и другие по ситуации.

Частая ситуация: разработчик отлаживает проведение документа, серверный код не останавливается, потому что включено автоподключение только к клиенту. При этом в списке доступных предметов отладки серверный контекст виден, но без автоподключения его нужно добавлять вручную до того, как код выполнится.

Для фоновых заданий есть дополнительная тонкость: задание стартует в отдельном сеансе, и подключиться к нему нужно успеть до выполнения целевого кода. Надёжный приём — поставить в начале фонового метода точку останова и включить автоподключение фоновых заданий, тогда конфигуратор подхватит задание сразу при старте.

Протокол отладки: TCP или HTTP

Платформа поддерживает два механизма отладки. Классический — прямое TCP-соединение между конфигуратором и рабочими процессами сервера. Он требует сетевой доступности диапазона портов рабочих процессов (по умолчанию 1560–1591) и порта агента 1540–1541. Если между машиной разработчика и сервером есть фаервол или NAT, TCP-отладка часто не работает именно из-за закрытых портов.

Отладка по HTTP работает через сервер отладки dbgs, который публикуется на веб-сервере (IIS или Apache) аналогично публикации информационной базы. Конфигуратор и сервер 1С обращаются к dbgs по HTTP/HTTPS, поэтому достаточно открытого порта веб-сервера. Этот вариант выбирают, когда конфигуратор и сервер находятся в разных сетях или порты рабочих процессов закрыты политиками безопасности.

Несовпадение протоколов — скрытая причина «неработающей» отладки: сервер запущен с поддержкой HTTP-отладки, а в конфигураторе в параметрах отладки выбран TCP, или наоборот. Проверьте соответствие в «Сервис» → «Параметры» → «Отладка» и в ключах запуска агента.

Сеть, фаервол и права доступа

Если сервер и конфигуратор на разных машинах, проверьте доступность портов. Для TCP-отладки критичны порты агента (1540, 1541) и диапазон портов рабочих процессов (по умолчанию 1560–1591). Проверить доступность можно командой Test-NetConnection server -Port 1560 в PowerShell с машины разработчика.

Отдельная группа проблем — права. Подключение отладчика к серверу требует, чтобы пользователь, от имени которого работает конфигуратор, имел соответствующие права в кластере. Если в кластере заведены администраторы, аутентификация в конфигураторе должна проходить под учётной записью с правами администратора кластера, иначе список предметов отладки будет пустым.

Ещё одна причина — антивирус или системы защиты, которые блокируют межпроцессное взаимодействие или сетевые подключения rphost. Если порты открыты, служба запущена с ключом, но отладка молчит, временно проверьте гипотезу, добавив процессы платформы в исключения защитного ПО.

Особые сценарии: HTTP-сервисы, веб-клиент и расширения

Отладка HTTP-сервисов

Код HTTP-сервисов выполняется на сервере в сеансах, которые создаются при каждом обращении к опубликованному сервису. Чтобы отладить обработчик, включите автоподключение предмета отладки «HTTP-сервис» и отправьте запрос к сервису. Если точка не срабатывает, проверьте, что обращение идёт к той же базе, что открыта в конфигураторе, — при нескольких публикациях легко попасть не в ту базу.

Веб-клиент и тонкий клиент через веб-сервер

При работе через веб-сервер клиентский код отлаживается отдельно от серверного. Для веб-клиента в настройках подключения должен быть включён соответствующий тип предмета отладки, а сам клиент запущен с признаком отладки (параметр в строке запуска или включённая настройка в диалоге подключения).

Код в расширениях конфигурации

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

Когда отладка не нужна: альтернативные способы диагностики

Не всегда для поиска причины ошибки обязательно поднимать серверную отладку. Часть задач решается технологическим журналом: включение событий EXCP и CALL позволяет увидеть, какой код выполнялся на сервере и где возникло исключение, без перезапуска служб и без влияния на пользователей.

Для разовой диагностики удобен замер производительности в конфигураторе и вывод отладочных сообщений через Сообщить() или запись в журнал регистрации. На продуктивном сервере, где перезапуск службы невозможен, это единственный безопасный способ получить информацию о выполнении серверного кода.

Итоговая логика диагностики проста: сначала ключ -debug и перезапуск службы, затем автоподключение предметов отладки, затем протокол и сеть. В подавляющем большинстве случаев проблема решается на первом или втором шаге.

Частые вопросы