vs2010对源文件进行md5计算的错误，源文件与模块生成时的文件不同

最新推荐文章于 2022-06-22 19:24:02 发布

艾萨克SU

最新推荐文章于 2022-06-22 19:24:02 发布

阅读量3.6k

点赞数

本文链接：https://blog.csdn.net/jewelsu/article/details/75333072

版权

最近碰到一个奇葩的问题。用vs2010编译程序调试运行，跟踪到一个函数的时候提示“源文件与模块生成时的文件不同，是否希望调试器使用它？”

通常碰到这种情况，重新编译一下就好了，但是这次，重新编译了n次居然都没好。

查了网上的方案，都是说修改工具-选项里的选项，取消比较。但是那只是掩耳盗铃而已。

选择“是”，在文档中无法下断点。

选择“否”不使用该文档调试，弹出来“无可用源”一个界面，界面上显示如下：

为“e:\xxx.cpp”查找源。Checksum: MD5 {b5 3f 44 4 db ea e5 e6 59 a f1 a4 fe af 9d e8}
文件“e:\xxx.cpp”存在。
正在脚本文档中查找“e:\xxx.cpp”...
正在确定校验和对于以下位置是否匹配:
1: e:\xxx.cpp Checksum: MD5 {c1 83 56 4e fa 1f f6 33 ed ae 8 ad bb 5e 50 ca} 校验和不匹配。
正在项目中查找“e:\xxx.cpp”。

这里显示了编译时该文件的md5值，也显示了当前文档的md5值，这两个值时不匹配的。

这怎能轻易放过。肯定有一个是错的。

下载了计算文件md5值的工具fciv,算了一下这个文件值，发现显示的跟之前显示的当前文档的md5值一致，看来问题出在了编译时保存在pdb中的值，编译时计算错了。

再下载查看pdb的工具cvdump，用-sf选项查看文件md5值。果然是不一致的。

之前这个文件编译都没出现过这种情况，于是恢复到上一个版本。通过比较，一致。

看来问题出现在了增加的一段代码身上。

将新增的代码注释掉，还是不一致。

逐行删除，终于找到了一行，将这一行删掉之后就好了。

再试，只删这一行的字符，发现只需要将这一行的开头tab删掉就好了。

通过winhex查看，这个tab并没有什么异常。

再试，在tab处再加一个tab，好了。

这最前面加一个tab，也是好的。

只要是在这个位置之前加一个tab，就是好的。删掉这个tab也是好的。

要疯了。

现在的结论就是，vs2010在编译时计算文件md5是存在bug的，至少对于我这个文档，计算是错误的，而且错误发生条件非常苛刻。

如果有人了解vs2010编译时计算md5的程序，可以一起探讨。

鉴于一定的原因，那个神奇的文件就不贴出来了，如果有兴趣的可以私下交流。

附录转自 https://msdn.microsoft.com/zh-cn/magazine/mt795185.aspx

Visual Studio - 使用 Visual Studio 对源代码文件进行哈希处理以确保文件完整性

对所有编译的软件语言来说，将人类可读代码转换成计算机可读代码都是一项软件保障挑战：用户如何有信心相信在其计算机上运行的软件程序是根据开发者创建的同一源代码文件生成的呢？这不一定，即使源代码文件经过行业专家评审，也不例外，因为可能出现开放源代码软件的情况。软件保障的核心是信任经过评审的源代码文件是生成可执行文件的相同源代码文件。

在编译和链接过程中，使用特定编程语言（C#、C++、Objective C、Java 等）编写的一组源代码文件被转换成二进制可执行文件，以供在特定体系结构（如 x86、x64、ARM）的计算机上运行。但这种转换可能不具有决定性作用。两组不同的源代码文件可能被转换成两组位完全相同的可执行文件。有时，这是有意而为之。源代码文件内空格或文本注释不一致不得影响编译器生成的二进制代码。另一方面，同一组源代码文件也可能会因不同的编译过程而被转换成不同的可执行文件。无论属于上述哪种情况，问题都在于确定性，即无法确定拥有的文件是否就是所需的文件。

为了解决这个问题，不妨在编译过程中使用 Visual Studio 编译器对源代码文件进行哈希处理。将编译器生成的哈希值与经过检查的源代码文件生成的哈希值进行匹配，可以验证可执行代码是否的确是由特定的源代码文件生成而来。这显然会让用户很受益（实际上，如果其他编译器的供应商也采用了类似方法，那么用户会进一步受益）。本文介绍了用于选择哈希算法的新 Visual Studio 开关、此类哈希可能适用的应用场景，以及如何使用 Visual Studio 生成源代码哈希值。