Using MDMP Files
links to other articles to help integrate it into the encyclopedia. Please help improve this article by adding links that are relevant to the context within the existing text.January 2024
Contents
What Is an MDMP File?
When a 
Source game crashes, it creates a mini dump file. This file is like the black box recorder, it contains the last few moments before the program crashed. If you want to find the dumps created when your mod crashes, those files are usually located in 'Steam\dumps\'.
What Do I Need to Open the MDMP File?
Visual Studio and the .pdb (Program Debug Database) files for server.dll and client.dll. The .pdb file contains pointers to all the source code from your project. Having the file means you can see the code instead of trying to debug using assembly. You should never distribute your .pdb files with your mod.
The PDB files change every time you compile. You should keep the PDB files alongside every mod release. For your mod, you can simply made a new folder for each release and put the files in there.
These are example files stored in every build:
How to Debug
When you crash, look in your Half-Life 2 folder, the folder containing hl2.exe (This may be the HL2DM folder if you're using HL2DM as your mod's base). It should contain at least one mdmp file.
Grab the newest file and put it in the folder contaning your pdb files (If it crashed on your PC you can open it in place, moving it just fixes the paths so it can find the right files).
Now open the file, Visual Studio should start up. You might need to save a solution file. Press the start button (or F5) and it will recreate the crash, showing an error message, press Break.
Note:In Visual Studio 2010, press "Debug with Native Only" in the actions panel for this step.Now, if the crash was in code you have power over, you'll see the code. If not, you'll see a load of assembly crap.
Callstack
You can use the call stack window to find out what got you into this mess. If you don't see the callstack window, go to Debug menu > Windows > Callstack.
So what can we tell from this callstack:
- It crashed on the server (server.dll)
- It crashed after a bullet was fired (CBaseEntity::FireBullets)
- It crashed a jeep took damage (CPropJeep::OnTakeDamage)
- A combine soldier entity shot the bullet (CNPC_CombineS)
- It crashed when calling something in Lua (GMod specific)
Double clicking on any of the functions in the callstack window will take you to that place and show you exactly how it was called, and sometimes if you're lucky it will show the values of the variables, too.
No Code
If you don't see code then chances are that it can't find the PDB file or the PDB file it's found doesn't match the DLL that the client was using. You can check this for sure using the modules window.
There's a few useful things in this window.
- Timestamp—compare to the time on your local files to find the right version
- Information—will let you know if it's loaded the pdb or not
Modpath
If you can't/don't want to copy the .mdmp file over, you can add the modpath parameter to the "Command Arguments" field in the properties box.
MODPATH=c:/folder/that/contains/your/pdb/files/
Conclusion
Some crashes will be completely out of your reach. You'll get a mdmp file with just OS calls in it. You can either these down to drivers and spyware and ignore them or worry about something nasty like heap or stack corruption.
If you're anything like most users, 95% of your crashes will be invalid/null pointers. Having a mdmp file makes finding and fixing these bugs incredibly easy.
One thing to bear in mind when using a mdmp file is that just because it crashes in the end function - it doesn't mean that's the function that is at fault. Especially if it's a function that you haven't programmed. Try to find out what started the events leading up to the crash rather than what made it crash.
