我编写（和销售）的软件在分发之前经过压缩和加密。每次发布新版本时，我都会在压缩和加密之前保留所有 .map 文件和生成的二进制文件，包括 exe。
当它在客户的机器上崩溃时，我会得到一个小型转储。我在 Visual Studio 中打开这些小型转储并在那里进行探索。
通过在 .map 文件中搜索地址，我充分利用了这些小型转储。这通常会让我进入代码的正确区域，并且我通常可以推断崩溃发生的原因并修复它，但这非常耗时。
如果我可以在调试 minidump 时使用从原始构建中保存的符号，那将会很有帮助。
我的问题是我收到有关无法找到正确符号的警告。我的研究让我相信这是因为客户端机器上 exe 的校验和与 Visual Studio 构建的 exe 的校验和不匹配。我明白为什么，它已被压缩和加密。当然校验和不匹配。
我想我可以手动编辑小型转储或更改已保存二进制文件的校验和以匹配可分发的校验和。我更愿意操作存储的副本，这样我就不必修改每个进入的转储，但我会很高兴。
所以，我的问题是：我怎样才能找到这些校验和并找出我应该用什么来替换它们？作为一个辅助问题：有没有更好的方法？
在不知道您如何精确地压缩和加密二进制文件的情况下，我很难说得非常具体。
John Robbins 的这篇博文指出，可执行映像通过嵌入在可执行文件的 PE 标头中的 GUID 与其 PDB 相关联。您应该能够通过在可执行文件上运行 DUMPBIN /HEADERS 并查找调试目录的输出来查看它。如果您的压缩和加密修改了 PE 标头，导致此信息不可用（或不正确），那么它将解释为什么您的调试器找不到任何东西。
我认为您可以采取一些方法来解决此问题。要真正尝试使其工作，您可能需要考虑使用 WinDbg 而不是 Visual Studio 调试器。你马上就会明白我为什么推荐这个了……
WinDbg 提供了一些允许轻松加载符号文件的选项。此选项的想法是，如果源代码未更改但二进制文件来自与 PDB 不同的构建，则可以放弃 GUID 检查并且可以加载不匹配的符号文件。我不知道这对您的压缩和加密效果如何，所以 YMMV。
WinDbg 及其附带的工具可用于从可执行文件和 PDB 中转储 GUID，但我现在省略了这一点，因为我希望这些步骤不是必需的。
在 WinDbg 中打开 minidump 后，您需要在命令行中输入几个命令才能使这一切正常工作：
.symopt +0x40
!sym noisy
ld <exe name>
第一个命令启用SYMOPT_LOAD_ANYTHING跳过 GUID 检查的选项。该!sym命令启用符号加载的详细输出，以便您可以看到更详细的错误消息。该ld命令指示 WinDbg 尝试加载可执行文件名称的符号，您将在<exe name>. 如果您重复该ld命令，WinDbg 将指示它是否第一次成功加载符号。
希望这会有所帮助——再说一次，我不知道这对您的压缩和加密效果如何，但值得一试。
这种压缩/加密类似于 UPX 吗？如果二进制文件的实际可执行内容发生变化（就像使用 UPX 之类的工具所做的那样），那么您将不走运（除非您喜欢用汇编语言调试复杂的应用程序）。您的软件真的如此重要/特别，以至于它的二进制文件在交付之前需要加密吗？根据我的经验，调试故障转储的能力远比阻止人们对您的代码进行逆向工程重要得多。