title: How to perform advanced search of all process memory from Visual Studio debugger?
body: <p>I am a developer on a large commercial program, and I am trying to track down a particular C++ memory leak.  I would like to use Visual Studio to search the entire valid address space of my process, but I can not see how to perform this search effectively.</p>
  
  <p>I am aware of the .s command documentation <a href="http://msdn.microsoft.com/en-us/library/ms171363%28VS.80%29.aspx" rel="nofollow">here</a>, but it is not doing what I need.  For examle, I am 100% certain that the address 0xfdfd240 contains the value 0x0f0e34a8.  I can successfully use the .s command to search near that address like this:</p>
  
  <pre><code>.s -d 0x0fdfd200 L256000000 0x0f0e34a8
  Found match at
  0xfdfd240
  </code></pre>
  
  <p>But my program has made many small allocations which have left me with many small non-contiguious sections of memory.  If I back up a few thousand bytes the search command fails:</p>
  
  <pre><code>.s -d 0x0fd00000 L256000000 0x0f0e34a8
  Memory location could not be read. Please specify a valid memory location.
  </code></pre>
  
  <p>And it also appears that the search command does not attempt to search forward any more when it finds it's first bad address, <em>even if there are valid addresses beyond it</em>.</p>
  
  <pre><code>.s -d 0x0f000000 L256000000 0x0f0e34a8
  No match was found
  </code></pre>
  
  <p>I'm vaguely aware that there is a way to ask windows what memory ranges are valid for a given process, so I'm considering writing a small throwaway program to harvest that information and then automate a series of search commands to the Immediate Window...but it seems like someone must have dealt with this before, and must have done something smarter.</p>
  
  <p>Also, I can extract a dump file of the running process, so if anyone can recommend third party tools to feed the dump to that has stronger search functionality that should work out as well.</p>
  
  <p>Any suggestions?</p>
  
  <p>Edit:  I see this behavior in VS2008SP1 and VS2010SP1.</p>