将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.

令我困扰的是，它工作在Server 2012 R2在.NET 4.0，但不是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 vs 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编辑项目文件以设置所需的Framework目标。测试应用程序是用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#.

推荐答案

Server 2012 R2与.NET 4.5总是在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内核的最后一次大改革。

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.

并且高熵虚拟地址特性是重要的变化。这是一个导致您的本地代码中的错误跳闸。此选项与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.

原始版本ASLR由动态库选项启用，通过选择256个可能的地址偏移中的一个来随机化地址。在引导时选择。在64位进程中有更好的选择，它有一个更大的地址空间。 / HIGHENTROPYVA链接器选项启用它。但是由于副作用，地址不再可能位于较低的4千兆字节地址空间中。因此跳过了这个bug。

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屋！