Прежде всего, я должен извиниться за расплывчатость этого. Это довольно сложно определить, поэтому я решил опубликовать это.
Среда - это серверы Windows 2012 R2 Citrix 7.16, мультитенантные (что является причиной использования App-V).
Сначала несколько слов о приложении.
Немного о том, как это проявляется:
Ошибка всегда возникает в нерабочее время, в основном через несколько часов. (Наша рабочая теория заключается в том, что, возможно, что-то во время выхода пользователя из системы / автоматического выхода из системы в режиме ожидания или повторного подключения сеанса вызывает это.)
Ошибка заключается в том, что пользователи не могут запустить приложение. Ничего не произошло.
Эту ошибку легко обнаружить, потому что в диспетчере задач все затронутые экземпляры приложения не имеют значков. Например, диспетчер задач не может получить доступ к ресурсу / прочитать его, однако мы проверили доступ, и файл и общий ресурс «открыты для бизнеса».
Если затем мы продолжим уничтожать все экземпляры приложения, пользователи смогут снова запустить приложения.
Возможно, важно то, что в пакетах есть другие приложения, которые могут быть запущены. Таким образом, виртуальная среда не была отключена для всех пользователей, и пакет «использовался» все время.
Эта статья в технике может быть актуальным - возможно, это связано с общим ресурсом кэшированного файла. Однако очень важно: этого не происходит, если приложение не виртуализировано в App-V.
Мы собираемся попытаться закрыть все сеансы, которые простаивают / отключены от разных клиентов с этой проблемой, и посмотреть, поможет ли это, но это все еще не очень хорошее решение.
Помимо этого, я просто надеюсь, что кто-то где-то испытал нечто подобное и нашел основную причину, или что кто-то более умный и знающий об основных используемых здесь технологиях, возможно, сможет понять, что происходит, или дать мне некоторые идеи относительно того, что мы можем попробуй дальше.
Сегодня мы обнаружили несколько сообщений об ошибках в журнале событий приложения (ошибка 0x7A602510-0xF), которые привели к этот тупик.
Вчера предпринял попытку активного выхода пользователей из системы, чтобы устранить проблемы с повторным подключением сеанса. Не повезло. Всего два пользователя вошли в систему и были активными, а третий вызвал ошибку, нет повторного подключения, нет других отключенных / бездействующих сеансов.
Этот ars-поток выглядит самым живым и актуальным из всех, что я когда-либо видел (спасибо @TrententTye!). Попробую получить доступ к файлу приложения несколькими способами: полное доменное имя, IP-адрес, возможно, подключенный диск. Также пользователь kttii пишет, что Win2016, возможно, устранил для них проблему. И, наконец, упоминаются некоторые патчи WannaCry от мая 2017 года, которые на самом деле очень хорошо совпадают с тем, когда мы начали получать ошибку.
Огромное спасибо всем, кто ретвитнул и внес свой вклад в твиттер! Вы, ребята, потрясающие.
изменить: найдено сообщение об ошибке и тупик.
edit2: @TrententTye способствовал эта арс-нить что похоже на ту же проблему. Переход с 2010 / Win2003 на 2017 / Win2012!
Я сам отвечаю на этот вопрос, поскольку мы нашли ошибку, и я решил ее исправить.
Это ошибка, теперь мы знаем: https://support.microsoft.com/en-us/help/2536487/applications-crash-or-become-unresponsive-if-another-user-logs-off-a-r Он также появлялся несколько раз, когда App-V не использовался, но в 98% случаев это происходило при виртуализации приложения.
Это обходной путь:
1 Создайте запланированную задачу на сервере RDS / Xenapp, на котором проявляется ошибка. Настройте его на запуск при загрузке или вскоре после этого. Он должен запускаться до того, как пользователи запустят приложение. Это запланированная задача:
Заявка: PowerShell.exe
Параметры: -command "& 'C:\Program Files (x86)\Script\ReadLockFilesInFolder.ps1' '\\server\folder\'"
2 Сохраните это как сценарий PowerShell:
$AllOfTheFiles = Get-childitem -Path $args[0] -File | Select-Object -ExpandProperty FullName
$fileLocks = @()
foreach ($afile in $AllOfTheFiles) {
$fileLocks+=[System.io.File]::Open("$afile",'Open','Read','Read')
}
Start-Sleep -s 86400
Сценарий работает, открывая файлы неэксклюзивно и удерживая магический первый дескриптор, предотвращая его освобождение.
Ноты:
Скрипт освобождает ручку через 24 часа. Сценарий блокирует файлы только в первой папке. Добавьте "-recurse" после Get-Childitem, чтобы просмотреть все папки.
Теперь это хорошо сработало для нас. Я также могу подтвердить, что этого не происходит на Server 2016, как описано в KB. надеюсь, это поможет