这是一篇关于如何使用Map文件查找崩溃的好文章。
http://www.codeproject.com/KB/debug/mapfile.aspx
手动完成这一切是非常无趣的。
我不知道有什么工具可以读取Map文件，并帮助找到崩溃的位置。如果有人知道，请更新我们。

对于嵌入式系统，Map文件要有用得多。（尽管你不会使用VisualC ++;）
了解程序/数据内存的使用情况以及特定变量驻留的位置等都很重要。

WinDBG在分析.hdmp和.mdmp故障转储时，使用.map和.pdb文件帮助调试故障。

基本上，它们将内存地址偏移Map到.exe（和/或加载的.dll）中的函数和变量。一般来说，如果你需要找出客户不高兴的原因，这非常有用。当他们证明这不是你的错时，这就更有用了。
调试“事后分析”崩溃的最有用方法是使用 WinDbg（Windows平台）。打开它，打开崩溃转储。然后设置源路径指向代码（如果有）、指向.map和.pdb的符号路径以及.exe的图像路径，并在命令行中键入“！analyze-v”。现在您有了一个 * 完整的堆栈跟踪，其中包含代码行 * 和所有内容。当然，您需要有与正在调试的exe和DLL版本对应的正确版本的源代码。
如果路径中有MS符号服务器，并且打开了整页堆或adplus正在运行，那就更好了。特别是使用ADPlus时，您可能也会捕获到变量值。
我最喜欢的一些WinDbg资源：
第一站：http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx
强制加载符号：http://www.osronline.com/ShowThread.cfm?link=182377
有用的网站：：http://www.dumpanalysis.org/blog/index.php/category/windbg-tips-and-tricks/page/7/

您很少需要它们，但是它们可以方便地调试一些问题，因为它们提供了有关函数和数据位置的信息。
例如：

• 所有段的详细信息（代码、数据和其他）。
• 将行号链接到代码

可以将Map文件用作调试工具。

在大型项目中，当你需要跟踪编译单元和库之间的依赖关系时，链接器Map会非常有用。通常，链接器会报告一个导致问题的符号，而且通常情况下，简单地搜索这个符号名不会返回任何结果（或者对于read这样的符号会返回大量的误报）。
如果没有链接器Map，您唯一的选择就是分析所有可用的源文件（如果使用了宏，则在预处理通过之后，这是典型的情况），并希望找到相关的点。
链接器Map通常有一个称为“reference by file/symbol”的部分，它告诉你项目的另一个目标文件需要哪个目标文件，以及引用了哪个符号。
我曾经做过一个项目，它必须移植到一个没有本地化支持的系统上。链接器报告了“未定义对_localeconv_r的引用“错误，这将是一个痛苦的通过搜索源代码来跟踪。幸运的是，用-Map=output.map生成的GCC链接器Map文件通过一次搜索就揭示了所有有问题的函数。

amap cross-platform GUI tool允许您检查GCC、Visual Studio和其他一些编译器生成的MAP文件。例如，您可以找出每个源文件和每个外部依赖项对可执行文件大小的影响。