Разберем ситуацию, с которой часто сталкиваются разработчики при работе с современными конфигурациями на платформе 1С:Предприятие 8.3. Представим, что у нас файловая информационная база (например, «Бухгалтерия предприятия 3.0 КОРП»), включена отладка по протоколу HTTP, запущен процесс dbgs, и в списке «Подключенные предметы отладки» мы видим наш клиент. Однако при попытке отладить серверную процедуру или модуль объекта (например, ПередЗаписью документа или формирование отчета по Гособоронзаказу), конфигуратор игнорирует точки останова. При этом обычная команда Сообщить() выводит текст, подтверждая, что код выполняется.
Рассмотрим по шагам причины такого поведения и проанализируем технические нюансы настройки окружения, которые позволят восстановить работоспособность отладчика.
Одной из самых частых причин, по которой отладчик «видит» клиентское приложение, но игнорирует серверные вызовы, является отсутствие настройки автоматического подключения. В файловом варианте клиентское приложение само эмулирует работу сервера, но для системы отладки это разные контексты исполнения.
Выясним, как правильно настроить подключение:
Без этих флажков конфигуратор не будет автоматически перехватывать управление, когда выполнение кода переходит из клиентского контекста (&НаКлиенте) в серверный (&НаСервере, модули объектов, общие модули с флагом «Сервер»).
Современные версии платформы по умолчанию предлагают использовать протокол HTTP для отладки. Рассмотрим подробнее, какие проблемы это может создать в файловом режиме.
Проанализируем работу службы отладки. Процесс dbgs.exe выступает посредником между конфигуратором и предметом отладки. Если используется HTTP, критически важно, чтобы порты (по умолчанию 1560 и выше) были доступны. Даже если брандмауэр Windows отключен, проблема может крыться в настройках IPv6.
Иногда сервер отладки dbgs начинает слушать адрес ::1 (IPv6 loopback), в то время как конфигуратор пытается достучаться до него по 127.0.0.1 (IPv4). В такой ситуации предметы отладки могут отображаться в списке, но управление ими будет невозможным. В качестве эксперимента попробуем временно отключить протокол IPv6 в свойствах сетевого адаптера или принудительно запустить отладку по старому протоколу TCP, убрав соответствующие параметры запуска в настройках конфигуратора.
Если задача стоит в отладке сложного отчета (например, отчет по исполнению ГОЗ), нужно учитывать, что в современных конфигурациях на базе БСП (Библиотеки стандартных подсистем) отчеты часто формируются в фоновом задании. Это делается для того, чтобы интерфейс программы не «зависал» во время длительных вычислений.
В файловой базе фоновое задание запускается в отдельном потоке. Чтобы отладчик смог «поймать» этот процесс, выполним следующие действия:
Если все настройки верны, но точка останова все равно игнорируется, применим метод «от противного». Это поможет нам понять, видит ли конфигуратор серверный контекст в принципе.
Проанализируем ситуацию: мы вставим в код заведомую ошибку. Например, перед интересующим нас участком кода напишем:
// Принудительное деление на ноль для проверки отладчика
ЧислоНоль = 0;
Результат = 100 / ЧислоНоль;
Затем в конфигураторе в меню Отладка выберем пункт Остановка по ошибке и установим флаг «Останавливаться по ошибке». Если при выполнении кода программа прервется на строке с делением на ноль и откроет конфигуратор — значит, связь с отладчиком установлена, и проблема заключается в некорректной привязке конкретной точки останова (например, из-за несовпадения версии конфигурации в базе и в конфигураторе).
Не стоит забывать и о «гигиенических» процедурах. Рассмотрим последовательность действий для очистки окружения:
dbgs.exe. Если в системе установлены разные версии платформы (например, 8.3.12 и 8.3.22), старый процесс отладки может блокировать порты для новой версии./Debug.Если вы пытаетесь отладить код, который находится в расширении, или код основной конфигурации, который перекрывается расширением, обратите внимание на свойства самого расширения. В дереве конфигурации вызовем свойства расширения и проверим, стоит ли флаг «Использовать основные параметры отладки». Также убедимся, что флаг «Защита от опасных действий» не блокирует работу механизмов интеграции.
Подводя итог, можно сказать, что отладка на сервере в файловой базе — это всегда комплексная проверка сетевых настроек (протоколы, порты), настроек подключения (автоматический захват фоновых заданий) и чистоты окружения (кэш и версии платформы). Последовательное выполнение описанных шагов в большинстве случаев позволяет успешно решить проблему и попасть в нужную точку останова.