主页 / server / 问题 / 895840
Accepted
Gomibushi
Asked: 2018-02-07 01:06:49 +0800 CST

App-V 虚拟化应用程序的奇怪行为 - 在所有其他实例关闭之前无法启动新实例

  • 772

我首先必须为这种含糊之处道歉。很难确定，这就是我转向发布此内容的原因。

环境是 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！

network-share

1 个回答

  1. Best Answer

    我自己回答这个问题，因为我们发现了这个错误，我做了一个解决方法。

    这是错误，我们现在知道：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 上发生。我希望这有帮助

    • 0

相关问题