将 C++CLI 包装器从 .NET 4.0 迁移到 4.5 会导致 Windows Server 2012 R2 上的 winsock 错误 [英] Migrating C++CLI wrapper from .NET 4.0 to 4.5 cause winsock error on Windows Server 2012 R2

问题描述

我为我们使用的通信中间件构建了一个 C++ CLI 包装器.包装器已经在 .NET 4.5 中并且在 Windows 7 和 Windows Server 2008 R2 中工作正常.但在 Windows Server 2012 R2 中，它会因 mswsock.dll 中的访问冲突"错误而崩溃

I have build a C++ CLI wrapper for a communication middleware we use. The wrapper has been in .NET 4.5 and works fine in Windows 7 and Windows Server 2008 R2. But in Windows Server 2012 R2 it crashes with an "Access violation" error in mswsock.dll

有趣的部分是，如果我构建包装器和测试应用程序以面向 .NET 4.0，它就可以工作.但是当我将它们重新定位到 .NET 4.5.x 时，它会触发异常.

The interesting part is that if I build the wrapper and test application to target .NET 4.0 it works. But when I re-target them to .NET 4.5.x it triggers the exception.

我曾尝试调查安全性、强命名、热修复 .NET，但没有用.

I've tried to investigate security, strong naming, hot-fix'ing .NET, but to no use.

令我烦恼的是，它适用于 .NET 4.0 中的 Server 2012 R2，但不适用于 4.5.x.并且显然是在本机代码访问winsock API时发生访问冲突.

What troubles me is that it works on a Server 2012 R2 in .NET 4.0, but not 4.5.x. And that it evidently is when the native code accesses the winsock API that the access violation occurs.

有没有人遇到过同样的问题，或者类似的 Server 2012 .NET 4.0 与 4.5.x 有线连接?

Have anyone experienced the same issue, or similar Server 2012 .NET 4.0 vs 4.5.x wiredness?

在运行 .NET 4.5 应用程序时，Server 2012 中是否有任何安全机制被激活，而对于 4.0 应用程序则没有激活.特别是关于 CLI 模块?

Are there any security mechanisms activated in Server 2012 when running .NET 4.5 applications, that aren't active for 4.0 applications. Specifically regarding CLI modules?

技术:本机代码是用 VS2010 编译的，因此包装器是在 VS2012 中使用该编译器编译的.编辑 C++ CLI 项目文件以设置所需的框架目标.测试应用程序是用 C# 编写的.

Technical: Native code is compiled with VS2010, and thus the wrapper is compiled using that compiler in VS2012. C++ CLI Project file is edited to set the desired Framework target. Test application is written in C#.

推荐答案

带有 .NET 4.5 的 Server 2012 R2 总是在 32 位地址范围之外分配内存

Server 2012 R2 with .NET 4.5 always allocates memory outside a 32-bit address scope

是的，当您在 EXE 文件上使用 Dumpbin.exe/headers 时，这很明显.我将发布它显示的输出的相关部分:

Yes, this is pretty visible when you use Dumpbin.exe /headers on the EXE file. I'll post the relevant part of the output it displays:

        4.00 operating system version
        0.00 image version
        6.00 subsystem version                      // <== here
           0 Win32 version
        8000 size of image
         200 size of headers
           0 checksum
           3 subsystem (Windows CUI)
        8560 DLL characteristics
               High Entropy Virtual Addresses       // <=== here
               Dynamic base
               NX compatible
               No structured exception handler
               Terminal Server Aware

子系统版本是 .NET 4.5 编译的可执行文件中的第一个重要变化.版本 6.00 是 Vista 的版本，之前设置为 4.00.一个副作用是该程序无法再在 XP 和 Server 2003 上运行.版本 6 是对 Windows 内核的最后一次大修.巨大的变化，正是那种让 Vista 不受欢迎的变化.

The subsystem version is the first important change in .NET 4.5 compiled executables. Version 6.00 is the version of Vista, previously that was set to 4.00. One side-effect is that the program cannot run anymore on XP and Server 2003. Version 6 is the last drastic overhaul of the Windows kernel. Big changes, the kind that made Vista so unpopular.

High Entropy Virtual Addresses 特性是重要的变化.这就是导致您的本机代码中的错误跳闸的原因.此选项与 ASLR(地址空间布局随机化)相关，这是一种针对恶意软件的对策.通过随机化地址空间布局，恶意软件攻击代码变得困难，它不再依赖于这些代码存在于已知地址.

And the High Entropy Virtual Addresses characteristic is the important change. That's the one that caused the bug in your native code to trip. This option is related to ASLR (Address Space Layout Randomization), a counter-measure against malware. By randomizing the address space layout, it becomes difficult for malware to attack code, it can no longer depend on such code to exist at a known address.

由 Dynamic base 选项启用的原始版本的 ASLR，通过选择 256 个可能的地址偏移量之一来随机化地址.在启动时选择.在 64 位进程中有更好的选择，它有更大的地址空间./HIGHENTROPYVA 链接器选项启用它.但是有一个副作用，即地址不再可能位于较低的 4 GB 地址空间中.从而触发铸造错误.

The original version of ASLR, enabled by the Dynamic base option, randomized addresses by picking one of 256 possible address offsets. Chosen at boot time. There are much better choices in a 64-bit process, it has a much larger address space. The /HIGHENTROPYVA linker option enables it. But with the side-effect that addresses are no longer likely to be located in the lower 4 gigabyte address space. Thus tripping the casting bug.

.NET 4.5 编译器在您面向 4.5 及更高版本时打开这些，而 4.0 编译器没有.不必再支持 XP 和 Server 2003(它们不能运行 4.5)启用了这些选项.

.NET 4.5 compilers turn these on when you target 4.5 and up, 4.0 compilers did not. Not having to support XP and Server 2003 anymore (they can't run 4.5) enabled these options.

这篇关于将 C++CLI 包装器从 .NET 4.0 迁移到 4.5 会导致 Windows Server 2012 R2 上的 winsock 错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！