我有一个程序冻结（特别是sql开发人员），其中有一些未保存的文件。 我使用sysinternal的进程资源管理器在杀死进程之前创建转储文件。 我真的只失去了几个小时的工作，但我认为看看我可以从转储文件中提取的内容是一个很好的学习经验。 到目前为止，我已经下载并运行了windbg并找到了我的文本：
s -u 0x00000000 L?0xffffffff "text I know exists in my file"从那里我得到了相关的内存地址，可以查看内存窗口中的文本以及大部分文件。 但是，从这里我有点卡住了。 我知道我可以使用du命令来转储文本，但我应该使用什么样的策略来确定开始和结束范围。 这是一个1千兆转储，所以我永远不会将0x00000000转储到0xffffffff，因为我没有大多数编辑器可以打开的文本文件。 有没有办法只是转储用户内存或非代码内存等？ 它无论如何都不一定是完美的。 我满足于只在文本板中打开转储文件，但是unicode数据没有显示，只显示了ascii（可能是因为textpad无法检测到类型，或者因为它是64位转储）。
I had a program freeze (sql developer specifically) that had some unsaved files in it. I used sysinternal's process explorer to create a dump file before killing the process. I really only lost a couple of hours of work but I thought it would be a good learning experience to see what I could extract from the dump file. So far I've downloaded and ran windbg and have found my text with:
s -u 0x00000000 L?0xffffffff "text I know exists in my file"From there I got the relevent memory addresses and could view the text in the memory window along with much of the file. However, from here I'm a bit stuck. I know I could use the du command to dump text but what sort of strategy should I use to determine the begin and end range. This is a 1 Gig dump so I'm nevervous to dump 0x00000000 to 0xffffffff as I wouldn't have text file that most editors could open. Is there a way to just dump user memory or non-code memory, etc? It doesn't have to be perfect by any means. I was content just opening the dump file in textpad, but unicode data doesn't show up, only the occational ascii (presumably because textpad cant detect the type or because it's a 64 bit dump).
最满意答案
您还可以尝试sysinternals（现在为MS）中的strings.exe实用程序，并将所有输出（unicode和ascii）重定向到文本文件。 然后搜索文本文件（或只是眼球）以寻找您正在寻找的内容。
You could also try the strings.exe utility from sysinternals (now MS) and just redirect all the output (unicode and ascii) to a text file. Then search the text file (or just eye-ball it) for what you're looking for.
更多推荐
发布评论