Проблема с нестабильной работой процесса dbgs.exe (сервера отладки) является одной из самых «болезненных» для разработчиков и администраторов систем на базе «1С:Предприятие 8.3». Начиная с версии 8.3.18, когда компания 1С активно начала внедрять протокол отладки по HTTP, многие столкнулись с тем, что сервер отладки начинает потреблять до 100% ресурсов процессора, «вешает» Конфигуратор и клиентские сеансы или просто перестает отвечать. В этой статье мы подробно разберем, почему это происходит, проанализируем технические нюансы и рассмотрим проверенные способы решения проблемы.
Прежде чем приступать к лечению, давайте разберем природу возникновения ошибки. Процесс dbgs.exe отвечает за взаимодействие между предметами отладки (сервером приложений, клиентом) и отладчиком (Конфигуратором). При использовании HTTP-протокола передача данных происходит через веб-запросы. Если проанализировать технологический журнал (ТЖ), часто можно встретить исключение вида Exception=4472f4ae-18e3-407c-a1f2-9650d2d50d57 с описанием Недопустимое значение аргумента функции в модуле IRequestProcessorServiceImpl.cpp. Это указывает на то, что сервер отладки получает некорректный пакет данных или не может правильно интерпретировать состояние сессии.
Рассмотрим одно из самых неочевидных, но эффективных решений. Согласно официальной документации 1С, ключи параметров запуска должны указываться через прямой слэш (/). Однако при стандартной установке сервера 1С в операционной системе Windows создается служба, где параметры прописываются через дефис (-). Опыт показывает, что для HTTP-отладки это имеет критическое значение.
Выполним следующие шаги для исправления:
1C:Enterprise 8.3 Server Agent.regedit) и перейдем в ветку, где описаны параметры запуска службы. Обычно это: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent.ImagePath.-debug -http, заменим это на /debug -http. Важно: ключ -http оставляем с дефисом, а основной ключ /debug пишем через слэш.Как показывает практика, такая простая замена часто снимает аномальную нагрузку на процессор и предотвращает падение процесса dbgs.exe.
Если на одном физическом сервере запущено несколько экземпляров служб 1С (разные версии или разные кластеры), сервер отладки по умолчанию может пытаться занять один и тот же порт или использовать динамические порты, что приводит к конфликтам. Выясним, как это исправить.
Проанализируем ситуацию: когда порт не задан жестко, процесс dbgs.exe может «залипнуть» при попытке перехватить соединение другой службы. Чтобы этого избежать, добавим в строку запуска службы ключ -debugServerPort с уникальным номером порта для каждой службы.
Пример настройки для двух служб:
Для первой службы (порт 1550):
"C:\Program Files\1cv8\8.3.21.1624\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" /debug -http -debugServerPort 1550
Для второй службы (порт 2550):
"C:\Program Files\1cv8\8.3.25.1234\bin\ragent.exe" -srvc -agent -regport 2541 -port 2540 -range 2560:2591 -d "C:\Program Files\1cv8\srvinfo2" /debug -http -debugServerPort 2550
Это гарантирует, что процессы dbgs.exe разных кластеров не будут мешать друг другу, особенно при использовании внешнего управления сеансами.
Разберем влияние сетевой инфраструктуры. Одной из скрытых причин зависаний dbgs.exe является некорректная работа с протоколом IPv6. Процесс может пытаться прослушивать адреса IPv6, в то время как клиент подключается по IPv4, или наоборот. Это вызывает задержки и таймауты.
Рекомендуемые действия:
hosts (находится в C:\Windows\System32\drivers\etc\) явное соответствие имени сервера его IPv4-адресу. Например: 192.168.1.10 my-1c-server.dbgs.exe пытается «общаться» через неработающий или некорректно настроенный интерфейс.Посмотрим на ситуацию, когда dbgs.exe завис «намертво» и перезапуск службы не помогает надолго. Это может быть связано с повреждением данных о сессиях отладки, которые хранятся в каталоге реестра кластера.
Проведем очистку:
srvinfo (путь к нему указан в параметрах службы).snccntx. В ней хранятся данные о сеансах, включая отладочные, а также может потребоваться ручное удаление спящих сеансов.temp пользователя, под которым запускается служба 1С (для автоматизации можно использовать батник для очистки кэша).Проанализируем поведение систем защиты. Поскольку HTTP-отладка использует стандартные порты и протоколы передачи гипертекста, системы глубокого анализа трафика (DPI) или антивирусные экраны могут блокировать «странные», с их точки зрения, пакеты данных от dbgs.exe. Это приводит к разрыву соединения и зависанию процесса, который бесконечно ждет ответа.
Что нужно сделать:
dbgs.exe в исключения антивируса (доверенная зона).-debugServerPort или динамический диапазон 1560:1591).Не будем забывать, что проблема может быть на стороне самого кода платформы. Рассмотрим ключевые версии:
dbgs.exe.Если ни один из вышеперечисленных способов не помог, а работать нужно здесь и сейчас, проанализируем возможность отката на старый протокол. TCP-отладка более «легковесная» и стабильная, хотя и имеет ограничения (например, она плохо работает через NAT или сложные маршруты).
Как вернуться на TCP:
Просто уберите ключ -http из параметров запуска службы. Оставьте только /debug. В настройках Конфигуратора (Параметры — Отладка) также переключитесь на использование протокола TCP. Это гарантированно избавит вас от проблем с dbgs.exe, так как в этом режиме данный процесс вообще не используется (отладка идет напрямую через порты рабочих процессов).
Подводя итог, можно сказать, что наиболее эффективным методом лечения «зависаний» является комбинация правильного синтаксиса ключей (использование слэша /debug), явного указания порта отладки и своевременного обновления платформы до стабильных релизов. Надеемся, что эти шаги помогут вам сделать процесс разработки комфортным и стабильным!