Using MAP file VS2010 MFC

Question

I've developed a program by a customer who's experiencing when he do a certain operation. This isn't happening always on the same place and on the same data and, moreover, it is not happening nor in my local developing machine nor in my test Virtual Machine (which is free of all developing equipment).

Given these conditions, I've decided to compile with MAP (enabled in Configuring Properties-> Linker->Debugger with option /MAP) to see which function is causing crash.

If I've correctly understood, when the program crash I've to check down the offset error and then, search in my MAP under the column RVA+BASE:

     Address                         Publics by Value                                      Rva+Base       Lib:Object
 0001:00037af0       ?PersonalizzaPlancia@CDlgGestioneDatiProgetto@MosaicoDialogs@@IAEXXZ 00438af0 f   DlgGestioneDatiProgetto.obj
 0001:00038000       ?SalvaTemporanei@CDlgGestioneDatiProgetto@MosaicoDialogs@@IAEXXZ 00439000 f   DlgGestioneDatiProgetto.obj

Actually, my crash happens at offset:

00038C90

So I should think that it's somewhere in the method:

MosaicoDialogs::CDlgGestioneDatiProgetto::PersonalizzaPlancia

but this is not absolutely possible, so assuming that the computer can't be wrong, I'm the one who's doing it bad.

Can someone explain me how to read MAP in correct way?

Answer 1

Reading of MAP files to find out crash location is explained nicely in this code project article.

http://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file

Hope helps.

Answer 2

don't bother - instead, build the project with symbols enabled and strip them into a pdb file.

Modify the program a little, to write a minidump when it crashes using a unhandled exception handler

Give the newly compiled program to the customer, and when it crashes call MiniDumpWriteDump.

Ask the customer to send this .dmp file to you, and you then simply load it up in Visual Studio (or WinDbg) and it will match up the symbols to the program, and will also match up the code. You should be able to see the exact line of code and some of the variables involved. (if using VS, when you load the .dmp file, top right corner will be an option to "start debugging" click that as it will 'start debugging' at the point of the crash)

Try it first locally - put a div by zero error somewhere in your program and see if you can debug the dump after its been run. Note that you must keep the exact same symbol file for each build of your program - they match exactly. You cannot expect a symbol file for one build to match another build, even if nothing changed.

There are tutorials for this kind of thing, such as this one from CodeProject that looks like it describes what you need.

Answer 3

For postmortem debugging, there's an alternative that would not required the use of a map file. Rather, it would require you to create a simple registry script to enable some WER (Windows Error Reporting) flags to trap the crash dump file. First, build your application with debug symbols. Then, follow the instructions for Collecting User-Mode Dumps. Basically, you create a sub key under the "LocalDumps" key. This sub key must be the name of your application, for example, "myapplication.exe". Then, create the "DumpCount", "DumpType", and "DumpFolder" keys/values. Have the user run the registry script. This will enable trapping the dump locally. Then, have the user force the crash to collect the dump file. The user can then send the dump file to you to debug using the symbols you created earlier. Lastly, you'll need to create a registry script that removes the keys/values you added to the registry.