gifts2017

Зависание терминальной сессии после выхода из 1С

Опубликовал Евгений (Berrimor) в раздел Администрирование - Системное

Предлагаю решение для "подвисающих" терминальных сессий.

При запуске прикладной программы (ПП) в момент подключения к удаленному рабочему столу (для нас скорее всего 1С), случается что по завершении ПП, терминальная сессия "зависает" на сервере (на стороне клиента выглядит как незакрытое окно подключения к удаленному рабочему столу с пустым рабочим столом, у меня такое случилось на сервере Win 2008R2 x64). После анализа выяснилось, что в моем случае, незакрытым остается процесс SplWOW64.exe, но предлагаемое решение подходит для любых привордящих к "подвисанию" приложений в терминальной сессии. 

 

1. Запускаем на сервере TaskMgr. переходим на закладку "Процессы" устанавливаем галку "Отображать процессы всех пользователей" нажимаем в заголовке таблицы на название колонки "Пользователи" (для сортировки процессов по пользователям) методом научного тыка находим проблемный процесс (закрываем по очереди и наблюдаем раекцию - после убивания процесса отключился пользователь? ОНО!)

1. Запускаем на сервере RegEdit

2. Ищем ветку "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\SysProcs

3. Добавить парметр DWORD: ИМЯ_НЕУБИВАЕМОЙ_ПРОГРАММЫ (в моем случае SPLWOW64.EXE) со значением 0


Для всего вышеописанного на сервере должны быть права админа.

См. также

Подписаться Добавить вознаграждение
Комментарии
1. al petrov (petrov_al) 19.05.14 09:43
Спасибо, есть такая проблема у меня то же, но хотелось бы докопаться до истинной причины...
2. Юрий Гончарук (yukon) 19.05.14 13:46
Это вольный перевод Remote Desktop or RemoteApp session does not terminate due to spawned splwow64.exe process http://support.microsoft.com/kb/2513330/ru?

Симптомы и лечения есть, а причины нет. Продолжим вольности:
The specified program may have spawned a new process. As part of the Remote Desktop session termination logic, if the specified program spawns a new process that new process is considered part of the program and the session will not terminate until that process also terminates.

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

One scenario that meets this criteria is printing from a 32-bit application on a 64-bit Remote Desktop Session Host. This printing action will spawn splwow64.exe, the 32-bit to 64-bit thunking process for spooler. Splwow64.exe has a 3 minute timeout to prevent the process from being repeatedly re-spawned during heavy printing, so it does not immediately exit when printing is complete. This can cause the remote session to to appear "hung" with a blank background.

Одним из наиболее распространенных случаев является печать из 32-битного приложения (клиент 1С для windows все еще только 32-битный) на 64-битной системе. В этом случае запускается процесс splwow64.exe - программная прокладка между 32- и 64-битной подсистемами печати. Указанный процесс имеет 3-х минутный таймаут перед закрытием - защита от постоянного перезапуска при массовой печати документов. Собственно этот таймаут и приводит к видимости "зависания".

Ну и решение:
You can add the splwow64.exe process to the following registry key to tell the operating system that the process may be safely terminated automatically

Можно добавить указанный процесс в список программ которые операционная система может завершить автоматически.
LexSeIch; mdzen; nixel; vdolynsky; Татьяна_69; +5 Ответить 2
3. Сергей Иванов (xten) 19.05.14 14:58
4. Алексей Коробов (olesha) 21.05.14 09:57
Проблема распространенная, спасибо!
5. sal salamanov (Salaman) 21.05.14 10:29
(2) yukon,
от этого могут появляться дублирующие учетные записи пользователя RDP ?
пользователь пользователь сидит в базе как будто он зашел с разных компов (тоесть профиль остается в 1с). хотя божатся что выходили :(
это непостоянно происходит, но изрядно достает :(
6. Александр (AlexInqMetal) 21.05.14 10:47
(5) Salaman, когда пользователь отображается сидящим в 1с, в диспетчере висит его профиль или отдельные процессы?
7. Евгений (Berrimor) 21.05.14 11:51
(5) Salaman, запрет создания пользователями более одного удаленного сеанса http://technet.microsoft.com/ru-ru/library/cc787315(v=ws.10).aspx
8. sal salamanov (Salaman) 22.05.14 13:53
(6) AlexInqMetal,
там файловый режим запуска 1с. под пользователем в диспетчере задач появляется 2-а запущенных процесса !!??
хотя программа запускалась 1-ин раз .....
Server 2012 r2 standart
9. sal salamanov (Salaman) 22.05.14 13:59
(7) Berrimor,
если я правильно понял , то кода пользователь зашел с другого компа под собой то прежняя сессия на 1-ом компе закрывается. Так ? (то есть юзер не может одновременно открывать несколько сессий)
У меня эти настройки используются дабы не плодить дубляжей....
10. sal salamanov (Salaman) 22.05.14 14:01
может есть механизм корректно закрыть 1с в автомате если нет обращения более 24 часов...???
11. Евгений (Berrimor) 22.05.14 14:26
(9) Salaman, нет, в том случае когда он подключается с другого компа, то соединяется со старой сессией
(10) Salaman, Настройка параметров времени ожидания и повторного подключения для сеансов служб удаленных рабочих столов http://technet.microsoft.com/ru-ru/library/cc754272.aspx
12. Евгений (Berrimor) 22.05.14 14:50
(10) это еще небольшой совет - часто пользователи просят отключить экранную заставку в терминальных сессиях, см. http://forum.oszone.net/thread-103331.html
13. Александр Федоров (Sasha255n) 23.05.14 14:19
А что простым обычным способом нельзя закрыть процеесс кторый приводит к подвисанию?
14. Евгений (Berrimor) 23.05.14 15:48
(13) Можно конечно :) если пользователей три калеки, а если 50?
15. Дмитрий Дрейцер (MadDAD) 27.05.14 16:26
ПиАрнусь немного. Автоматизированный костыль - http://infostart.ru/public/248792/ Разрабатывал эту штуку специально для таких случаев. У нас на SPLWOW64 все не закончилось.
16. Neman Entorin (ne_en) 22.06.15 22:56
(2) yukon, У меня печать производится не через средства мелкомягких, поэтому этот процесс не застревает. Но застревают другие: rdpshell.exe и rdpinit.exe. Их вышибание приводит к завершению сеанса. Однако имеются опасения относительно безопасности добавления этих процессов в такой список. Потому как в случае нарушения работы RDP на сервере, он станет недоступен, потому как размещён очень далеко даже за пределами страны. Требуется подсказка знающего человека. Безопасно ли это? Не потеряю ли я сервер на долго? (пока не получится в него влезть не через RDP)