Почему режим «1С:Предприятие» долго запускается из Конфигуратора при включенной сети?

Довольно часто разработчики сталкиваются с ситуацией: при старте сеанса отладки по клавише F5 информационная база открывается больше минуты, но если отключить сетевой кабель или отключить сетевой адаптер, то запуск происходит практически мгновенно. При этом обычный запуск через список баз без отладки также работает штатно. Выясним причину такого поведения и подробно разберем по шагам, как локализовать и устранить эту проблему.

Анализ технологического журнала: в чем причина задержки

Для понимания происходящих процессов проанализируем записи технологического журнала 1С. В момент зависания в событиях CALL и SCALL (вызовы сервиса IRemoteCreatorService и метода createRemoteInstance) четко видны повторяющиеся временные задержки ровно по 15 секунд:

17:05.438001-1,CALL,1,process=1cv8,t:clientID=3,Interface=7f58f27d-5ad8-43a1-aa1e-c982f41bed5c,IName=IRemoteCreatorService,Method=0,CallID=18806,MName=createRemoteInstance
...
17:20.446000-0,EXCP,1,process=1CV8C,Usr=Иванов,Descr=InitializeSecurityContext: Error 80090311!

За несколько таких обращений суммарная задержка как раз превышает минуту. Ключевая зацепка здесь — системное событие исключения EXCP с описанием InitializeSecurityContext: Error 80090311!.

Разберем природу этой ошибки. Код 0x80090311 (системная константа SEC_E_NO_AUTHENTICATING_AUTHORITY) интерфейса безопасности Windows (SSPI) означает: «Не найден центр проверки подлинности» (No authority could be contacted for authentication).

Когда мы нажимаем F5, Конфигуратор и запускаемый толстый или тонкий клиент должны связаться между собой по протоколу отладки. Процессы 1С обращаются к системным механизмам Windows (SSPI / NTLM / Kerberos) для согласования аутентификации. Если рабочая станция находится в домене Active Directory (или учетная запись пользователя создана в домене), подсистема безопасности операционной системы пытается найти контроллер домена в сети. Если контроллер домена недоступен (например, разработчик работает из дома, без VPN или через сторонний маршрутизатор), каждый сетевой запрос ждет ответа ровно 15 секунд до наступления таймаута.

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

Способ 1. Привязка имени компьютера в файле hosts

Часто операционная система пытается разрешить локальное имя компьютера (например, в журнале фигурирует сетевое имя s002) через внешние DNS-серверы провайдера или локальной сети, тратя время на таймауты. Устраним эти задержки прямым сопоставлением локального имени в системе:

1. Запустим текстовый редактор от имени администратора.
2. Откроем файл конфигурации сетевых имен по пути C:\Windows\System32\drivers\etc\hosts.
3. Добавим в конец файла явное сопоставление сетевого имени машины с локальной петлей localhost:
   Скопировать код

   
   127.0.0.1  s002
   ::1        s002
   

   где вместо s002 укажем фактическое имя текущего компьютера.
4. Сохраним изменения в файле. Теперь системные службы не будут опрашивать внешнюю сеть для разрешения локального имени при междескрипторном взаимодействии Конфигуратора и клиента.

Способ 2. Проверка настроек домена и DNS-серверов

Проанализируем конфигурацию сетевого адаптера и доменной авторизации:

1. Если учетная запись Windows является доменной, а контроллер домена находится в корпоративной сети, настроим и включим стабильное подключение к корпоративной сети через рабочий VPN до начала работы в 1С.
2. Проверим сетевые настройки IPv4 активного адаптера: первым DNS-сервером должен быть указан контроллер домена, а не адрес домашнего роутера или публичные серверы (например, 8.8.8.8), иначе запросы проверки подлинности будут зависать.
3. Если использование домена на данном компьютере больше не требуется, переключимся на локальную учетную запись Windows, для которой системные проверки выполняются на локальной машине без обращения к контроллерам.

Способ 3. Отключение неиспользуемых протоколов сетевого подключения

Широковещательные запросы и зависания протоколов разрешения имен могут провоцироваться сетевыми надстройками Windows. Разберем шаги по их отключению:

1. Перейдем в окно подключений (нажав комбинацию Win + R и введя команду ncpa.cpl).
2. Откроем свойства используемого сетевого адаптера.
3. Если провайдер или локальная сеть не поддерживают IPv6, снимем галочку с компонента «Протокол Интернета версии 6 (TCP/IPv6)», чтобы исключить задержки перехода с IPv6 на IPv4 при сетевых вызовах.
4. Выделим «Протокол Интернета версии 4 (TCP/IPv4)», нажмем Свойства, затем Дополнительно.
5. На вкладке WINS переключим параметр в положение «Отключить NetBIOS через TCP/IP». Это предотвратит широковещательные попытки поиска локального узла через устаревший механизм NetBIOS.

Способ 4. Изменение протокола отладки в 1С

Начиная с платформы 8.3, разработчикам доступно два механизма взаимодействия Конфигуратора и предметов отладки: классический TCP/IP и современный HTTP. Механизм HTTP-отладки не полагается на доменную авторизацию Windows SSPI, а поднимает локальный легкий веб-сервис отладки.

1. В Конфигураторе перейдем в главное меню: Сервис → Параметры.
2. Перейдем на вкладку Отладка.
3. В параметрах протокола выберем вариант HTTP (если ранее был указан протокол TCP/IP). Если уже был активен HTTP, попробуем переключить на TCP/IP для проверки поведения.
4. Перезапустим Конфигуратор и проверим запуск по F5.

Способ 5. Подключение отладчика к уже запущенному сеансу

Если быстро скорректировать сетевые политики операционной системы невозможно, а работать требуется прямо сейчас, применим рабочий обходной сценарий:

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

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