爱华网“LINK100:Internal error duringIncrBuildImage”
搜了一下才知道，解决办法如下：
一、下微软的补丁：KB948127补丁来解决，http://code.msdn.microsoft.com/KB948127。貌似安装了也不起作用
二、如果下载的补丁没安装成功或下载失败，可以用下面的方法手工来改工程设置项目(Project)->属性(Property)->链接器(Linker)->常规(General)下面的“启用增量链接(Enable IncrementalLinking)”，将“是(/INCREMENTAL)”改为“否(/INCREMENTAL:NO)”。不过这又引入了另外一个警告：FormatCom.obj : warning LNK4075:忽略“/EDITANDCONTINUE”(由于“/INCREMENTAL:NO”规范)
选择项目,属性(Property pages)->配置属性(ConfigurationProperties) ->C/C++，修改“调试信息格式(Debug InformationFormat)”为“程序数据库(Program Database(/Zi))”即可。
看到这我又迷茫了，不断咒骂vs复杂的同时我搜索了增量链接这个东西，得到了如下的解释：
好的，文接上回，本文我就来讲讲微软link.exe连接器的IncrementalLiking这个特性。当然这个其实不是微软linker独有的特性，很多链接器都有这个特性，这个特性实际上是为了提高链接速度的。
想象一下这个场景，我写了两个函数foo()和bar()，其中foo()在0x400100处而bar()紧接着保存在0x400200处。现在我将foo()改写了一下，添加了一些perfect的功能，然后编译了新的代码。不过现在的麻烦是foo()不可避免的变大了，他现在需要200h字节来保存了。那么链接器该怎么办？
一般的思考是——重新洗牌，将现有的编译好的exe删除了，然后重新布局所有的函数，也即是说bar()函数向后挪动0x100h字节的位置，给foo()腾出空间来。然后之后所有的函数都需要重新定位……对于大型软件来说这个处理时间开销是痛苦的，但作为程序员我们却不能避免需要不断的调试改代码，不断地重复这个耗时的工作。
不过我们现在并不需要给客户最终的发行代码，我们只是想要尽快地将程序的bug改掉然后去休息而已！于是，IncrementalLinking出现了！它的原理如下：
现在连接器不会将所有函数紧挨着放在一块儿了，他们会在函数之间加上padding，这个时候函数要想添几句指令就有余地了。只要我们的改动不大，没有超过padding的范围连接器就不需要重新洗牌，这大大提高了链接的速度。
先别高兴，加入我们的改动很大，以至于超过padding能够搞定的范围怎么办？如上图，我们还会在整个section末尾设置一个较大的padding（当然具体在哪里要看实现，比如我这图是从GCC那里搞得，说的就是ld.exe的行为方式），这时候就可以将这个函数搬到这里来了。但有个毁灭性的问题——所有调用我这个函数的函数都必须重定位他们的call指令啊！
为了解决这个问题，我们引入了一个ILT表（Incremental LinkingTable），这个表是放在.text区域中的（我在IDA中观察得知）。它的原理是什么呢？我们来看：
;之前我们都是直接调用函数复制代码
call foo
;现在我们来点小把戏
call foo_stub
foo_stub:
jmp foo
我们现在不直接调用函数，而是call到一个包含jmp指令的地方，然后由这个指令将我们的程度带往foo()函数的实现去。现在如果我们将foo()的实现改动过大后，linker直接将foo()移动了，然后只需要修改这个jmp指令就行了。可以看到，这种实现方式开销是O(1)。然后当很多个函数都用这种方式时，就形成了一个有jmp指令构成的表——这就是ILT表啦。
有兴趣的童鞋可以做下实验，在VS2010编译一次代码，然后用IDA或者W32Dasm之类的软件可以看到两个函数之间间隔了不少距离，而这些间隔就是我们所谓padding。padding被填充以0xCCh的数据。熟悉win32汇编的朋友这时候该笑而不语了，是的，这个值就是指令INT3。在WIndows下，执行这个指令会引发一个异常，然后程序会被终止或是回到调试器去，这当然是出于安全性考虑的。这之后如果你在前一个函数加几句话，编译后可以看到两个函数位置不变，但函数间的padding变小了。
