问题标签 [winsxs]

有时我们客户的故障转储文件将包含对

问题是，我没有得到正确的堆栈跟踪，因为这些 DLL（从 2011 年 4 月开始）被 2011年 6 月的进一步补丁取代，与我在网上找到的相反，从MS下载不包含 5592 版本，而仅包含 CRT/MFC/... DLL 的 6195 版本。

我们可执行文件的清单指向版本8.0.50727.4053，但这无济于事，因为该版本被 5592 和后来的 6195 取代。SxSTrace 输出如下所示：（忽略德语文本并查看版本号）

现在，也许我可以从客户的 PC 中获取确切的 DLL，但这仍然只剩下 DLL，而且我仍然没有任何调试符号（PDB 文件）。

因为，查看我的转储（例如 kernel32），我可以看到通常所有系统 DLL 都应该从 MS 符号服务器（或其缓存）加载——

我必须假设微软从他们的符号服务器中清除了这些文件的 5592 版本，因此如果客户 PC 确实包含 2011 年 4 月更新但不包含 2011 年 6 月更新，则有效地阻止了任何有用的调试。从我可以从 MS 页面推断，这些更新包含在 Windows 更新中，所以如果客户的更新机制不完整，我真的无能为力。

是否还有从 MS 下载的包含 5592 DLL 和 PDB 文件的原始补丁？

更新：似乎 MS 符号服务器确实包含 5592 DLL 版本的 PDB 文件，但它不包含 DLL。（现在这是否有意义是另一个问题，但也许这就是它与这些 DLL 一起工作的方式。）

我可以确定以下内容：

• 4053 的 PDB：...\Cache\msvcr80.i386.pdb\7D5669C7431445CD84D149AE19FE3CD51\msvcr80.i386.pdb
• 5592 的 PDB（因为 WinDbg 确实加载了那个）：...\cache\msvcr80.i386.pdb\3FA5DD7B7FAF4F2EAC5ABEDC03012DB21\msvcr80.i386.pdb
• 6195 的 PDB：...Cache\msvcr80.i386.pdb\54C9E2F351544D1CB39517DC4B299EA81\msvcr80.i386.pdb

背景：

• 位于C:\windows\Winsxs文件夹中的 Windows 共享运行时库
• 在 Winsxs 中，有两个重要的子文件夹也位于policies和Manifests
• 除此之外，还有很多运行时程序集位于彼此的子文件夹中。
• 里面的所有子文件夹Winsxs并 policies 具有相同的命名格式。

例如文件夹名称：

• 运行时间：x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e
• 政策：x86_policy.9.0.Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_x-ww_b7353f75

据我所知，名称的第一部分 (x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1) 描述了程序集或策略的“processorArchitecture”( x86)、“Name”( Microsoft.VC90.CRT)、“publicKeyToken”( 1fc8b3b9a1e18e3b) 和“Version”( 9.0.30729.1)。

问题：x-ww_6f74963e assembly( ) 或 policy( x-ww_b7353f75) 文件夹名称 的最后一部分描述了什么？

好的，这是最初的问题（但故事很长）。我在 Windows XP 计算机上部署了我的 C++ MFC 应用程序，该计算机以前安装了一些 C++ 重新分发包和一些运行时程序集的安全补丁。所以这些预装的 C++ 再分发包会自动在Winsxs/policies. 这些策略强制使用新的运行时程序集，而不是我的应用程序使用和部署的程序集。但有时这些较新的 DLL 不存在，因为某些其他应用程序删除或程序集可能已损坏。所以我正在寻找一种方法来部署专门用于我的应用程序的运行时程序集（这意味着我的应用程序必须使用它曾经部署的程序并忽略策略）。所以我认为子目录名称的最后一部分与应用程序的身份相关联。我需要找到它。

我正在尝试在 WinSxS 中安装我的 dll 的 MUI 版本。

我正在为具有下一个程序集标识的 mt.exe 创建本地化 dll 的清单文件：

生成的清单文件是这样的：

尝试加载 Dll 时，由于“文化”属性，无法创建激活上下文。

如果我将属性名称更改为“语言”，它运行良好。

为什么 mt.exe 创建“文化”属性而不是“语言”属性？

我怎样才能 forze mt.exe 来创建“语言”属性而不是“文化”属性？

谢谢你。

Windows 有一个 WinSXS 目录，它存储一些系统文件的旧版本，以防您想要回滚服务包或类似文件。（这些存储为硬链接，因此许多文件指向与当前系统文件相同的磁盘区域）。

它还有一个卷快照服务，可以保存整个 NTFS 卷的旧版本的快照。我的理解是，它被诸如备份工具之类的东西使用，它们希望查看整个卷内容的瞬时快照。

我可以看到它们是完全不同的东西，并且出于不同的目的，但它似乎仍然是重复的。谁能解释为什么这些功能中的一个或其他不能满足所有需求？

我想使用 Microsft.Web.Administration.dll 程序集。在我的 Windows 7 上，该文件仅位于文件夹 c:\windows\winsxs 中。为什么程序集在此文件夹中，是否建议从那里引用？

我有一个 Java 应用程序，我想生成一个新进程（启动一个 .bat 文件），它基本上会做与双击它相同的事情。

为了产生这个过程，Runtime.getRuntime().exec()我已经尝试了这两种方法。ProcessBuilder这两种方法都有效（它们可以启动 .bat 文件），但我的问题是它们实际上并没有做与双击它完全相同的事情。

更具体地说，这个 .bat 文件启动了一个配置为使用 Windows SxS（并排）运行的 JVM (java.exe MyMainClass)。因此，我创建了适当的java.exe.config和 java.exe.manifest文件。当我点击它时，java 应用程序启动并且适当的 .dll 被成功加载（因为我需要 SxS）。

ProcessBuilder我的问题是，当我使用or启动完全相同的 .bat 文件（具有完全相同的参数和进程环境）时Runtime.getRuntime().exec()，它似乎没有考虑到我的 SxS 配置，因此我需要的 .dll 是根本没有加载，导致错误。

有没有人知道如何启动这个 .bat 文件，就像我双击它时 Windows laucnhes 一样？此外，是否有人对 Java SxS 部署有任何经验？我无法真正理解为什么 ProcessBuilder 会忽略我的 SxS 配置。

提前致谢。

我正在开发许多使用 RegFree COM 激活的应用程序，除了其中一个应用程序是使用使用 JIT 类型编译器的旧技术运行之外，一切都运行良好。

为了让 RegFree COM 工作，我必须为启动可执行文件提供一个清单（如果我错了，请纠正我）并列出我的依赖项。我所有的其他应用程序都是内部构建的，我可以完全控制我的清单（创作，如果我嵌入它，如果我将它并排放置，等等）。但是这个 JIT 编译器（ala Java JRE）不是我的，它已经包含（嵌入）一个清单。

我已经提取了清单（使用带有 -inputresource 和 -outfile 的 MT），对其进行了修改并重新嵌入。它按预期工作。但是，由于对这个可执行文件没有所有权，我担心这种操作的合法性（修改第三方的可执行文件并重新分发它！）并希望避免这样做。另外，我担心在某些时候这个可执行文件可能会被第三方签名，因此修改嵌入式清单会破坏签名。

有没有办法让 sxs-loader 先寻找另一个清单？似乎如果它找到一个嵌入的，它默认采用它（在大多数情况下这很好）。我可以提供一个配置文件或任何可以跳过嵌入式清单并使用我并排提供的文件（myExe.exe.manifest，而不是 myExe.exe 中的 RT_MANIFEST 资源）吗？

我将首先解释我正在尝试做什么（以及为什么），然后再深入了解细节。

我试图让注册免费 COM 激活在编译 JIT 的语言的上下文中工作。我使用 Reg-Fre COM 是因为我想避免注册我的 COM 组件，并且希望这个应用程序可以在没有管理权限的情况下安装。

JIT 编译器是主要的可执行文件，已签名并包含嵌入式清单。默认情况下，最新版本的 Windows 更喜欢嵌入清单而不是外部清单（在 Windows XP 上正好相反）。由于 JIT 已签名，因此我无法在不破坏签名的情况下提取/修改/更新它的清单。此外，这会在我们的应用程序的维护中引入复杂性（始终确保我们嵌入一个新的清单）。修改我不拥有权利的程序也会产生法律影响。

所以，我的想法是尝试让 WinSxS 激活通过一个 Win32 包装库，我将为其提供一个列出依赖项的清单。作为概念验证，我决定制作一个简单的 VB6 应用程序、一个 C++ Wrapper 库和两个 COM 库（1 个在 .NET 中，1 个在 VB6 中）。包装器包含 3 种方法，一种调用 VB6 COM，一种调用 .NET COM，一种返回简单字符串。只要我的 COM 的所有内容都已注册，它当然可以工作。如果我取消注册它们，为 COM 提供清单并将它们作为依赖项添加到主可执行文件的清单中，它就可以工作。如果我取消注册它们，为 COM 和 C++ Wrapper 提供清单并将 com 添加为 C++ Wrapper 的依赖项，然后将 C++ Wrapper 作为主可执行文件清单中的唯一依赖项添加，它可以工作。

请注意，对于我的所有测试，我运行一个 Powershell 脚本来更改我所有文件的修改日期，确保触发激活上下文缓存（清单）。

从那里，我开始使用 SXSTrace.exe 进行调试并设置 COMPlus_LoadLogDir 变量。我发现如果我的清单是外部的，它永远不会被考虑在内。我还发现，如果我将它嵌入到 .DLL 中，sxstrace 会显示它已找到、已解析并且已找到依赖项、已找到它们的清单，并且我在日志中获得了通常成功的上下文激活行。

然而，即使日志说，我的 COM 调用仍然没有通过。当调用 .NET COM 调用时，我在 COMPlus_CLRLoadLogDir 配置路径中得到一些输出。

在这种情况下，我没有得到任何输出。

一旦我将仅将我的 C++ Wrapper 列为我的主要可执行文件的依赖项的清单添加到我的主可执行文件中，一切都会重新开始工作。我从 SXSTrace 得到了类似的输出，但现在 COM 调用工作了。如前所述，在所有情况下，C++ Wrapper 的简单字符串方法都有效。这意味着即使我的主可执行文件中没有清单，它仍然可以找到我的 .dll 并调用它。如果我没有完整的清单链，似乎 COM 不起作用：Application.Manifest > Wrapper.Manifest > COMs manifests

所以，这里有两件事...... 1.我正在尝试做的事情甚至可能吗？（仅在属于我的 DLL 的清单中列出了依赖项，而不涉及主可执行文件的清单） 2. 如果可能的话，我可能只是遗漏了一件小事来让一切顺利进行......它是什么？:)

如果有人有兴趣尝试使用 em 的东西，我可以提供我所有的代码/可执行文件作为示例。

我有一个程序拒绝在某些 Windows 7 机器上运行。使用sxstrace，可执行文件声称需要 Microsoft.VC80.CRT/MFC 版本 8.0.50727.6195 和 8.0.50608.0。见下文。

使用mt.exe向我展示了相同的版本要求。

希望不相关，但我能够让它运行的唯一机器安装了 Visual Studio。

我按照 Hans Passant 在这个问题的评论中建议的那样做了，这导致我安装了 x86 版本。

在我安装新的可再发行组件之前，我有以下内容：

在我安装了假定的 8.0.50727.6195 可再发行组件后，我最终得到：

我预计“之后”部分的顶线是8.0.50727.6195。我显然错过了一些东西。有人可以指出我正确的方向吗？我是不是连续 3 次得到错误的链接？

另外，这条线INFO: Find publisher policy at C:\Windows\WinSxS\manifests\x86_policy.8.0.microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_516d712b0f495a45.manifest是什么意思？它是否也依赖于 8.0.5727.4940？

我有一个 Win32 程序集，我一直在通过安装程序将其部署到 WinSxS 中。直到最近当我将我的项目升级到 VS2013 时，一切都运行良好。自升级以来，我注意到安装程序抛出错误并回滚安装。经过验证，我意识到问题确实出在将 Win32 程序集安装到 WinSxS 中。在进一步的探索中，发现问题只是在程序集是在 Release 配置中构建的，而不是在 Debug 配置中构建的。我已经验证了两种配置中的链接器和清单工具属性，并且没有区别。我想知道什么会导致这样的问题？

安装程序日志说：

错误 1935。安装程序集组件 {65E42E52-10F8-482D-B246-0599A4B162B5} 时出错。HRESULT：0x800736FD。程序集接口：IAssemblyCacheItem，函数：Commit，程序集名称：MyAssembly,processorArchitecture="x86",publicKeyToken="75c921dc6145ab19",type="win32",version="3.0.0.0" === 记录停止：7/31/2014 11:28:05 ===