Почему зависает RDP-клиент при закрытии 1С?

Терминальный сервер IBM

Хотелось бы рассказать о проблеме, с которой столкнулся совершенно недавно. Я понимаю, что эта проблема, наверное, не сильно экзотическая и с ней сталкивается чуть ли не каждый системный администратор, но тем не менее, я столкнулся с ней впервые. Настраивая новый терминальный сервер на свеженьком сервере я столкнулся с неприятным фактом – пользователь, работая с 1С 8.3 через терминальную сессию, закрывает клиента 1С и до бесконечности наблюдает синий экран. Получается, что при закрытии клиента 1С, терминальная сессия не закрывается, а просто напрочь зависает. Сессия завершается только по таймауту или после ручного сброса через учетку Администратора.

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


Хотелось бы сразу сказать, что кэш 1С был сброшен на клиенте, но это не решало проблемы.

Исходные данные проблемы

Есть терминальный сервер, на котором установлена операционная система Windows 2016 Server, 64-бита. Добавлена роль – терминальный сервер и создано несколько десятков однотипных учетных записей, которые обладают привилегиями Пользователь удаленного рабочего стола.

Все клиенты подключаются по протоколу RDP версии 7.0 с операционных систем Windows 10.

Вроде как стандартный набор для типовой, коммерческой организации, каких миллионы.

Поиски виновного

Создал себе нового пользователя удаленного рабочего стола, который бы никак не отличался от уже работающих с сервером и запустил 1С через удаленку. Пооткрывал документы и, как положено, закрыл 1С`ку. Сессия ожиданно повисла. Перелогинился под Администратором и полез в Диспетчер задач, чтобы посмотреть что же остается запущенным из процессов у страдающего пользователя.

Подозрения пали на странный процесс – splwow64.exe, который был запущен среди остальных нормальных процессов. Этот процесс был запущен у каждого пользователя, наверное, именно это и насторожило меня. Покопавшись в Интернетах, я понял, что:

splwow64.exe – это программная прослойка, которая позволяет 32-битным приложениям соединиться с 64-битным диспетчером службы очереди печати.

Многим покажется странным то, что этот процесс вызвал у меня подозрения. Все недоверчивые люди могут от имени Администратора последовательно позавершать все запущенные процессы пользователя, у которого зависла терминальная сессия. После завершения процесса splwow64.exe, сессия сама закроется, как ей и положено.

Получается что у пользователя, открывшего терминальную сессию, нет полномочий для завершения этого процесса. Экая, несправедливость…

Проблема найдена, осталось найти ее решение.

Решение

Ищем в системном реестре ветку с настройками терминального сервера [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]. Из всех параметров, нас интересует вложенная ветка SysProcs. Эта ветка служит для перечисления всех процессов и библиотек, которые нужно насильно отнести к пользовательским и дать возможность управлять ими самому пользователю.

По умолчанию эта ветка пустая. Создаем 32`ух битный dword-параметр с названием мучившего нас процесса – splwow64.exe. Можете еще накидать процессы, которые покажутся Вам странными.

Так как это ОС Windows, то не лишним будет перезагрузить сервер, хотя все должно работать и так.

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

Теги: и

Комментарии

Граватар пользователя «myr4ik07»
myr4ik07, 15 апреля 2013 г. 18:52 #

Так это баг или …? Решение в сети совпадают с вашими?
Решение интересное и добавлено в избранное. Спасибо.

Граватар пользователя «Mut@NT»
Mut@NT, 16 апреля 2013 г. 05:58 #

Скорее всего баг… По крайней мере я не вижу смысла делать этот процесс не подконтрольным терминальной сессии

Граватар пользователя «Muxa»
Muxa, 29 января 2014 г. 14:32 #

Друг, большое тебе спасибо. Выручил сильно !!!

Граватар пользователя «Бредман»
Бредман, 9 февраля 2014 г. 16:58 #

Спасибо, очень помогло!!

Граватар пользователя «Зюзгин Иван»
Зюзгин Иван, 9 февраля 2014 г. 19:20 #

Пожалуйста

Граватар пользователя «Зюзгин Иван»
Зюзгин Иван, 9 февраля 2014 г. 19:21 #

Рад, что смог помочь

Граватар пользователя «Вадим»
Вадим, 23 октября 2015 г. 15:41 #

а мне не помогает. в этой ветке есть параметр с указанным названием, но все равно виснет 2003-64 сервак после выхода юзеров. пришлось убрать кнопки логофф у всех и тупо закрывать окно.




В качестве аватарки используется сервис - gravatar.com



IT-событие
Создание Instagram
Создание Instagram
Оглавление
  1. Исходные данные проблемы
  2. Поиски виновного
  3. Решение
  4. Комментарии