Debugging the Mass Effect Trilogy
Debugging issues in the Mass Effect trilogy can be difficult, especially if you don't know where to begin. As a developer, you should ensure you're taking consistent snapshots of your mod, as an issue that appears at one point may be triggered by changes further back then your last save. Many modders have learned the hard way when working on mods that a backup saves valuable time - once your file is broken, without a backup you have no way to get it back without recreating it.
Depending on which game you are modding, you will have different tools available. In order of how "easy" it is to debug a game, Mass Effect 3 is the easiest, followed by Mass Effect, and finally ending with the 'cursed' Mass Effect 2.
Each game has specific debugging tools for the game, in addition to the global tools we'll discuss below. ASI mods are native code mods that run along with the game and can provide additional features.
Mass Effect conveniently outputs program logs, which include crash error messages for some crashes. It is by far the most useful output, but it only typically only helps with crashes. The native SDK we have for ME1 is built differently than ME2/ME3 and is not easy to use, and as such, there are no game-hooking ASIs.
- The application log located in Documents/BioWare/Mass Effect/Logs
Mass Effect 2 removed the logging feature from the first game, as well as fully stripping out any useful debug methods. As such there is no way for us to tell why the game crashed (without resorting to a debugger & disasembler), or see internal debug methods (such as ClientMessage), which means developing mods for ME2 can be very frustrating when the game begins to crash.
- Kismet Logger ASI
- Function Logger ASI
- Streaming Levels HUD ASI
Mass Effect 3 does not have a logging feature, but they left an internal native method stub for 'appErrorF', which is the internal procedure call for logging error messages. By default this was a stub and did nothing, but with the ME3 Logger ASI installed, calls to this method are logged. It only catches handled error messages and crashes, unhandled errors that crash the application are unlikely to be logged. Common output from this log includes bad import/export/name index, I/O error operation on files, Serial Size mismatch, incorrect class declarations, and more.
- Kismet Logger ASI
- Function Logger ASI
- Streaming Levels HUD ASI
- ME3Logger ASI
P L A C E H O L D E R
Topics include:
- Available debugging tools for each game
- ProcMon tutorial debugging
- ME3Logger + ME3Explorer debugging
- Mod Manager debugging
Process Monitor is a very useful utility that logs tons of things a process does, from file reading, registry key reading, subprocess start/stop, thread start/stop... While a lot of these features are not useful to us, ones such as ReadFile are. We're going to go through a scenario and use ProcMon to try and identify the issue.
You'll need to download ProcMon to get started, which you can download from Microsoft. Extract it, run it, and accept the EULA.
ProcMon logs everything by default on first run. You will need to make sure you immediately drop filtered events and stop the capture - ProcMon can crash your system if you leave it unattended, as it will use all available memory. Go to Filter > Drop Filtered Events.
The toolbar at the top of ProcMon is where useful actions are performed. The ones we will care about are Capture enable/disable, Autoscroll, Clear log, and Filter.
Capture enable/disable is the magnifying glass, with the items directly to the right of it being autoscroll, clear log, and filter, in order. At this time you should disable capture and clear the log. You can tell capture is disabled when the log is cleared by looking at the bottom left of the window.