问题标签 [windows-appcompat-platform]

由于显而易见的原因（写入程序文件以及默认情况下不再允许的其他内容），我正在处理一个与 Vista 存在问题的 vb6 应用程序。

• 我应该在哪里存储应用程序数据或用户保存的文件？
• 我也需要在那里创建文件夹和文件的权限吗？
• 还有哪些常见的操作会导致问题？
• 该程序有一个必须下载和注册文件的更新程序，发生这种情况时如何提升权限？

其中一些问题有明显的答案，但我想把明显的东西弄清楚。

我有一个产品设置可执行文件，可以将一些文件复制到用户的硬盘上。它不是一般意义上的典型安装程序（它不会向“开始”菜单或“程序文件”文件夹添加任何内容）。

每次在 Vista 上运行安装程序时，exe 终止后，Vista 都会生成一个任务对话框：

• 此程序可能未正确安装
• 使用推荐配置重新安装
• 这个程序正确地安装了

我需要从 exe 或注册表项中调用一个函数来设置，以向操作系统指示程序安装正确（或至少抑制此消息）？

相关问题： Windows 7 RC 中的“此程序可能未正确安装”消息（针对特定于 Windows 7 的问题）

我将我的可执行文件显示为需要管理员：

然后我对其进行了数字签名。

但是当我运行可执行文件时，我注意到一些奇怪的事情：同意对话框上的可执行文件的名称从更改PingWarning.exe为pinxxxx.tmp；好像制作了一个临时副本，并且正在运行：

我挖出了 Process Montior，看看是否有人在我启动我的可执行文件时创建了*.tmp文件，并且有：

此特定容器内的应用程序信息服务有意将我的可执行文件复制到 Windows 临时文件夹，并从那里请求用户“同意”；给出一个无效的文件名。svchost

一旦获得同意，可执行文件将从其原始位置运行：

如果我不对其进行数字签名，则该文件不会复制到临时文件夹：

所以我的问题是当我对我的可执行文件进行数字签名时出现在同意对话框中的无效文件名已显示为.requireAdministrator

做什么？

更新：

我能找到的最接近解释的东西来自Uninformed.org ：

打破经纪人

在请求 uiaccess 的程序的启动请求的情况下， 调用appinfo!RAiLaunchAdminProcess来为请求提供服务。然后验证该过程是否在appinfo!AiCheckSecureApplicationDirectory允许的目录集（硬编码）内 。在验证程序是从允许的目录中启动后，控制权最终传递给appinfo!AiLaunchProcess ，它执行为启动请求提供服务所需的剩余工作。此时，由于“安全”应用程序目录要求，受限用户（或以低完整性运行的用户，就此而言）不可能将自定义可执行文件放置在任何“安全”应用程序目录中。

提示是一些（未记录的、未指定的）硬编码路径，应用程序被“允许”位于其中。

另一个是用于请求 uiaccess 的程序。就我而言uiAccess="false"，我的原始清单中没有。但是更改清单以包含无 ui 访问权限：

但这并没有解决原来的问题。

更新二：

来自MSDN：

SendSAS 函数

重要uiAccess标志设置为 true 的应用程序必须经过 Authenticode签名才能正常启动。此外，应用程序必须驻留在文件系统中受保护的位置。目前，有两个允许的受保护位置：

• **\程序文件**
• **\windows\system32**

这似乎支持了可执行请求uiAccess必须位于允许的位置的概念。除了我不要求 uiAccess。

如果堆栈跨越内核边界，为什么 64 位 Windows 不能在异常期间展开堆栈 - 而 32 位 Windows 可以？

整个问题的背景来自：

OnLoad 异常消失案例——x64 中的用户态回调异常

背景

在 32 位 Windows 中，如果我在我的用户模式代码中抛出异常，该异常是从内核模式代码回调的，它是从我的用户模式代码调用的，例如：

Windows 中的结构化异常处理 (SEH) 可以展开堆栈，通过内核模式展开，回到我的用户代码，在那里我可以处理异常并且我看到有效的堆栈跟踪。

但不是在 64 位 Windows 中

64 位版本的 Windows 不能这样做：

由于复杂的原因，我们无法将异常传播回 64 位操作系统（amd64 和 IA64）。自从 Server 2003 的第一个 64 位版本以来，情况就一直如此。在 x86 上，情况并非如此——异常通过内核边界传播，最终将帧返回

而且由于在这种情况下无法返回可靠的堆栈跟踪，因此必须做出决定：让您看到无意义的异常，或者完全隐藏它：

当时的内核架构师决定采取保守的 AppCompat-friendly 方法——隐藏异常，并寄希望于最好的结果。

本文继续讨论所有 64 位 Windows 操作系统的行为方式：

• Windows XP 64 位
• Windows Server 2003 64 位
• Windows Vista 64 位
• Windows Server 2008 64 位

但从 Windows 7（和 Windows Server 2008）开始，架构师改变了他们的想法——在某种程度上。仅对于64 位应用程序（不是 32 位应用程序），它们将（默认情况下）停止抑制这些用户-内核-用户异常。因此，默认情况下，打开：

• Windows 7 64 位
• 视窗服务器 2008

所有 64 位应用程序都会看到这些异常，它们以前从未见过它们。

在 Windows 7 中，当原生 x64应用程序以这种方式崩溃时，程序兼容性助手会收到通知。如果应用程序没有Windows 7 清单，我们会显示一个对话框，告诉您 PCA 已应用应用程序兼容性 shim。这是什么意思？这意味着，下次您运行应用程序时，Windows 将模拟 Server 2003 的行为并使异常消失。请记住，Server 2008 R2 上不存在 PCA，因此此建议不适用。

所以这个问题

问题是为什么64 位 Windows 无法通过内核转换来展开堆栈，而 32 位版本的 Windows 可以？

唯一的提示是：

由于复杂的原因，我们无法将异常传播回 64 位操作系统（amd64 和 IA64）。

提示是复杂的。

我可能不明白这个解释，因为我不是操作系统开发人员 - 但我想知道为什么。

更新：停止抑制 32 位应用程序的修补程序

Microsoft 发布了一个修补程序，使 32 位应用程序也不再抑制异常：

KB976038：在 64 位版本的 Windows 中运行的应用程序引发的异常被忽略

• 在回调例程中引发的异常在用户模式下运行。

在这种情况下，此异常不会导致应用程序崩溃。相反，应用程序进入不一致的状态。然后，应用程序抛出一个不同的异常并崩溃。

用户模式回调函数通常是由内核模式组件调用的应用程序定义的函数。用户模式回调函数的示例是 Windows 过程和挂钩过程。Windows 调用这些函数来处理 Windows 消息或处理 Windows 挂钩事件。

然后，此修补程序可让您阻止 Windows 全局吃掉异常：

或每个应用程序：

该行为也记录在 XP 和 Server 2003 的 KB973460 中：

• 在 64 位版本的 Windows Server 2003 或 Windows XP Professional 中运行的 64 位应用程序引发的异常将被静默忽略

一个提示

在研究使用 xperf 在 64 位 Windows 上捕获堆栈跟踪时，我发现了另一个提示：

Xperf 中的堆栈行走

禁用寻呼执行器

为了在 64 位 Windows 上进行跟踪，您需要设置DisablePagingExecutive注册表项。这告诉操作系统不要将内核模式驱动程序和系统代码分页到磁盘，这是使用 xperf 获取 64 位调用堆栈的先决条件，因为 64 位堆栈遍历依赖于可执行映像中的元数据，并且在某些情况下xperf堆栈遍历代码不允许触摸分页页面。从提升的命令提示符运行以下命令将为您设置此注册表项。

设置此注册表项后，您需要重新启动系统才能记录调用堆栈。设置此标志意味着 Windows 内核将更多页面锁定到 RAM 中，因此这可能会消耗大约 10 MB 的额外物理内存。

这给人的印象是，在 64 位 Windows 中（并且仅在 64 位 Windows 中），您不允许遍历内核堆栈，因为磁盘上可能有页面输出。

我有以下问题，如果有人能回答会有所帮助，我已经用谷歌搜索过，阅读文章和用户体验后我很困惑。

问题：如果用户没有管理员权限，则使用 InstallShiled 创建的 MSI 不会安装在 windows-7 上

1. 我是否必须为使用 InstallShiled 11.0 开发的 MSI 安装任何 shim
2. 我是否必须为 msiexec 可执行文件安装 shim。
3. Microsoft 是否默认提供这些 shim，如果是，如何在客户端计算机上安装
4. 启用 AppCompat 引擎的目的是什么？如果它被禁用是否意味着不会使用垫片？
5. 我可以使用 ORCA 工具执行类似于 AppCompat Toolkit 中的 ForceAdminAccess hack 的操作吗

感谢您的时间和关注

谢谢汤姆