2

我在现场的某个特定软件上弹出了一个完全随机的错误。该应用程序是用 VB6 编写的游戏，在 Windows 7 64 位上运行。每隔一段时间，应用程序就会崩溃，并出现一个通用的“program.exe 已停止响应”消息框。该游戏可以连续几天正常运行，直到出现此消息，或者在几个小时内。没有异常被抛出。

我们以 Windows 2000 兼容模式（这是它的原始操作系统）运行此应用程序，禁用视觉主题，并以管理员身份运行。应用程序本身在使用外部组件和 API 调用方面非常简单。

参考：

Visual Basic for Applications
Visual Basic 运行时对象和过程
Visual Basic 对象和过程
OLE 自动化
Microsoft DAO 3.51 对象库
Microsoft 数据格式化对象库

组件：

Microsoft Comm Control 6.0
Microsoft Windows Common Controls 6.0 (SP6)
Resizer XT

如您所见，这些工具大部分都是非常简单的 Microsoft 标准工具。数据库组件的存在是为了与用于记账的 Access 数据库进行交互，并且插入了Resizer XT以更轻松地将这款游戏从原来的 800x600 分辨率移动到 1920x1080。

信息亭没有启用网络；没有网络驱动程序，因此没有与远程数据库的连接。一切都封装在一个盒子里。

在 Windows 应用程序事件日志中，当发生这种情况时，有一个事件 ID 1000 导致看似随机的模块出现故障 - 到目前为止，要么是 ntdll.dll 要么是 lpk.dll。在 API 调用方面，我没有看到任何来自 ntdll.dll 的内容。我们将 kernel32、user32 和 winmm 用于各种文件系统和声音功能。我无法重现，因为它是完全随机的，所以我什至不知道从哪里开始进行故障排除。有任何想法吗？

编辑：更多信息。在其他一些开发人员的建议下，我尝试了几个不同版本的 Dependency Walker，最新版本显示我缺少 IESHIMS.dll 和 GRPSVC.dll（这两个似乎是 Depends.exe 中众所周知的错误） ，并且我在 COMCTRL32.dll 和 IEFRAME.dll 中缺少符号。那里有任何线索吗？

4

2 回答 2

6

来自应用程序事件日志的消息并没有那么有用——您需要的是从您的进程中进行的事后进程转储——这样您就可以看到代码中哪里开始出错了。

每次我看到其中一个问题时，它通常归结为错误的 API 参数，而不是更奇特的东西，这可能是由于传入的错误数据造成的，但通常是一个很好的老式错误导致了问题。

正如您可能已经想到的那样，调试起来并不容易；理想情况下，您将有一个可重复的故障案例进行调试，而不是依赖于从远程机器捕获转储文件，但直到您可以使其可重复远程转储是唯一的前进方式。

沃森博士曾经这样做，但不再发货，因此替代方案是：

您需要得到一个小型转储，其中包含进程空间的重要部分，不包括标准模块（例如 Kernel32.dll） - 并将转储替换为版本号。

有关于在进程崩溃时自动捕获转储的说明- 它使用调试工具附带的 cdb.exe，但关键项是注册表项\\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug

您可以更改代码以添加更好的错误处理 - 如果您可以将原因缩小到几个过程并使用使用符号调试信息来定位程序崩溃中描述的技术，则特别有用。直接处理地图文件。

一旦你有了一个小型转储和符号文件，WinDbg 是挖掘这些转储的首选工具 - 但是发现原因可能需要一点时间。

我要考虑的唯一另一件事是尝试捕获所有输入事件以进行重播，这取决于您的应用程序结构。

另一种选择是找到具有重放调试功能的 VMWare 7.1 副本，并将其用作捕获可重现步骤集的第一步。

于 2012-08-07T09:26:41.247 回答
0

右键单击您的可执行对象，并在您发现问题根源时让它与 WINXP 兼容待定以最终解决它

于 2016-11-16T15:28:33.027 回答