【问题标题】:Debugging/troubleshooting windows applications without source code在没有源代码的情况下调试/故障排除 Windows 应用程序
【发布时间】:2014-05-30 17:34:42
【问题描述】:

几天前,我在工作中遇到了这个问题,我想知道有没有办法从场景中提取更多数据而不是去微软。有很多这样的案例,我想探索作为一个 Windows 开发人员,获取大部分信息的最佳/最佳方式是这种情况。我将描述情况:

  1. Office 应用程序在使用某些设置(涉及 cmyk 色彩空间)进行打印时会引发一个对话框错误,该对话框的描述错误。“文件 %s 无法打开,因为它已被其他应用程序锁定”。它不提供文件名,事件查看器也不提供。打印中止。

  2. 在使用procmon 时,当 api CreatefileMapping 被涉及的进程(如办公应用程序、假脱机程序、splwow64.exe 是的,它是 64 位系统和该应用程序是 32 位的)。

  3. 不涉及 splwow64 时问题不存在,意味着在 64 位操作系统上使用 64 位应用程序。

我想知道在这种情况下哪些工具有助于获取更多信息。这包括在需要时将 MS 符号与 windbg 和调试程序集一起使用。基本上我需要锁定的文件名,显示为 %s 和问题的根源。

【问题讨论】:

  • ProcMon 怎么回事,找不到文件名?
  • 有多个文件报告了相同的问题。我想指出实际文件和根本原因。寻找一些可能有助于深入研究这些场景的方法。
  • 文件名可能已经消失,因为消息显示的时间比实际文件访问要晚得多。你能创建一个splwow64.exe 的转储,在WinDbg 中打开它并执行.symfix c:\symbols;~*kb 以便我们有一个起点吗?
  • 您是否尝试过捕获第一次机会异常并使用 procdump 创建转储?

标签: assembly reverse-engineering windbg debug-symbols symbol-server


【解决方案1】:

没有源代码和没有符号的调试很困难。所采取的方法因您可以观察到的内容和可以做出的假设而有很大差异。以下听起来对您的情况是合理的。

区分 64 位文件访问与 32 位版本

由于 64 位版本可以工作,看看文件访问的区别是什么。您可以将 Process Monitor 日志导出为 CSV,并编写一个分析文件访问的工具。您的分析工具可能应该

  • 将具有不同偏移量的多个文件读取访问汇总为整个文件的单个文件访问。
  • 忽略读取顺序,因为顺序似乎不太重要。
  • 首先忽略 DLL

也许您甚至可以在 Excel 本身中做到这一点。

捕获文件访问调用

首先,我认为使用 Process Monitor 已经是一个好方法。您可以在不了解应用程序的情况下了解应用程序在做什么,所以这将是我的首选。

当然,要缩小有问题的文件列表是很困难的。如有必要,您需要通过所有这些,例如在批处理文件的帮助下,找到一个命令行工具,可以帮助找到打开文件的应用程序。在这种情况下,请查看SysInternals Handle。它是一个命令行实用程序,您可以给它一个文件名。基本上,它是 Process Explorer 的命令行版本(见下文)。

读取文件和写入文件通常是通过API调用完成的,所以API Monitor是另一种选择。过滤所有可疑的文件访问方法(ReadFile、ReadFileEx、LockFile、LockFileEx、WriteFile、WriteFileEx,...)。

这也可以在 WinDbg 中通过设置断点来实现,但您可能会经常遇到它们,因此处理它们可能需要一些自动化。您可以为bp 命令指定一个命令字符串。

祝你好运

可能会发生打算用作%s 格式字符串参数的文件名在内存中的某个位置。

  1. 在应用程序显示消息时进行故障转储
  2. 使用SysInternals Strings 实用程序转储转储的所有字符串。
  3. 通过管道将其直接输出到C:\D:\ 等的过滤器通过管道传送到find 命令或将其重定向到文本文件以供以后分析

这仍然会给您留下很多文件,因此找到罪魁祸首并不比以前的方法容易得多。同样,使用其他工具缩小列表范围,例如handle.

  1. 在应用程序显示消息时进行故障转储
  2. 在 WinDbg 中打开转储
  3. 为您在堆栈中找到的某些地址转储字符串。由于 NTFS 中的文件名是 Unicode,du <address> 在这里应该可以正常工作。

这肯定需要更多关于内部知识的知识,例如在哪里可以找到好的指针等。

分析第一次机会异常

如果应用程序依赖于异常,您可以通过检查第一次机会异常来获得一些洞察力。但是,如果应用程序进行了良好的先决条件检查,异常情况就会减少,从而降低您获取有用信息的机会。

如果情况重现良好,您可以

  1. 使用 Image File Execution Options 将 WinDbg 设置为该进程的调试器。
  2. 使用.logopen /t /u c:\firstchanceexceptions.log 打开一个日志文件
  3. 使用sxe -c ".exr -1;k;g" * 转储所有异常。该命令中的g 将立即继续,以便应用程序(希望)不会遇到超时。
  4. 使用g 继续执行
  5. 当应用程序终止时,用.logclose关闭日志文件
  6. 查看日志文件以了解有趣的异常/有趣的调用堆栈
  7. 重现错误,但这次停止有趣的异常
  8. 查看方法参数和内存是否找到文件名(再次使用du <address>

查找属于消息框的应用程序

如果您无法确定哪个应用程序显示错误消息,例如由于消息标题错误,请执行以下操作:

  1. 下载SysInternals Process Explorer并运行它。

  2. 将工具栏中的十字线拖到窗口上方。

  3. Process Explorer 现在突出显示拥有该窗口的可执行文件

如果打印文件名则查找锁定应用程序

如果对话框显示文件名而不仅仅是“%s”:

  1. 也可以使用进程资源管理器

  2. 使用查找/查找句柄或 DLL 或按 Ctrl+F

  3. 输入文件名或部分文件名

【讨论】:

  • 很多有用的输入。谢谢他们。我将继续对这些方面进行调查。
  • "在这种情况下,请查看 SysInternals Handle。它是一个命令行实用程序,您可以给它一个文件名。基本上,它是 DOS 版本的 Process Explorer(见下文)。"最近基于 NT 的 MSWindows 系统并不将 DOS 用于所有命令行应用程序。事实上,在 64 位系统上,甚至不再包含 NTVDM 兼容 DOS 框。所以这个工具绝对不是任何东西的“DOS版本”。
  • @ecm: 当然,Windows 中不再有 DOS。我现在把它改成了“命令行”
猜你喜欢
  • 2012-08-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-11-03
  • 2018-08-14
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多