5

How can I search a string in a large MEMORY.DMP file generated by Windows BSOD (Windows 8.1 64 bit)?

On 32-bit Windows, the command

s -a 0 ffffffff "my pattern"

seems to work.

But for 64-bit windows, 

s -a 0 ffffffff`ffffffff "my pattern"

takes almost infinite time, even though the total size of the MEMORY.DMP is about 400MB only, while a simple grep can find the pattern within seconds.

My goal is to find the virtual address of the string to determine which stack/heap/text area is overwritten by it.

I would finally resort to interpret the file format of MEMORY.DMP by hand if the reference or specification of the file format is available. Any hints?

murali
  • 59
  • 1
  • 4
  • Do you get many findings, e.g. > 1000 addresses? – Thomas Weller Sep 02 '15 at 10:56
  • @Thomas I didn't get any finding when trying the `s` command and WinDbg just kept "*BUSY*" on searching. In fact there is only one instance of the pattern in the dump. I know where it is in the file, just don't know how to translate it into virtual address. – murali Sep 02 '15 at 11:02
  • Ok, I see. In case of many findings, I observed that WinDbg is so slow because it needs to print everything on its GUI. – Thomas Weller Sep 02 '15 at 11:06
  • BTW something [similar here](http://stackoverflow.com/a/32340474/4136325) worked nicely, but that's a user mode dump, not a kernel dump. May it depends on the WinDbg version? Did you try [Version 10](http://debugging.wellisolutions.de/windbg-versions/)? It also works on Win 7. – Thomas Weller Sep 02 '15 at 11:08
  • @Thomas The 'Version 10' WinDbg in the link seemingly doesn't contain the executable, only samples and libraries after installing. I tried the latest release WinDbg 6.3.9600.17298 and it exhibit the same behavior. I also tried [the solution](http://stackoverflow.com/a/32340474/4136325), but it hangs there as well. – murali Sep 03 '15 at 06:19
  • The [x64 msi](http://codemachine.com/downloads/win10/X64%20Debuggers%20And%20Tools-x64_en-us.msi) and [x86 msi](http://codemachine.com/downloads/win10/X86%20Debuggers%20And%20Tools-x86_en-us.msi) should contain the debugger, but ok, version 6.3 is quite recent and should do for this purpose. – Thomas Weller Sep 03 '15 at 06:48
  • Could you provide the dump to me so that I could reproduce the issue and (perhaps) find a solution? I can sign an NDA if needed. – Thomas Weller Sep 17 '15 at 13:04
  • @Thomas Unfortunately the memory dumps belong to our client and they are fairly huge (8GB). – murali Sep 21 '15 at 02:03

1 Answers1

0

Currently this is how I do it:

  1. !heap -a

Which will provide some output like below:

HEAPEXT: Unable to get address of ntdll!RtlpHeapInvalidBadAddress. Index   Address  Name      Debugging options enabled   1:   1b9be450000 
    Segment at 000001b9be450000 to 000001b9be54f000 (0008b000 bytes committed)   2:   1b9be1f0000 
    Segment at 000001b9be1f0000 to 000001b9be200000 (00001000 bytes committed)   3:   1b9bfe10000 
    Segment at 000001b9bfe10000 to 000001b9bfe1f000 (0000f000 bytes committed)
    Segment at 000001b9c3a40000 to 000001b9c3b3f000 (00005000 bytes committed)   4:   1b9be440000 
    Segment at 000001b9be440000 to 000001b9be44f000 (00007000 bytes committed)
  1. Search between the start and end addresses of each segment until you find your data
  2. For example: s -a 000001b9be450000 000001b9be54f000 "my pattern"

This may not work in every scenario but for me it allowed me to find the data I was looking for.

Malcolm McCaffery
  • 2,468
  • 1
  • 22
  • 43