Проблема с отладкой серверного кода — одна из самых досадных ситуаций, с которой сталкивается разработчик 1С. Особенно странно это выглядит, когда на одном и том же сервере приложений находятся несколько идентичных баз, но в одной из них точки останова на сервере игнорируются, а в других всё работает штатно. В этой статье мы подробно разберем причины такого поведения платформы 1С:Предприятие 8.3, проанализируем известные баги и найдем надежные способы решения проблемы.
Прежде чем приступать к сложным манипуляциям, проанализируем ситуацию. Если отладка работает на клиенте, но «пролетает» мимо серверных процедур, это означает, что механизм подключения предметов отладки (в данном случае rphost) не может корректно связаться с вашим Конфигуратором. Рассмотрим ключевые факторы, которые нужно проверить в первую очередь:
1C:Enterprise 8.3 Server Agent запущена с ключом -debug. Без этого ключа серверная отладка не будет работать ни в одной базе.Начиная с версии платформы 8.3.10 и вплоть до некоторых релизов ветки 8.3.13, наблюдается специфический глюк. Суть его в том, что автоматическое подключение предметов отладки для серверных вызовов срабатывает некорректно при первом запуске сеанса. Проанализируем алгоритм действий для этого случая:
Если вы столкнулись с тем, что отладка «оживает» только после определенных манипуляций, выполните следующие шаги:
Как показывает практика, после такого принудительного переподключения в рамках одного сеанса точки останова начинают срабатывать мгновенно. Это подтверждает наличие программной ошибки в механизме автоматического связывания сеансов 1С.
Рассмотрим более современный и стабильный способ — отладку по протоколу HTTP. В отличие от TCP/IP, где сервер сам пытается инициировать соединение с Конфигуратором (что часто блокируется брандмауэрами или сетевыми экранами), протокол HTTP работает иначе. В этом режиме Конфигуратор выступает в роли активного узла, что снимает 90% проблем с сетевой видимостью.
Разберем, как перевести сервер на HTTP-отладку без использования веб-сервера (IIS или Apache):
-debug на -http.Важно: При использовании HTTP-отладки возможности отладчика расширяются, например, становится проще отлаживать фоновые задания, запущенные на разных рабочих процессах.
Иногда проблема локализуется в одной базе из-за «мусора» в серверных метаданных. Удаление базы из списка консоли администрирования и повторное добавление не всегда полностью вычищает файлы на диске. Проанализируем процесс полной очистки:
Выясним расположение папки с данными сервера. Обычно это C:\Program Files\1cv8\srvinfo. Внутри находятся папки с GUID баз. Чтобы решить проблему, выполним следующие шаги:
rmngr).snccntx внутри директории нужной информационной базы.snccntx и reg_1541 (кроме конфигурационных файлов).Это заставит сервер заново перестроить карту скомпилированных модулей для отладки, что часто исправляет «избирательную» неработоспособность точек останова.
Посмотрим на ситуацию со стороны сетевого взаимодействия. Механизм TCP-отладки чувствителен к разрешению имен (DNS). Если сервер видит ваш компьютер под одним именем (или IP), а Конфигуратор сообщает серверу другое, соединение не установится.
Проанализируем файл hosts на сервере и на рабочей станции разработчика. Рекомендуется жестко прописать соответствие IP-адреса и имени сервера. Также крайне важно проверить настройки протокола IPv6. В некоторых случаях 1С пытается передать параметры отладки через адрес ::1, который не прослушивается службой отладки. Попробуем временно отключить IPv6 в свойствах сетевого адаптера на обеих сторонах.
Если в вашей проблемной базе активно используются расширения конфигурации, это может вносить дополнительные сложности. Модули расширений компилируются сервером отдельно, и отладчик иногда теряет связь между исходным кодом в Конфигураторе и исполняемым кодом в памяти rphost.
Рассмотрим вариант временного отключения расширений:
Для отладки фоновых заданий также важно, чтобы строка соединения в Конфигураторе и в параметрах базы на сервере совпадала до символа. Любое различие (например, использование IP вместо имени сервера) может привести к тому, что фоновое задание не будет «подцеплено» отладчиком. Используйте метод ЖдатьЗавершение или аналогичные приемы для отладки фоновых процессов в файловом режиме для локализации ошибок в самом коде.
В сложных случаях, когда стандартные диалоги не помогают, можно принудительно задать параметры отладки через файл конфигурации. Создадим текстовый файл debugcfg.xml в каталоге bin\conf сервера 1С.
Разберем пример содержания этого файла:
<config xmlns="http://v8.1c.ru/7.4/config/debugconfig">
<debugProtocol>tcp</debugProtocol>
<address>192.168.1.100</address>
</config>
В этом примере мы жестко указываем протокол и IP-адрес, который сервер должен использовать для поиска отладчика. Это помогает в сетях с несколькими сетевыми интерфейсами или сложной маршрутизацией.
Подводя итог, можно сказать: если отладка не работает в одной базе при работающих остальных — в 90% случаев это либо кэш конкретной базы на сервере, либо баг платформы, требующий ручного переподключения предметов отладки. Переход на HTTP-протокол является наиболее долгосрочным и надежным решением, избавляющим от большинства перечисленных проблем.