Где моя отладка, чувак?

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

Теперь расскажу, как проходило расследование ситуации и последующая настройка сервера в моем случае. Для начала необходимо определить используемый на данный момент порт отладки. Это можно посмотреть в конфигураторе через меню "Отладка" - "Подключение" - "Настройка". В моем случае это было tcp://srv1c:1562.
Выполнение netstat -nao | find "1562" показало, что к порту отладки имеют отношение только мои процессы конфигуратора и клиента, запущенного на отладку. Запуск периодического опроса портов netstat -naot 1 | find "1562" с последующим запуском отладки выявил наличие состояний SYN_SENT, что означает, что клиент все таки пытается достучаться порта отладки.
После этого решил посмотреть, какие события пишет клиент во время запуска в технологический журнал. Поскольку мне неизвестно, какое событие будет содержать необходимую информацию, то я буду собирать все события с момента старта отладки до момента, пока SYS_SENT не прекратятся.

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\v8\client\logs" history="1">
        <event>
            <ne property="name" value=""/>
        </event>
        <property name="all">
        </property>
    </log>
</config>

Файл настроек журнала кладется в %UserProfile%\AppData\Local\1C\1cv8\conf, потому что мне нужны события только моих сеансов. После этого снова запускаем клиент на отладку и изучаем логи. В логе конфигуратора ничего интересного не оказалось. Из лога клиента целиком полученные данные приводить смысла нет, покажу только значимые события, связанные с сетевой активностью.

30:25.862000-0,EXCP,1,process=1cv8,ClientID=0,Exception=NetDataExchangeException,Descr='server_addr=any:1560 descr=10048(0x00002740): Обычно разрешается только одно использование адреса сокета (протокол/сетевой адрес/порт). line=261 file=src\DataExchangeServerImpl.cpp'
30:25.862003-0,EXCP,1,process=1cv8,ClientID=0,Exception=NetDataExchangeException,Descr='server_addr=any:1561 descr=10048(0x00002740): Обычно разрешается только одно использование адреса сокета (протокол/сетевой адрес/порт). line=261 file=src\DataExchangeServerImpl.cpp'
30:25.862006-0,EXCP,1,process=1cv8,ClientID=0,Exception=NetDataExchangeException,Descr='server_addr=any:1562 descr=10048(0x00002740): Обычно разрешается только одно использование адреса сокета (протокол/сетевой адрес/порт). line=261 file=src\DataExchangeServerImpl.cpp'
30:30.199000-0,EXCP,3,process=1cv8,Usr=Админ,ClientID=3,Exception=NetDataExchangeException,Descr='server_addr=tcp://127.0.0.1:1562 descr=127.0.0.1:1562:10060(0x0000274C): Попытка установить соединение была безуспешной, т.к. от другого компьютера за требуемое время не получен нужный отклик, или было разорвано уже установленное соединение из-за неверного отклика уже подключенного компьютера. ;
line=1043 file=src\DataExchangeTcpClientImpl.cpp'
30:34.208000-0,EXCP,3,process=1cv8,Usr=Админ,ClientID=4,Exception=NetDataExchangeException,Descr='server_addr=tcp://127.0.0.1:1562 descr=127.0.0.1:1562:10060(0x0000274C): Попытка установить соединение была безуспешной, т.к. от другого компьютера за требуемое время не получен нужный отклик, или было разорвано уже установленное соединение из-за неверного отклика уже подключенного компьютера. ;
line=1043 file=src\DataExchangeTcpClientImpl.cpp'

Коды ошибок сокетов можно посмотреть на MSDN. В моем случае ошибка 10048(0x00002740) является причиной, 10060(0x0000274C) - следствие. Проблема оказалась знакомой - неделю назад настраивал другой сервер, на котором периодически отваливались клиенты с такой же ошибкой.
Приступаем к настройке TCP протокола с помощью редактирования реестра (regedit), отсутствующие параметры в ветках необходимо создать руками:

MaxUserPort

При соединение по TCP/IP открывается сокет и выбирается динамический порт. По умолчанию, диапазон динамических портов от 1024 по 5000. Увеличиваем до максимума.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value: MaxUserPort
Data Type: REG_DWORD
Range: 5000 to 65534
Default value: 5000
Recommended value: 65534

TcpTimedWaitDelay

Когда соединение TCP закрывается, то сокет сразу не освобождается, а переходит в статус TIME_WAIT и ресурсы освободятся только через определённое время. По умолчанию, только через 4 минуты. Снизим это время до минимума - 30 секунд.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value: TcpTimedWaitDelay
Data Type: REG_DWORD
Range: 30 to 300
Default value: 240
Recommended value: 30

Так же отключим автотюнинг tcp протокола:
netsh int tcp set global autotuninglevel=disabled

Выполненный ping srv1c показал использование протокола tcp/ipv6. Если в нем явной необходимости нет, то рекомендуется его отключить. Одного отключения протокола в свойствах подключения недостаточно, нужно еще отключить компоненты.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
Value: DisabledComponents
Data Type: REG_DWORD
Value: 0xff

На некоторых сайтах можно встретить рекомендацию установить значение 0xfffffff. Данное
значение, согласно вышеуказанной статье от Microsoft, является некорректным и может привести к задержкам при загрузке системы (Additionally, system startup will be delayed for 5 seconds if IPv6 is disabled by incorrectly, setting the DisabledComponents registry setting to a value of 0xfffffff. The correct value should be 0xff).

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

Публикация на infostart.ru