I think we've been going about this in the wrong way. The documented functions for querying and walking used memory only give back a subset of the total memory a process has access to. The working set doesn't necessarily contain all referenceable memory, likewise allocated memory doesn't have to come from a heap. Since there doesn't seem to be a public way to access the address and extents of just which vm regions are valid (short of VirtualQueryExing every page), the dump and inspect method isn't viable for total coverage.
I thought of minidumping the process which can bring in all allocated memory, and querying the dump file for info but that obviously wouldn't scale very well, and there's a snag in that the dmp file doesn't seem to be (well) documented. Searching for the format lead me to
this, and the idea of leveraging the same interfaces as WinDbg, which just happens to contain a method that can search for an arbitrary value in a specified virtual memory range of an attached process.
I tested this with cmd.exe and it returned where the MZ dos header was for all loaded modules so it seems to work well for small values at least. I'm not saying this is the best method, but it seems a more complete and simpler method to use and build upon than the enumeration of pages and heap block approaches. With the immediate downside being that it won't work on Win2k as-is due to the use of DebugBreakProcess to trigger the initial debug event.
I got the impression that the OP is simply looking for a certain value in memory and not specifically to dump it. If dumping is what's required, you can use the same framework, just dump the process with
MiniDumpWriteDump and change
pClient->AttachProcess
to
pClient->OpenDumpFile(dumpfile)
Anyway, enough rambling.