3

我在装有 Visual Studio 2012 的 Windows 7 机器上编写了一个 .NET 4.5 应用程序，它在 Windows 7 上安装和运行良好。

当我尝试在 Windows 8 机器上部署它时，它会发生灾难性的崩溃，事件查看器中的输出不是很有用。Dependency walker
的跟踪表明它在一个/一些核心 Windows dll 中找不到方法。例如：

LoadLibraryExW("C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscoreei.dll", 0x0000000000000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned 0x00007FFDEA780000.  
GetProcAddress(0x00007FFDEA780000 [MSCOREEI.DLL], "RegisterShimImplCallback") called from "MSCOREE.DLL" at address 0x00007FFDEA82F3A9 and returned 0x00007FFDEA783444.  
GetProcAddress(0x00007FFDEA780000 [MSCOREEI.DLL], "RegisterShimImplCleanupCallback") called from "MSCOREE.DLL" at address 0x00007FFDEA82F3BC and returned NULL. Error: The specified procedure could not be found (127).

在检查 mscoreei.dll 时，我注意到：

Windows 7 机器
v4.0.30319.18408
613,456 字节

Windows 8 机器
v4.0.30319.33440
633,424 字节

两台机器（根据ASoft .NET 版本检测器）都有 .NET 4.5 Full。

为什么我的机器有不同的 .NET 版本，我如何确保我的 windows 7 机器上的编译器以 windows 8 机器的正确版本为目标？

4

3 回答 3

5

是的，这完全正常。Windows 8 还具有 .NET 3.5 的自定义版本。没有什么不寻常的，.NET Framework 确实严重依赖操作系统版本。以及它预装在 Windows 8 上的原因。

对于 MSCoree（.NET 框架的“加载程序 shim”）而言，这种依赖关系尤其值得注意。它带来了一个非常戏剧性的噱头，它可以让 Windows 从 32 位 EXE 文件创建一个 64 位进程。这并不简单，它与 Windows 中的加载程序密切合作以实现这一目标，修补内部数据结构以使其创建一个 64 位进程。

看到“找不到指定的程序”错误也没什么异常。这就是它使用 GetProcAddress() 而不是隐式导入依赖的原因。使用 GetProcAddress() 是一种非常常见的技术，可以确定是否确实支持特定的 api 函数。

我严重怀疑您是否找到了程序崩溃的真正原因。永远不要忘记实现 AppDomain.CurrentDomain.UnhandledException 事件来报告未处理的异常，你从 Windows 获得的崩溃信息是毫无用处的。

于 2013-10-31T14:34:06.470 回答
1

It looks like, either somewhere in your code or in a third party DLL, the LOAD_WITH_ALTERED_SEARCH_PATH value is being used.

This is because the LoadLibraryEx function is being called somewhere. This imports kernel32.dll which is different in Windows 7 compared to Windows 8.

LOAD_WITH_ALTERED_SEARCH_PATH which is mentioned in the error was already deprecated in Windows 7, it could be that this doesn't exist in Windows 8 at all.

I think you need to install Visual Studio on Windows 8.1, and debug your code from there until you hit an exception. It will probably help you pinpoint where the problem is faster than compiling on 7 and trying to run on 8 while trying to decipher cryptic error messages. Once you find the problem library, you could contact the vendor to see if they have an updated version.

于 2013-10-31T12:29:46.537 回答
0

这不是一个特别有用的答案 - 但它是一个无法处理在 Win 8 上的 x64 进程中运行的第三方 dll。没有关于究竟是什么导致实际问题的更多信息

于 2014-04-07T22:54:55.273 回答