use*_*807 4 assembly windbg reverse-engineering debug-symbols symbol-server
几天前，我在工作中遇到了这个问题，我想知道有没有办法从场景中挖掘出更多的数据，而不是去微软。已经有很多这样的案例，作为 Windows 开发人员，我想探索一下，获取大部分信息的最佳/最佳方式是什么。我来描述一下情况：
使用某些设置（涉及 cmyk 颜色空间）进行打印时，Office 应用程序会抛出一个对话框错误，其中描述错误。“文件 %s 无法打开，因为它被其他应用程序锁定”。它不提供文件名，事件查看器也不提供。打印中止。
在使用时procmon，我们发现当 apiCreatefileMapping被相关进程调用时，在几个文件上出现“文件锁定错误”，例如 office 应用程序、假脱机程序、splwow64.exe（是的，它是 64 位系统，应用程序是 32 位）。
当不涉及 splwow64 时，问题不存在，这意味着在 64 位操作系统上使用 64 位应用程序。
我想知道在这种情况下哪些工具对获取更多信息有用。这包括在需要时将 MS 符号与 windbg 和调试程序集一起使用。基本上我需要被锁定的文件名，它显示为 %s 和问题的根源。
没有源代码和符号的调试是很困难的。要采取的方法因您可以观察到的情况和可以做出的假设而异。以下对您的情况听起来很合理。
由于 64 位版本有效，看看文件访问的区别是什么。您可以将 Process Monitor 日志导出为 CSV 并编写一个分析文件访问的工具。您的分析工具可能应该
也许您甚至可以在 Excel 本身中做到这一点。
首先，我认为使用 Process Monitor 已经是一个很好的方法。你在不知道任何事情的情况下发现应用程序在做什么，所以这将是我的第一选择。
当然，很难缩小有问题的文件列表。如有必要，您需要浏览所有这些文件，例如在批处理文件的帮助下并找到一个命令行工具，该工具可以帮助查找打开文件的应用程序。在这种情况下，请查看SysInternals Handle。它是一个命令行实用程序，您可以为其指定一个文件名。基本上，它是 Process Explorer 的命令行版本（见下文）。
读取文件和写入文件通常是通过 API 调用完成的，因此API Monitor是另一种选择。过滤所有可疑的文件访问方法（ReadFile、ReadFileEx、LockFile、LockFileEx、WriteFile、WriteFileEx、...）。
这也可以在 WinDbg 中通过设置断点来实现，但您可能会经常遇到它们，因此处理它们可能需要一些自动化。您可以为命令指定一个命令字符串bp。
可能会发生打算用作%s格式字符串参数的文件名在内存中的某处。
C:\，D:\通过将其配管到etcfind命令或重定向到供以后分析的文本文件这仍然会给你留下很多文件，所以找到罪魁祸首并不比以前的方法容易得多。同样，使用其他工具缩小列表范围，例如handle。
du <address>因此在这里应该可以正常工作。这肯定需要更多关于内部内容的知识，例如在哪里可以找到好的指针等。
如果应用程序依赖于异常，您可能会通过检查第一次机会异常获得一些见解。但是，如果应用程序进行了良好的前提条件检查，则异常会更少，从而降低您获取有用信息的机会。
如果情况再现良好，您可以
.logopen /t /u c:\firstchanceexceptions.logsxe -c ".exr -1;k;g" *. 该g命令中的 将立即继续，以便应用程序（希望）不会遇到超时。g.logclosedu <address>）如果您无法确定哪个应用程序显示了错误消息，例如由于错误的消息标题，请执行以下操作：
将十字准线从工具栏拖到窗口上方。
进程资源管理器现在突出显示拥有窗口的可执行文件
如果对话框显示文件名而不仅仅是“%s”：
还可以使用进程资源管理器
使用查找/查找句柄或 DLL 或按Ctrl+F
键入文件名或文件名的一部分