对于没有源代码的随机崩溃应用，我们可以做些什么？

Question

我正在努力帮助客户解决问题，但我的想法已经不多了。他们有一个定制的，内部编写的应用程序，按计划运行，但它崩溃了。我不知道它有多久这样，所以我认为我不能将崩溃追溯到任何特定的软件更新。最不幸的是，VB6 DLL不再包含任何逻辑内容的源代码。

这个VB6 DLL由来自VB脚本的2-3个函数调用启动。显然，我可以修改VB脚本以添加错误记录，但是我没有太多运气获得质量信息来查明崩溃的来源。我已将记录消息放在所有函数调用的任一侧，并确定哪些调用导致崩溃。但是，错误对象中没有返回任何内容，因为调用正在崩溃wscript.exe。

我不确定我能做些什么。有什么想法吗？

编辑：我关心的主要原因，即使我没有源代码，可能会有一些外部因素导致崩溃（凭据不足，锁定文件等）。我检查了由于wscript.exe崩溃而在drwtsn32.log中创建的日志文件，我得到的唯一信息是“访问冲突”。

我首先倾向于认为这与安全权限有关，但这也不是内存访问冲突吗？

Answer 1

如果您认为这是环境问题（如文件权限），您可以考虑使用其中一个Sysinternals工具。我曾经使用Filemon找出我的应用程序所触及的所有文件，并发现了一个问题。

您可能还希望使用Dependency Walker进行快速健全性检查，以确保您实际上正在加载您认为自己的DLL文件。我已经看到加载了C运行时的错误版本并导致了一次神秘的崩溃。

Answer 2

根据应用程序的范围，您的客户可能需要考虑重写。如果没有源代码，当其他东西发生变化时，他们最终将被迫这样做。

Answer 3

总是可以使用调试器 - 直接在运行崩溃应用程序的PC上或在内存转储上 - 来确定或多或少地发生了什么。在这种情况下，代码是VB6，这可能不是很有用，因为你只能在Win32级别获得有用的信息。

最终，如果你没有源代码，那么将找出bug真正有用的地方？除非您可以在调用脚本中永远避免使用该代码路径，否则无论如何都无法修复它。

Answer 4

您可以使用the debugging tools for windows。这可能有助于您查明错误，但如果没有来源修复它，对您没有多大帮助。

更懒惰的方法是从代码（而不是脚本）调用dll，这样你至少可以看到导致问题的原因并检查错误的对象。你仍然无法修复它，除非问题是它被错误地调用。

Answer 5

Coding The Wheel的家伙有一个非常有趣的系列关于构建一个充满严谨的技术信息的在线扑克机器人，其中很多涉及如何进入现有应用程序并弄乱它们，这是在某种程度上，你想做什么。

具体来说，他有an article on using WinDbg to get at important info，一个how to bend function calls to your own code和one on injecting DLLs in other processes。这些技术可能有助于找到并可能解决或修复崩溃，虽然我猜这仍然是一个艰难的电话。

Answer 6

有一些工具可能会有所帮助。首先，您可以使用依赖性walker来执行应用程序的运行时配置文件：

http://www.dependencywalker.com/

有一个配置文件菜单，您可能希望确保选中了跟随子进程选项。这将做两件事。首先，它将允许您查看所有被拉入的lib版本。这可能对某些问题有所帮助。其次，运行时配置文件在运行子进程时使用调试内存管理器。因此，您将能够看到缓冲区是否会溢出以及有关该缓冲区的一些信息。

另一个有用的工具是Mark Russinovich的过程监控器：

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

此工具将报告所有文件，注册表和线程操作。这将帮助您确定是否存在任何文件或注册表凭据问题。

Process explorer为您提供了许多相同的信息：

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

这也是Russinovich工具。我发现通过这个工具查看一些数据要容易一些。

最后，使用windows或dev studio的调试工具可以让您深入了解错误发生的位置。

Answer 7

访问冲突几乎总是内存错误 - 在这种情况下更可能是因为它的随机崩溃（权限可能更明显可重现）。在dll的情况下，它可能是

1. dll本身的代码出错 - 这可能是内存分配错误，甚至是简单的循环边界条件错误。

2. 当dll尝试链接到系统上的另一个dll时出错。这通常是由机器上的dll版本不匹配引起的。

您的第一步应该是尝试获得可重现的崩溃条件。如果您没有一系列会导致系统崩溃的情况，那么您无法知道何时修复它。

然后我会在干净的机器上安装系统并尝试重现该错误。运行监视器并在程序崩溃时准确检查其他文件（dll等）是否打开。我已经看到代码在超线程Pentium上崩溃但在早期版本上没有崩溃 - 因此将旧机器恢复为测试平台可能是一个很好的选择来覆盖那个。改变机器中的撞锤数量也是值得的。

希望这些步骤可能会给你一些线索。希望这将是一个环境问题，所以可以通过使用正确版本的Windows，dll等来避免。但是，如果你仍然坚持崩溃此时没有好的线索，那么你的选择是要么重写或尝试通过在汇编程序控制器上调试dll或拆卸它来进一步解决问题。如果你不熟悉汇编代码，那么这两个都是长镜头，你很难看到你将获得什么 - 而且任何一个选项都可能是一个巨大的时间汇。我自己过去曾经遇到过这样一个特别低级别的高强度问题，这个问题就像在“雇用编码器”网站上做广告一样，并寻找具有专业知识的人。同样，您需要一个可重现的错误才能执行此操作。

从长远来看，必须更换没有源代码的dll。支付具有装配技能的专家来分析功能并为您提供流程图可能值得考虑。以一种受控的方式比以后更快地完成这项工作是一种很好的商业惯例 - 比如在它运行的机器崩溃后，该版本的窗口不再容易获得。

Answer 8

您可能想尝试使用Resource Hacker，您可能很幸运需要对内部应用程序进行反编译。它可能不会给你完整的源代码，但至少可能会有更多关于应用程序正在做什么的信息，这也可以帮助你确定你的culrpit。

Answer 9

将最大可能的RAM添加到计算机

这个简单而便宜的黑客过去对我有用。当然是YMMV。

Answer 10

逆向工程是一种可能性，虽然是艰难的 从理论上讲，你可以反编译，甚至可以调试/跟踪一个已编译的VB6应用程序 - 这是一个简单的部分，在没有源代码的情况下修改它，除了最简单的情况之外，都是困难的部分。

免费编译器/反编译器：

VB decompilers

VB debuggers

在大多数情况下，重写是解决问题的更成功和更快捷的方法。