Re-responses from Eric van Beurden:
hmm I still don't get how, in a generic way symbols could overlap the only think I could come up with if when static functions get automatically inlined by the compiler, but that's rather a different story (as I'd suspect the inlined function to be a single memory range within a container => and in that case returning the shortest matching symbol should be fine is there an existing exe/pdb file available for further testings
in testing with one of our projects, i was seeing symbols lookups fail 85-90% of the time with the initial versions of dbghelp. The PDB files that were being used were generated along with the release build of the project (it was a C++ project as well). On further investigation i found that the lookups were failing because many symbol addresses and ranges were overlapping. This seemed to occur on even unrelated objects and symbols. I would suspect it was the result of the optimizations the compiler performed.
I was able to generate PDBs that exhibited this behaviour with every test app i built under Visual Studio (v7.1 and 8.0Express); even apps that were only 25 lines long. Since it was very repeatable and the project in question would always be using PDBs generated from optimized release builds i decided to change the symbol lookup method to take the range into account and to be able to store a sublist of all symbols whose addresses fall into the same range (15-25% of the lookups still failed with just the range addition).
hmm still not sure it's the correct explanation... the 928k value is not that clear (and doesn't explain the impact of the order) I'd rather fear something like windbg mmaps the first meg of minidump upfront, and expects to get most the relevant information (the 5 listed streams, potentially header and data, in that mapping)... memory is likely to be used differently by another memory mapping, hence getting around the 1meg barrier (that's still needs to be further tested anyway)
Sorry, i don't think i explained it properly last time. The 928kb stream limiting change was incorrect and should be ignored now. It very well could be that windbg only mmaps the first 1MB of the file in an effort to find the SystemInfoStream information (and some others). The issue arose when we were performing a minidump that included a thread with an invalid ESP and EBP value in its Context struct. This resulted in us dumping the whole stack buffer (~1.14MB) for that thread instead of just the used area. Windbg refused to open the minidump after that. It complained that the SystemInfoStream could not be found (as it came after the MemoryListStream data in the file).
The stream reordering was done for a couple of reasons: - to put the smaller, fixed size, standard streams first in the file where windbg seemed to want them - to better match the stream ordering that native dbghelp wrote its minidump files in.
The stream ordering still isn't identical because native does things such as coalesce all strings into the same area of the minidump file (instead of putting each string immediately after the stream they belong to), and group stream data and non-stream data together.