结合托管和非托管代码的调试软件：

Ollydbg 可以很好地调试和运行托管代码（当然，在这种情况下，它仅作为本机调试器运行，而不像 DnSpy 那样完美地显示 .Net 功能和代码）。

有时，如果恶意软件对非托管代码（本机代码 DLL）进行大量调用，则使用像 OLLY 这样的调试器来跟踪向本机 DLL 的转换会方便得多。

这在 x32dbg/x64dbg 中根本不可能，并且在处理托管代码时会崩溃。

与 32 位系统的兼容性：

用于 x32dbg 的 ScyllaHide 不是很好，并且在 Windows 7 和 Windows 10（32 位）上失败。（它绝对不能在 Windows XP SP3 上运行，并且不断给我们带来 UNKNOWN SYSCALL 错误——所以我什至懒得在这种情况下提到 Win XP）。

我看到 GitHub 上有一个关于此的未决问题（对于 32 位 Windows 7 和 Windows 10），但那里的唯一答案似乎建议我们应该迁移到 64 位 Windows。

虽然这是真的，但很多时候我们需要在 32 位系统上工作，原因有很多。

如果没有一个好的系统来隐藏调试器免受大多数恶意软件的反调试调用，调试器基本上没有什么用处。

脚本引擎：

与 Olly Script 引擎相比，x32dbg/x64dbg 上的脚本插件非常慢。python脚本也是如此。

修补问题： 根据我的经验，在处理某些可执行文件时，使用 x32dbg/x64dbg 进行修补非常有问题，我发现我需要恢复到 Olly 以确保可执行文件得到可靠的修补。

更新问题：x32dbg/x64dbg 调试器的每次更新都会带来它自己的错误，在某种程度上，这让人想起 Windows 10 中的一个不断更新；)

在调试目标时，我们真的不需要不断思考是调试器的故障还是导致崩溃的目标程序！

简而言之，主要问题似乎是太多的程序员已经并且（仍在）以他们自己的编程风格在 x32dbg/x64dbg 上工作，并且调试器的整体结构似乎缺乏方向。

对于 Olly 来说，情况并非如此，因为它是由一个程序员创建的，因此它的结构清晰明了，很难用简单的术语来定义或描述。

这并不是说 x32dbg/x64dbg 不好。只是说还有很大的改进空间，让它像 Olly 一样可靠地运行。

这些只是我能记住的一些问题，这些问题一直让我不断地给我的旧 Olly 除尘并一次又一次地重新使用它。

免责声明：我是 x64dbg 的主要开发者，请考虑到这一点:)

我会说 OllyDbg 和 x64dbg 之间的主要区别在于 OllyDbg 根本不支持 64 位（操作系统）。如果您在现代系统上工作，我认为 x64dbg 是更好的选择，因为它旨在在那里工作。

也就是说，x64dbg 并不是在所有方面都更好。一个主要区别是 OllyDbg 有一个非常可靠的跟踪系统，而 x64dbg 有一些东西，但仍然需要大量的工作。我在工作中使用 x64dbg，但我熟悉源代码，因此我可以根据需要进行改进。

另一个很大的区别是您可以直接为 x64dbg 做出贡献。要么通过报告错误，要么只是自己修复它们。对我来说，这是一个很大的优势，因为 OllyDbg 的许多插件都会钩住内部函数来修复错误或添加功能。

除了自定义插件或隐藏的功能和可用性差异之外，真的没有动力OllyDbg过度使用x32dbg/x64dbg. 由于OllyDbg多年来一直选择调试器，因此需要一段时间才能运行。

也就是说，它对于具有丰富支持/插件生态系统的 32 位调试器仍然非常有能力（即使现在有点过时），因此如果您更喜欢它而不是任何其他 32 位调试器，那么使用它绝对没有错位应用。

就个人而言，我迁移到x32dbg/x64dbg很久OllyDbg以前，从那以后就再也没有错过。事实上，这种切换非常简单，人们大概可以通过使用调试器通过OllyDbg，然后x32dbg/x64dbg用很少的差异来弥补。

• x32dbg 不能在为调试或分析加载的 dll 中调用任意导出，ollydbg2 可以
• x32dbg 在附加/分离到 svchost.exe 时仍然崩溃 ollydbg2 可以毫无问题地处理它
• x32dbg 不能自动跟随子进程，ollydbg2 可以