你可能有一个针对x64(这是模块机器类型)的. obj或. lib文件，而你链接的是x86(这是目标机器类型)。

在. obj文件上使用DUMPBIN /HEADERS，并在FILE HEADER VALUES块中检查机器条目。

当我遇到这个令人抓狂的问题时，我写了一篇关于这个问题的博客文章，并最终将我的系统恢复到正常工作状态。

以下是需要检查的事项，按顺序:

Check your properties options in your linker settings at: Properties > Configuration Properties > Linker > Advanced > Target Machine. Select MachineX64 if you are targeting a 64 bit build, or MachineX86 if you are making a 32 bit build. Select Build > Configuration Manager from the main menu in visual studio. Make sure your project has the correct platform specified. It is possible for the IDE to be set to build x64 but an individual project in the solution can be set to target win32. So yeah, visual studio leaves a lot of rope to hang yourself, but that's life. Check your library files that they really are of the type of platform are targeting. This can be used by using dumpbin.exe which is in your visual studio VC\bin directory. use the -headers option to dump all your functions. Look for the machine entry for each function. it should include x64 if it's a 64 bit build. In visual studio, select Tools > Options from the main menu. select Projects and Solutions > VC++ Directories. Select x64 from the Platform dropdown. Make sure that the first entry is: $(VCInstallDir)\bin\x86_amd64 followed by $(VCInstallDir)\bin.

一旦我完成了第4步，一切都恢复正常了。问题是我在我所有的项目中都遇到了这个问题，我想编译一个64位的目标。

在VS2008中，当我试图将X64版本添加到VS2003转换的项目中时，我遇到了同样的问题。

我查看了在谷歌(目标机器，vc++目录，DUMPBIN....)上搜索此错误时发现的所有内容，一切看起来都OK。

最后，我创建了一个新的测试项目，并做了相同的更改，似乎可以工作。

在vcproj文件之间进行差异，发现了问题....

我的转换项目有/MACHINE:i386设置为附加选项设置下的链接器->命令行。因此，有两个/MACHINE选项设置(x64和i386)，另外一个优先。

删除这个，并在链接器->高级->目标机下正确设置，使问题消失。

除了C Johnson的清单之外，我还要补充以下几点:

检查在Visual Studio: 项目属性->配置属性-> link ->命令行。

“附加选项”不应该包含/machine:X86

我有这样的键，由CMake输出生成:CMake生成x86项目，然后我通过Visual Studio 2010中的配置管理器添加了x64平台-除了链接器命令行，单独指定/machine: x86之外，新平台的一切都创建得很好。

"project property - CUDA Runtime API - GPU - NVCC Compilation Type"

设置64位编译选项-m64 -cubin

提示是在编译日志。 是这样的:

nvcc.exe ~~~~~~ -machine 32 -ccbin ~~~~~

“- 32号机器”是个问题。

第一个设置64位编译选项， 下一步重新设置混合编译选项。 然后你就能看到成功。

我在构建QT时遇到了这个问题，我在某处读到的说明建议我使用VS命令提示符配置nmake。

我选择了x64命令提示符并轻松地执行了配置。当我尝试nmake时，它给出了这个错误。

我想有些组件是为32位系统预建的。这个错误甚至报告了哪些模块是为x86构建的。

我使用32位默认的VS命令提示符，它工作。

模块机类型是您正在编译的机器，目标机类型是您正在为其构建二进制文件的x86或x64架构。

如果您的解决方案有库项目，请检查属性->图书管理员->通用中的目标机器属性

在Visual Studio 2013中，

1)检查项目属性页/配置属性/链接器/所有选项，并纠正所有未配置的机器和目录。

2)检查项目属性页/配置属性/链接器/输入，并纠正所有未配置的目录。

参见示例1)

除了Jhonson的列表，还可以查看图书馆的文件夹

在visual studio中，从主菜单中选择Tools > Options。选择项目和解决方案> vc++目录。从平台下拉菜单中选择x64。

$(VCInstallDir)lib\AMD64;
$(VCInstallDir)atlmfc\lib\amd64;
$(WindowsSdkDir)lib\x64;

由于问题是由于编译和目标机器规格(x86 & x64)的差异造成的 遵循以下步骤:

打开要配置的c++项目。 选择“配置管理器”按钮，打开“配置管理器”对话框。 在“主用解决方案平台”下拉列表中，选择相应的选项，打开“新建解决方案平台”对话框。 在“类型或选择新平台”下拉列表中选择64位平台。

它解决了我的问题。

在Visual Studio 2012 +/-中，“配置属性”. linker的属性页。“命令行”包含一个标记为“附加选项”的框。如果您正在构建x64，请确保该方框不包含/MACHINE:I386。我的项目是这样做的，它产生了问题中的错误。

如果您的项目设置为在项目属性->配置属性->常规中具有相同的中间目录，也可能发生此问题

今天我就遇到了这种情况，因为我在x86模式下添加了一个库目录，并意外地删除了继承的目录，使它们变成了硬编码。 然后切换到x64后，我的vc++目录仍然读:

“... (VC_LibraryPath_x86美元);(WindowsSDK_LibraryPath_x86美元);”

而不是_x64。

我正在使用CMake，然后添加了一个win32配置。属性页显示x86，但实际上在文本编辑器中打开vcxproj文件时，它是x64!手动切换到x86解决了这个问题。

首先尝试以下几点: 1. 进入配置管理器，并创建一个新的x64，如果它已经不在那里。 2. 选择x64解决方案。 3.进入项目属性，然后链接器->高级选择x64机器。 4. 现在重新构建解决方案。

如果你仍然得到相同的错误。尝试干净的解决方案，然后重新构建，再次打开visual studio，您将获得最近打开的项目列表，右键单击该项目并将其从那里删除。现在转到解决方案并再次重新打开解决方案。

这是一个非常令人沮丧和讨厌的问题，但一旦你理解了它，它就很简单了:你在构建一种架构类型(在你的情况下是x64)中有一些元素，尽管它是另一种类型(比如x86)的目标。

您可以通过查看哪个obj文件导致崩溃来分析问题的根源，并开始在那里寻找问题。每个obj将有一个源代码模拟:要么在cpp, c, asm等。可能有一些特殊的构建事件使用了错误的工具。在属性表中查看。

我会先看看那里，然后再看C·约翰逊的待办事项清单。

当我将我的VS2008解决方案转换为VS2010并将win32配置更改为X64时，这种情况发生在我身上，在我的旧解决方案中我有mfcs90d。lib(配置->连接器->输入->附加依赖项)，因为我正在使用VS010，我刚刚在VS2010文件夹中检查了它是mfcs100d。所以我改变了mfcs90d。Lib到mfcs100d。lib(配置->链接器->输入->附加依赖项)它工作得很好。

所有的项目设置看起来都很完美，但我仍然得到了错误。查看.vcxproj文件并搜索“x86”就会发现问题:

<Lib>
  <AdditionalOptions> /machine:X86 %(AdditionalOptions)</AdditionalOptions>
</Lib>

快速搜索/替换所有出现的情况(10个单独的文件设置)解决了这个问题。

vcxproj文件可能包含“MACHINE:i386” 用编辑器编辑vcxproj文件。把它拿掉!

我通过在Visual Studio 2013中将Win32更改为*64来解决这个问题。

对于那些使用QT Creator的人来说，问题也是一样的(正如@c-johnson所描述的那样)。 确保工具包中MSVC的编译器设置设置为x86，如下所示。

对于一些使用命令提示符(dos提示符)的用户 这可能会有帮助:

call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" --help
Error in script usage. The correct usage is:
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" [option]
  or
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" [option] store
  or
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" [option] [version number]
  or
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" [option] store [version number]
where [option] is: x86 | amd64 | arm | x86_amd64 | x86_arm | amd64_x86 | amd64_arm
where [version number] is either the full Windows 10 SDK version number or "8.1" to use the windows 8.1 SDK
:
The store parameter sets environment variables to support
  store (rather than desktop) development.
:
For example:
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_amd64
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_arm store
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_amd64 10.0.10240.0
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_arm store 10.0.10240.0
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64 8.1
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64 store 8.1
:
Please make sure either Visual Studio or C++ Build SKU is installed.

如果你这样做:

CL "%1%2%3" /EHsc /链接user32。自由Gdi32。自由Winmm。自由comctl32。自由*。obj /子系统:CONSOLE /MACHINE:x86

你必须取消*。obj之前;为了避免混淆链接器与64和32位对象从以前的编译遗留下来?

上面有很多好的建议。

另外，如果你试图在x86 Win32中构建:

确保你在Program Files(x86)中链接到的所有库实际上都是x86库，因为它们不一定…

例如，我在C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\SDK中链接到的一个lib文件抛出了这个错误，最终我在C:\Program Files (x86)\Windows Kits\10\ lib \10.0.18362.0\um\x86中找到了它的x86版本，一切都正常工作。

我的目标是一个x64 Windows 10文本模式的DOSBox应用程序在C语言。 使用“Visual Studio 2019 Community”通过DOS提示符“nmake -f makefile”进行编译。 错误是类似的，但在相反的方面:

fatal error LNK1112: module machine type 'x32' conflicts with target machine type 'X64'

在另一台计算机上用vc++ 2010编译是可以的。但是“Visual Studio 2019社区”在这台计算机上失败了。所以我的设置是正确的，以上所有答案都不工作。

我想和大家分享的解决方案是这样的make.bat:

call "c:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat" 
nmake -f makefile

你会发现还有很多其他的vcvarxxxx .bat，只有这一个词。

我为自己解决了这个问题，如下所示。

首先，我根据这个问题的其他答案，得出的结论是所有的项目设置都是正确的。

然后我用编辑器检查了.vcxproj文件，并注意到两个(调试和发布)x64配置的< Link >属性没有指定< TargetMachine >，而Win32配置都包含< TargetMachine > MachineX86 < /TargetMachine >。

然而，我已经验证了，从Visual Studio的属性>配置属性>连接器>高级>目标机，x64配置说MachineX64 (/ Machine: x64)。

因此，我编辑了.vcxproj文件，在两个x64配置中包含< TargetMachine > MachineX64 < /TargetMachine >。回到Visual Studio项目属性对话框，我注意到MachineX64 (/MACHINE:X64)设置和以前一样，只是现在它以粗体显示(显然意味着该值不是默认值)。

我重建了它，它成功了。

在我的例子中，将环境变量PROCESSOR_ARCHITECTURE设置为AMD64 修复了问题。

https://social.msdn.microsoft.com/Forums/en-US/f9303904-81ce-405d-85b3-b66d97e49971

属性->configurationManager-> ActiveSolutionPlatform。这里选择x64。

它应该照顾到所有的依赖关系，编译应该能够顺利进行