App-V 虛擬化應用程序的奇怪行為 - 在所有其他實例關閉之前無法啟動新實例
我首先必須為這種含糊之處道歉。很難確定，這就是我轉向發布此內容的原因。
環境是 Windows 2012 R2 Citrix 7.16 伺服器，多租戶（這是使用 App-V 的原因）。
首先是關於應用程序的一些事情。
- 該應用程序在最新的 App-V 5.1 中排序。
- 應用程序在排序期間在網路共享上註冊一個 exe 文件。
- 應用程序客戶端部分主要包括註冊此文件。客戶端上沒有本地文件。
- 共享是讀取/執行（共享和 NTFS 權限）
- 該應用程序執行良好，直到大約 6 個月前的一段時間。然後所有新包都會表現出這種行為。
- 當應用程序未在 App-V 中虛擬化時不會發生。
關於它如何表現的一點：
- 該錯誤總是在正常工作時間之後發生，主要是在幾個小時之後。（我們的工作理論是，可能在使用者註銷/空閒會話自動註銷或會話重新連接期間觸發此事件。）
- 該錯誤本質上是使用者無法啟動應用程序。沒發生什麼事。
- 很容易發現此錯誤，因為在任務管理器中，所有受影響的應用程序實例都沒有圖示。就像任務管理器無法訪問/讀取資源一樣，但是我們已經測試了訪問權限並且文件和共享是“開放的”。
- 如果我們然後繼續殺死應用程序的所有實例，那麼使用者可以再次啟動應用程序。
- 也許相關的是包中還有其他可以執行的應用程序。所以虛擬環境並沒有為所有使用者關閉，包一直在“使用中”。
- 這篇 technet 文章可能是相關的 - 也許這與記憶體文件的共享資源有關。但非常重要：當應用程序未在 App-V 中虛擬化時，不會發生這種情況。
我們將嘗試關閉所有因此問題而與不同租戶空閒/斷開連接的會話，看看是否有幫助，但這仍然不是一個很好的解決方案。
除此之外，我只是希望某個地方的某個人經歷過類似的事情並找到根本原因，或者希望某個更聰明、更了解這裡使用的核心技術的人也許可以理解正在發生的事情，或者給我一些關於我們能做什麼的想法接下來試試。
我們今天在appv事件日誌中發現了一些錯誤資訊（錯誤0x7A602510-0xF），導致了這個死胡同。
昨天嘗試積極註銷使用者以消除會話重新連接的問題。沒運氣。只有兩個使用者登錄並處於活動狀態，第三個使用者觸發了錯誤，沒有重新連接，沒有其他斷開/空閒會話。
這個ars-thread 看起來是迄今為止我見過的最生動、最相關的一個（感謝@TrententTye！）。將嘗試以幾種不同的方式訪問應用程序文件，FQDN，IP，也許是映射驅動器。使用者 kttii 還寫道，Win2016 可能已經為他們解決了這個問題。最後提到了 2017 年 5 月的一些 WannaCry 更新檔，它們實際上與我們開始收到錯誤的時間非常吻合。
非常感謝所有在推特上轉發和貢獻的人！你們很棒。
編輯：發現錯誤資訊和 technet 死胡同。
編輯2 ：@TrententTye貢獻了這個看起來是同一個問題的ars-thread 。從 2010/Win2003 持續到 2017/Win2012！
我自己回答這個問題，因為我們發現了這個錯誤，我做了一個解決方法。
這是錯誤，我們現在知道：https: //support.microsoft.com/en-us/help/2536487/applications-crash-or-become-unresponsive-if-another-user-logs-off-ar 它在不使用 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 小時後釋放句柄。該腳本僅鎖定第一個文件夾中的文件。在 Get-Childitem 後面添加一個“-recurse”以遞歸遍歷所有文件夾。
現在這對我們來說效果很好。正如 KB 所述，我還可以確認它不會在 Server 2016 上發生。我希望這有幫助