← На главную

Часто разработчики сталкиваются с ситуацией, когда, несмотря на правильно установленную точку останова в серверной процедуре, например ПриСозданииНаСервере, отладчик ее игнорирует. Особенно актуальна эта проблема в сложных конфигурациях, таких как 1С:ERP, при работе в клиент-серверном варианте. При этом в файловой версии базы отладка может работать корректно, что добавляет путаницы. Чтобы упростить процесс подготовки среды и не настраивать всё вручную каждый раз, некоторые разработчики используют Помощник отладки, который автоматизирует рутинные действия.

Рассмотрим по шагам основные причины такого поведения и методы диагностики, которые помогут найти и устранить проблему.

Шаг 1. Базовые проверки и настройки отладки

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

1. Включена ли отладка на сервере 1С?
   Для работы отладчика в клиент-серверном режиме недостаточно запустить его в конфигураторе. Правильная настройка отладки на сервере 1С:Предприятие подразумевает, что служба «Агент сервера 1С:Предприятие» должна быть запущена со специальным ключом -debug.

   Как проверить и включить:

   • Откройте на сервере редактор реестра (regedit).
   • Перейдите в ветку, соответствующую вашей версии платформы, например: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent.
   • Найдите параметр ImagePath. Его значение должно содержать путь к файлу ragent.exe with параметрами. Убедитесь, что среди них есть ключ -debug.
   • Если ключа нет, добавьте его. Пример строки: "C:\Program Files\1cv8\8.3.20.1234\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug.
   • Важно: после изменения этого параметра необходимо перезапустить службу «Агент сервера 1С:Предприятие».
2. Проверка привязки события к обработчику
   Убедимся, что процедура, в которой стоит точка останова, действительно назначена обработчиком нужного события.

   Как проверить:

   • Откройте нужную форму в конфигураторе.
   • Нажмите правой кнопкой мыши на корневой элемент формы в дереве элементов и выберите «Свойства».
   • Перейдите на вкладку «События».
   • Найдите событие ПриСозданииНаСервере и проверьте, какая процедура указана в качестве обработчика. Возможно, там указана другая процедура или не указана никакая.
3. Очистка кэша
   Поврежденный или устаревший кэш — классическая причина необъяснимого поведения платформы. Система может выполнять старый, закэшированный код, в котором точка останова отсутствует. Очистка локального и серверного кэша и перезапуск сервера часто помогают решить проблему.

Шаг 2. Анализ кода и устаревших объектов

В типовых конфигурациях, особенно в 1С:ERP, часто происходит рефакторинг и развитие подсистем. Старые объекты помечаются как устаревшие, а их функциональность переносится в новые. Рефакторинг в 1С:ERP и переход на новые версии объектов (2.2, 2.4, 2.5) может быть причиной, по которой ваш код в устаревших процедурах больше не выполняется. В процессе обновления и переноса кода полезным инструментом станет Объединение модулей в разрезе методов, помогающее корректно сопоставлять изменения.

Обратим внимание на комментарии в коде. Если вы видите пометку вида //++ Устарело_Производство21, это прямой намек на то, что логика была изменена. В данном случае, вероятно, вместо документа ЗаказНаПроизводство теперь используется ЗаказНаПроизводство2_2 или другой связанный объект.

Что делать в такой ситуации:

1. Изучите конфигурацию на предмет наличия новых, более актуальных объектов. Поиск по имени с добавлением суффиксов "2_2", "2_5" и т.п. часто дает результат.
2. Проверьте, какая форма на самом деле открывается в режиме предприятия. Чтобы узнать имя активной формы, нажмите в правом верхнем углу окна кнопку «Сервис и настройки» (меню с тремя точками) → «Информация для технического специалиста». В открывшемся окне будет указано полное имя формы, например: Документ.ЗаказНаПроизводство2_2.Форма.ФормаСписка. Это поможет убедиться, что вы ставите точку останова в правильном месте.

Шаг 3. Использование Замера производительности для трассировки вызовов

Если прямая отладка не работает, на помощь приходит мощный инструмент — Замер производительности как инструмент диагностики логических ошибок. Он позволяет записать точную последовательность всех выполняемых процедур и функций, даже если отладчик в них не останавливается.

Разберем по шагам, как его использовать для диагностики:

1. В конфигураторе перейдите в меню «Отладка» → «Замер производительности...» или нажмите на иконку с часами на панели инструментов.
2. В открывшемся окне нажмите «Выполнить замер производительности на сервере».
3. Переключитесь в режим «1С:Предприятие».
4. Выполните действие, которое должно было привести к остановке на точке останова (например, откройте список документов «Заказ на производство»).
5. Сразу после этого вернитесь в конфигуратор и нажмите «Остановить замер».
6. Проанализируйте полученный отчет. Вы увидите дерево вызовов всех серверных процедур, которые были выполнены. Внимательно изучите его, чтобы понять, какая форма на самом деле создавалась и какие ее обработчики вызывались. Это даст точный ответ, почему ваша процедура ПриСозданииНаСервере не была задействована.

Шаг 4. Проверка влияния расширений конфигурации

Это одна из самых частых причин проблем с отладкой в современных конфигурациях. Расширения могут активно вмешиваться в выполнение стандартного кода, и это может полностью изменить логику работы системы. Особенности отладки кода в расширениях заключаются в использовании различных аннотаций, и, как выяснилось в обсуждаемой теме на форуме, именно некорректно работающее расширение было корнем проблемы. Для выявления конфликтов и ошибок в таких случаях рекомендуется выполнить Анализ конфигураций и расширений.

Как расширения могут мешать отладке:

• Перехват вызова с помощью аннотации @Вместо. Расширение может полностью заместить стандартную процедуру. Если в коде расширения не будет строки ПродолжитьВызов(...), то код из основной конфигурации, где стоит ваша точка останова, никогда не будет выполнен.
• Перехват вызова с помощью аннотаций @Перед и @После. Ошибки в коде этих обработчиков могут приводить к исключениям, из-за которых выполнение до основной процедуры просто не доходит.
• Конфликты между несколькими расширениями. Если два расширения пытаются изменить одну и ту же процедуру, результат может быть непредсказуемым.

Как диагностировать проблемы с расширениями:

1. В конфигураторе откройте список расширений («Конфигурация» → «Расширения конфигурации»).
2. Снимите галочки со всех расширений, которые могут относиться к изменяемому объекту (документу, его форме). Если расширений или патчей слишком много, можно использовать Универсальное удаление расширений для быстрой очистки системы от лишних исправлений.
3. Обновите конфигурацию базы данных (F7).
4. Повторите попытку отладки. Если точка останова сработала, значит, проблема точно в одном из отключенных расширений.
5. Включайте расширения по одному и повторяйте проверку, чтобы найти то, которое вызывает проблему.

В итоге, следуя этому алгоритму, вы сможете системно подойти к проблеме и найти причину, по которой отладчик не останавливается на серверной процедуре. Чаще всего решение кроется либо в настройках сервера, либо в логике, измененной обновлением конфигурации или некорректной работой расширения.