Minidump mod

After trying to debug some crashes, I decided to implement for CvGameCoreDLL a debugging feature that I'm accustomed to use: memory dumps.

A memory dump (also called minidump) is a snapshot of the memory state of a program, including only the information required to get a stacktrace. With this modification to CvGameCoreDLL, a memory dump file is created after a crash next to Civ4BeyondSword.exe. This file can be used by a developer to debug a crash that happened for someone else, as long as that person sends the developer the dmp file. To debug the crash, you only need to place the dmp file next to the executable (in our case Civ4BeyondSword.exe).

If our application (CvGameCoreDLL) has been compiled with enough debug information to generate a pdb file (/Zi in CFLAGS and /DEBUG in LDFLAGS) and that file can be found in the same folder where the original dll was compiled, opening the dmp file will start Visual Studio which will be able to start debugging in the same state in which the user initially had the crash.

As mentioned, for this to be useful, you need to compile a release version that generates debug symbols (or distribute a debug build). As far as I know, since the options explained above only affect the generation of the pdb file (they also add the path to the pdb file to CvGameCoreDLL), adding them to releases shouldn't have an impact in performance, but this claim is completely untested

The Express edition of Visual Studio 2010 can't open dmp files. You can use the Express edition of Visual Studio 2008, though.
It can be found here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14597

This small modcomp only contains two hunks of changes to CvGlobals.cpp, clearly labelled with "MINIDUMP_MOD". I'm uploading that file with my changes to this thread.

Very good. I have tried that out now and the resulting DLL does not seem to be any larger than usual and the Minidump is created on a crash.
Now I wonder how to interpret some of the info it yields. When I debug on the Minidump it gives a trace that says Line XXX + 0x20 or similar. Does that mean the crash occured at a CPU op belonging to that line? Could it be inlined? Can I find out which one?

Visual Studio uses the information in the generated pdb file to understand the crash dump files. You can customize the amount of information that is stored in your pdb file. In most makefiles for CVGamecoreDLL, release builds are set to "store only symbol names", which means that it will be missing the code lines of each entry of the stacktrace.

If you want to get better crash dumps with this modcomp, you need to modify your makefile (adding /Zi in CFLAGS and /DEBUG in LDFLAGS). Check the discussion starting here for more details and a makefile example.

Sorry but... why? This functionality already exist in civ 4, you can set it to generate crash dumps in the ini file.

I did not know that it already existed, I'll try that

Hey Tekhen!
Sry for resurrecting this old thread, but I'm really curious
How were you able to check those .dmp files with Visual Studio?

I can attach my .dll, the symbol files (.pdb), and the source code itself to the dump file.
But VS still asks for the pdb files for the Civ4BeyondSword.exe too, which I obviously don't have.
Firaxis never released those AFAIK.
From the OP of this thread it seems you were still be able to open and use your dump files
Can you help me how you do it? What's your workaroud?

AbsintheRed said:

Hey Tekhen!
Sry for resurrecting this old thread, but I'm really curious
How were you able to check those .dmp files with Visual Studio?

I can attach my .dll, the symbol files (.pdb), and the source code itself to the dump file.
But VS still asks for the pdb files for the Civ4BeyondSword.exe too, which I obviously don't have.
Firaxis never released those AFAIK.
From the OP of this thread it seems you were still be able to open and use your dump files
Can you help me how you do it? What's your workaroud?

Click to expand...

Just ignore if VS asks you for the pdb file for the Civ4BeyondSword.exe by clicking yes. You can still see where in the dll crash happens and if it crashes in the exe you see that too but only the diassembly.

Ohh, that's why I was confused, I only have the disassembly.
So this means it crashes in the exe... that's not very good news :/