我在现场的某个特定软件上弹出一个完全随机的错误。该应用程序是一个用VB6编写的游戏，运行在64位Windows 7上。每隔一段时间，应用程序崩溃，通用“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中缺少符号。那里有任何线索吗？
答案 0 :(得分：6)
来自应用程序事件日志的消息没有那么有用 - 您需要的是从您的进程中进行事后处理转储 - 这样您就可以看到代码中的某些内容出现了问题。
每当我看到其中一个问题时，它通常归结为一个糟糕的API参数，而不是更具异国情调的东西，这可能是由于数据输入不良引起的，但通常它是一个很好的形状错误导致问题
正如您可能已经想到的那样，调试并不容易;理想情况下，你有一个可重复的失败案例来调试，而不是依赖于从远程机器捕获转储文件，但直到你可以使它成为可重复的远程转储是唯一的方法。
Watson博士曾经这样做，但不再发货，所以替代方案是：
你需要得到的是一个minidump，它们包含进程空间的重要部分，不包括标准模块（例如Kernel32.dll） - 并用版本号替换转储。
有Automatically Capturing a Dump When a Process Crashes的说明 - 它使用调试工具附带的cdb.exe，但关键项是注册表项\\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
您可以更改代码以添加更好的错误处理 - 如果您可以将原因缩小到几个程序并使用Using symbolic debug information to locate a program crash.中描述的技术直接处理地图文件，这将非常有用。
一旦你有了一个minidump并且符号文件WinDbg是挖掘这些转储的首选工具 - 但是，发现原因可能是一次航行。
我要考虑的另一件事，这取决于你的应用程序结构，是尝试捕获所有输入事件以进行重放。
另一个选择是查找具有replay debugging的VMWare 7.1的副本，并将其作为捕获可重现步骤集的第一步。
答案 1 :(得分：0)
右键单击您的可执行对象，让它与WINXP兼容挂起 当你发现问题的根源以最终解决它时