Что делать, если перестала работать отладка на сервере 1С:Предприятие?

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

Анализируем строку запуска службы сервера

Первым делом нам необходимо убедиться, что сервер 1С вообще запущен в режиме, позволяющем проводить отладку. Разберем структуру параметров службы ragent. Для этого откроем редактор реестра или оснастку «Службы» и найдем строку запуска. Она должна выглядеть примерно так:

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

Рассмотрим ключевой параметр -debug. Если этот флаг отсутствует, серверные процедуры и функции не будут доступны для отладчика, и вы не сможете остановиться на точках останова в модулях, выполняемых на стороне сервера (например, &НаСервере или в общих модулях с установленным флагом «Сервер»).

Важный нюанс: если вы только что добавили параметр -debug в строку запуска, обязательно перезапустите службу 1С:Предприятие 8.3 Server Agent. Без перезапуска изменения не вступят в силу.

Проверяем сетевую доступность и брандмауэр

Одной из самых популярных причин отказа отладки является блокировка сетевого трафика. Отладка в 1С требует открытия целого диапазона портов. Рассмотрим ситуацию: основной порт агента — 1540, порт реестра — 1541. Однако для нужд отладки платформа динамически выделяет порты из диапазона, указанного в параметре -range (обычно это 1560:1591).

Выполним последовательную диагностику брандмауэра:

1. Отключение защиты для теста: временно отключите брандмауэр Windows (и сторонние антивирусы/фаерволы) как на стороне сервера, так и на стороне клиентской машины. Если после этого отладка заработала — проблема в правилах фильтрации трафика.
2. Настройка исключений: если отладка заработала при выключенном брандмауэре, необходимо создать правила для входящих и исходящих соединений. Нужно разрешить работу по протоколу TCP для портов 1540, 1541 и всего диапазона 1560–1591.
3. Проверка клиентской части: часто системные администраторы забывают, что правила нужно прописывать не только на сервере, но и на локальном компьютере разработчика, так как отладочное соединение устанавливается между процессами dbgs (на сервере) и 1cv8.exe (на клиенте).

Проанализируем состояние портов с помощью команды в командной строке сервера:

netstat -an | find "156"

Это позволит нам увидеть, действительно ли порты в диапазоне отладки находятся в состоянии прослушивания (LISTENING).

Выбор протокола отладки: TCP/IP или HTTP

Начиная с версии 8.3.7, платформа 1С поддерживает два протокола отладки. Рассмотрим их различия, так как неверный выбор в настройках может «сломать» отладку. В Конфигураторе перейдем в меню Сервис — Параметры — Отладка.

Если выбран режим «Отладка по протоколу TCP/IP», то на сервере должен быть прописан флаг -debug. Если же вы решили использовать «Отладку по протоколу HTTP», то сервер должен быть запущен с параметром -http. При использовании HTTP-отладки появляется отдельный сервис (отладочный сервер), который по умолчанию работает на порту 1550.

Рекомендация: если отладка внезапно перестала работать, проверьте, не переключил ли кто-то из коллег режим протокола в параметрах Конфигуратора. Если вы используете старый способ через TCP/IP, убедитесь, что в параметрах отладки на клиенте не стоит галочка использования HTTP.

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

Иногда отладка «не работает» просто потому, что Конфигуратор перестал автоматически подключаться к запущенным сеансам. Выясним причину в настройках подключения:

1. В Конфигураторе откройте меню Отладка — Подключение....
2. Нажмите кнопку Настройка.
3. Убедитесь, что в разделе «Автоматическое подключение» установлены флажки для пунктов: «Серверные процедуры и функции» и «Устанавливать режим отладки при запуске».

Если эти галочки сняты, отладчик будет игнорировать серверные вызовы, пока вы не подключитесь к конкретному сеансу вручную через список доступных предметов отладки.

Проблемы нескольких сетевых интерфейсов

Разберем ситуацию, когда сервер 1С имеет несколько сетевых адаптеров (например, локальная сеть и VPN). В этом случае процесс отладки может пытаться связаться с клиентом через неправильный IP-адрес. Это часто происходит на так называемых Multihomed-серверах.

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

192.168.1.10 SERVER-1C

Также стоит проверить настройки IPv6. Иногда система пытается приоритетно использовать IPv6 для связи, что не всегда корректно поддерживается сетевой инфраструктурой или конфигурацией 1С. Попробуйте временно отключить IPv6 в свойствах сетевого адаптера.

Очистка кэша и зависшие процессы

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

Выполним следующие шаги:

1. Полностью остановите службу 1С.
2. Убедитесь через «Диспетчер задач», что процессы rphost, rmngr и ragent завершены. Если остались «сироты», завершите их принудительно.
3. Очистите папку кэша на клиентской машине: %AppData%\1C\1cv8 и %LocalAppData%\1C\1cv8.
4. Удалите базу из списка и добавьте её заново — это обновит внутренние идентификаторы подключения.

Также стоит обратить внимание на процессы dbgs.exe. В некоторых версиях платформы отладочный сервер выделяется в отдельный процесс. Если он завис в состоянии TIME_WAIT, новые сеансы отладки не смогут инициализироваться. Полный перезапуск сервера (железа) или службы 1С обычно решает эту проблему.

Соответствие версий платформы

Проанализируем ситуацию с обновлением. Отладка крайне чувствительна к несовпадению версий платформы. Если на сервере установлена версия 8.3.8.1652, а на клиентской машине «тихо» обновили тонкого клиента до 8.3.8.1700, основные функции работы с базой могут сохраниться, но отладка работать не будет. Всегда следите за тем, чтобы релизы платформы на всех узлах системы совпадали до последнего знака.

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