Точки останова в серверном коде не срабатывают: что проверить в кластере 1С
Содержание
Отладка на сервере 1С чаще всего не работает
потому, что агент сервера ragent.exe запущен без ключа -debug. Пока этого ключа нет в строке запуска службы, Конфигуратор не видит серверные предметы отладки, а точки останова в процедурах &НаСервере молча пропускаются.
Если ключ на месте, а отладчик всё равно не подключается, причина обычно в одном из пяти мест: протокол отладки в Конфигураторе не совпадает с режимом сервера, закрыты порты, у пользователя нет прав на Конфигуратор, версии платформы на клиенте и сервере разные или не включено автоматическое подключение нужных предметов. Ниже — проверки в том порядке, в котором их удобнее делать.
Запущен ли сервер 1С в режиме отладки
Первое, что нужно проверить, — параметры запуска службы агента сервера. Режим отладки включается только при старте агента, «на лету» его не включить.
Как посмотреть текущую строку запуска
На сервере Windows откройте PowerShell от администратора и выполните:
Get-CimInstance Win32_Process -Filter "name='ragent.exe'" | Select-Object CommandLine
В выводе должна быть строка примерно такого вида:
"C:\Program Files\1cv8\8.3.24.1548\bin\ragent.exe" -debug -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"
Номер платформы и пути у вас будут свои. Главное — наличие -debug.
Как добавить ключ -debug в Windows
- Откройте
regeditи перейдите вHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. - Найдите раздел службы агента сервера 1С. Его имя видно в оснастке
services.msc, в свойствах службы, в поле «Имя службы». - Откройте параметр
ImagePathи допишьте-debugсразу после пути кragent.exe. - Если нужна отладка по HTTP, допишьте
-debug -http. Для TCP достаточно-debug(TCP используется по умолчанию). - Перезапустите службу агента.
Перезапуск службы агента обрывает все сеансы пользователей на этом сервере. Делайте это вне рабочего времени или после предупреждения пользователей. На рабочем продуктивном сервере режим отладки лучше вообще не держать включённым постоянно: он добавляет нагрузку.
Сервер на Linux
В старых сборках платформы параметры службы задавались в файле /etc/sysconfig/srv1cv83 переменной SRV1CV8_DEBUG=1. В новых версиях 8.3 служба запускается через systemd: ключ -debug добавляют в строку ExecStart юнита агента через systemctl edit, затем выполняют systemctl daemon-reload и перезапускают службу. Проверка та же: ps aux | grep ragent должен показать -debug в командной строке.
💡 После перезапуска ещё раз выполните команду проверки. Частая ситуация: правку внесли в службу другой версии платформы, а работает агент соседней версии, установленной на том же сервере.
Протокол отладки: TCP или HTTP
У платформы 8.3 два механизма отладки. Сервер и Конфигуратор должны работать по одному и тому же.
| Протокол | Ключ агента | Как работает | Когда выбирать |
|---|---|---|---|
| TCP/IP | -debug или -debug -tcp | Отладчик подключается к предметам отладки напрямую | Небольшая сеть, сервер и ПК разработчика в одном сегменте |
| HTTP | -debug -http | Предметы отладки подключаются к серверу отладки dbgs.exe | Отладка через межсетевые экраны, работа в EDT, удалённые серверы |
В Конфигураторе протокол выбирается в Сервис → Параметры → Отладка. Если сервер запущен с -debug -http, а в Конфигураторе выбран TCP/IP, серверные предметы отладки просто не появятся. И наоборот.
После смены протокола в параметрах перезапустите Конфигуратор: настройка применяется к новому сеансу.
Для отладки по HTTP Конфигуратор сам запускает сервер отладки dbgs.exe на компьютере разработчика. Его версия совпадает с версией Конфигуратора. Если в диспетчере задач висит dbgs.exe от другой версии платформы, завершите его и перезапустите Конфигуратор.
Подключение предметов отладки в Конфигураторе
Сервер запущен с -debug, протокол совпадает, но точки останова не срабатывают. Тогда смотрите, подключён ли вообще серверный предмет отладки.
Ручная проверка
- Запустите отладку из Конфигуратора (
F5). Клиент, запущенный так, уже стартует в режиме отладки. - В клиенте выполните действие, которое вызывает серверный код: откройте форму, проведите документ.
- В Конфигураторе откройте
Отладка → Подключение. В списке должны быть клиентский и серверный предметы отладки этой базы. - Если серверный предмет есть, но не подключён, выделите его и нажмите «Подключить».
Автоматическое подключение
В том же окне есть кнопка автоматического подключения. В её настройках отметьте типы предметов, которые нужно ловить: сервер, фоновые задания, HTTP-сервисы, веб-сервисы. Без отметки серверного типа отладчик будет останавливаться только в клиентском коде.
Ещё несколько причин, которые выглядят как «отладка на сервере не работает», но к серверу отношения не имеют:
- 🔹 точка останова стоит в процедуре
&НаКлиенте, а не&НаСервере; - 🔹 код выполняется в фоновом задании, а этот тип не отмечен в автоподключении;
- 🔹 вызов идёт в другую базу кластера: Конфигуратор открыт не на ту информационную базу;
- 🔹 модуль изменён, но конфигурация не сохранена и не обновлена — сервер выполняет старую версию кода;
- 🔹 клиент запущен ярлыком без ключа
/DEBUG, а не из Конфигуратора.
Если клиент нужно запускать отдельно, добавьте /DEBUG в поле дополнительных параметров запуска в свойствах базы в окне запуска 1С.
Права пользователя и учётная запись службы
Отладку запускают из Конфигуратора, поэтому пользователю нужен доступ к нему. В типовых конфигурациях это роль с правом «Администрирование», обычно — «Полные права». Без неё Конфигуратор не откроется вовсе, и до отладки дело не дойдёт.
Отдельного права «на отладку» в ролях конфигурации нет. Если Конфигуратор открывается, а серверный предмет отладки не виден, проблема не в ролях — ищите её в режиме сервера, протоколе или сети.
Учётная запись службы 1С
Агент и рабочие процессы работают от имени служебной учётной записи (часто USR1CV8). Для отладки по TCP рабочему процессу нужно принимать входящие соединения, для HTTP — самому подключаться к компьютеру разработчика. Если служба работает от учётной записи с урезанными сетевыми правами или политиками безопасности домена, соединение может блокироваться.
Проверить это просто: временно запустите службу от локальной учётной записи с правами администратора на тестовом сервере. Заработало — значит, дело в правах служебной учётной записи.
Расширения и безопасный режим
Код расширения конфигурации
отлаживается так же, как основной, но точки останова ставятся в модулях самого расширения. Открывается оно в Конфигураторе через Конфигурация → Расширения конфигурации. Если точка поставлена в основной конфигурации, а метод перехвачен расширением, отладчик остановится только там, где код реально выполняется.
Лицензии и ключи защиты при отладке
Сам режим отладки отдельной лицензии не требует. Но клиентский сеанс, который запускается для отладки, занимает клиентскую лицензию так же, как обычный сеанс пользователя.
Типичные ситуации:
- 🔑 все клиентские лицензии заняты — отладочный клиент не стартует, хотя Конфигуратор открыт. Освободите лицензию: попросите кого-то выйти или завершите зависший сеанс в консоли кластера;
- 🔑 на сервере нет лицензии сервера 1С — кластер не обслуживает базы, и проблема не в отладке;
- 🔑 программный ключ привязан к параметрам компьютера, которые поменялись (замена сетевой карты, перенос виртуальной машины) — лицензия слетает, сеансы не создаются.
Посмотреть, какие сеансы держат лицензии, можно в консоли администрирования кластера в списке сеансов базы. Из командной строки — через rac session list --licenses (сначала узнайте идентификатор кластера командой rac cluster list).
Перед тем как завершать чужой сеанс, убедитесь, что пользователь не проводит документы или не загружает данные: несохранённые изменения пропадут.
Брандмауэр и сетевые порты для отладки на сервере
Сетевые проблемы — вторая по частоте причина после отсутствия -debug. Вспомним, как ходят соединения в клиент-серверной 1С: клиент обращается к агенту (порт 1540), затем к менеджеру кластера (1541) и к рабочим процессам. Диапазон портов рабочих процессов задаётся в свойствах рабочего сервера, по умолчанию 1560:1591.
Что открыть
| Направление | Порты по умолчанию | Зачем |
|---|---|---|
| ПК разработчика → сервер | 1540, 1541 | Агент и менеджер кластера |
| ПК разработчика → сервер | 1560–1591 (диапазон рабочего сервера) | Рабочие процессы, отладка по TCP |
| Сервер → ПК разработчика | 1550 | Сервер отладки dbgs.exe при отладке по HTTP |
Последняя строка — то, о чём забывают чаще всего. При HTTP-отладке соединение идёт в обратную сторону: серверный предмет отладки сам стучится на компьютер разработчика. Брандмауэр Windows на ПК разработчика по умолчанию такое соединение не пропустит.
Правило для входящего соединения на компьютере разработчика можно создать так (PowerShell от администратора):
New-NetFirewallRule -DisplayName "1C debug server" -Direction Inbound -Protocol TCP -LocalPort 1550 -Action Allow
Имена компьютеров
Отладчик и предметы отладки находят друг друга по имени компьютера. Если сервер не может разрешить имя ПК разработчика (другой домен, VPN, нет записи в DNS), подключение не состоится, хотя порты открыты.
Проверьте с сервера ping <имя ПК разработчика>. Не отвечает по имени — добавьте запись в DNS или в файл C:\Windows\System32\drivers\etc\hosts на сервере.
Версии платформы на клиенте и сервере
Конфигуратор и сервер 1С должны быть одной и той же версии — с точностью до номера сборки. Если на сервере 8.3.24.1548, клиент тоже нужен 8.3.24.1548. При расхождении Конфигуратор просто не подключится к базе с ошибкой о несоответствии версий.
Хитрость в том, что на ПК разработчика часто стоят несколько платформ. Окно запуска 1С может открывать базу не той версией, которую вы ожидаете.
- В окне запуска выделите базу и нажмите «Изменить».
- На последнем шаге в поле версии 1С:Предприятия укажите точный номер, совпадающий с сервером.
- Сохраните и запускайте Конфигуратор заново.
При HTTP-отладке есть ещё один уровень: версия dbgs.exe совпадает с версией Конфигуратора, который его запустил. Если вы открыли две базы разными платформами, могут запуститься два сервера отладки, и предметы отладки подключатся не к тому.
Для отладки в 1С:EDT требуется HTTP-механизм — по TCP среда разработки к серверу не подключается. Сервер для EDT запускают с -debug -http.
Технологический журнал и журнал регистрации
Если по всем пунктам выше порядок, а отладка не работает, ищите след ошибки в журналах.
Журнал событий Windows
Начните с простого: eventvwr.msc → «Журналы Windows» → «Приложение». Здесь видны ошибки запуска службы агента, например, если после правки ImagePath строка запуска оказалась с лишней кавычкой и служба не стартует.
Журнал регистрации базы
В Конфигураторе: Администрирование → Журнал регистрации. Отберите события по своему пользователю и времени попытки отладки. Здесь видны ошибки выполнения серверного кода, но сетевые проблемы отладчика сюда обычно не попадают.
Технологический журнал
Самый информативный источник. Создайте файл logcfg.xml в каталоге conf платформы (например, C:\Program Files\1cv8\conf\) со сбором исключений:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\1C_logs" history="24">
<event>
<eq property="name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
Платформа подхватывает файл без перезапуска службы, обычно в течение минуты. Повторите попытку отладки и посмотрите файлы в C:\1C_logs в подпапках процессов rphost и ragent. Строки с событием EXCP в момент подключения отладчика покажут, на чём срывается соединение.
Не оставляйте технологический журнал включённым надолго, особенно со свойством all: на нагруженном сервере каталог растёт на гигабайты за часы. После диагностики удалите или переименуйте logcfg.xml.
Частые вопросы
Можно ли включить отладку на сервере без перезапуска службы?
-debug читается только при старте агента, поэтому службу придётся перезапустить, а сеансы пользователей оборвутся.Опасно ли держать продуктивный сервер в режиме отладки?
Почему файловая база отлаживается, а серверная копия — нет?
-debug у агента не нужен. В клиент-серверном варианте код выполняет рабочий процесс кластера, и режим отладки должен быть включён у службы.