Minecraft Modpack Making: Troubleshooting Crashes and Reporting Bugs

What to do when your first launch doesn't go smoothly.

There are two ways of diving into a modpack: installing everything you can possibly think of right away, and then launching for the first time; or installing a few mods at a time and launching to take a look at them/ensure stability before adding another handful. Both are valid ways of doing this. The latter is obviously a little easier to troubleshoot, but it’s also tough if you have ADHD or are impatient (hi, it’s me).

If you do the first method, it’s highly likely that your first run of the pack will crash. That’s just the way modded MC is. If it doesn’t, feel free to skip this chapter and move on to configuring your mods! You can always return later if you need help. Crashes can occur at any time in development, and even after release.

When Minecraft crashes, it gives you an exit code and sometimes an error or crash report. Details will also be in your latest.log file. These are going to be your best friends, and your worst enemies. Crashes can be tricky to diagnose, and logs can be hard to read, but we’ll tackle how to do those things in this chapter.

First, where to find these files. In your Minecraft directory, you’ll have both a /crash-reports/ folder and a /logs/ folder. You can probably guess which files go where. Additionally, some crashes may provide an hs_err_pid file, which will be found in your default Minecraft directory. These specific crashes are almost always issues with the PC launching the game, not the modpack itself - users may need to update graphics or sound drivers, or get a different version of Java. Google is your friend.

A thing to note about logs: your latest.log is, as you could guess, the latest log your game has made. So if you got an error, exited the game, and relaunched it without getting the error - your latest.log will no longer help you. You’ll need to look for a previous log, which appear in your logs folder and are dated to help you know which was from when. They are in .gz format, which you can unzip using the program 7zip, and access the .log file. These files can be opened in Notepad, but I recommend setting them to always open in VSCode, because it will provide color coding for you and make things MUCH easier to read!

Reading Crash Reports

Okay, so if you’ve ever seen a crash report’s content before, you’ll know that they’re a bunch of crazy mumbo-jumbo. There are probably people who look at the random strings of characters and see The Matrix and know exactly what’s going on where - I don’t know who these people are, but I’m certainly not them. But there’s a way to get a general idea despite the madness. Here’s a crash report that I got recently:

Right away, we can see in the description that the crash comes from the “mouseClicked event handler,” from which we can gather that something we clicked on caused the crash. If you scan the lines below, you can see strings talking about the “worldselection.CreateWorldScreen” - so we can guess that the error occured while trying to create a world. It’s also a good idea to scan for mod names inside the ~[brackets like this.jar], because often they will indicate who you need to report the crash to. However, in this case, none of those brackets contain helpful mod names. So what we need to do is take a look at the latest.log, which will give more information about what happened before the crash.

Reading the Log

So let’s open the log associated with the crash report. This crash happened a few launches back, so I unzipped the 2024-01-19-6.log.gz and checked to see if the file had the crash report at the very bottom. It does! Logs are in chronological order, so since the crash report happened last (ending the log), we can scroll up a bit to see what the log says just before the crash occurred.

Wow, that’s a lot of orange! Those lines are known as the “stacktrace,” and are crucial information for mod developers so they know exactly what went wrong and where. That’s why it’s really important to include your crash reports and your logs when reporting issues! But anyway, look up to the part where I have highlighted. You can see here that the error occurred when Minecraft was trying to load the dimension The End. The following line says “Failed to parse minecraft:dimension/the_end.json from pack KubeJS Resource Pack [data].” This is exactly what WE need to know. What it means is that KubeJS is trying to load a datapack for the end dimension, but the file is incorrect in some way - which means that our world couldn’t be fully defined, and that’s why clicking “Create World” crashed the game.

Now, I know exactly why this occurred. It’s because I made that datapack, and I know it contains references to a mod which I temporarily loaded the pack without (for testing purposes). Since the datapack couldn’t find that mod, it caused an error. Adding the mod back in, or deleting that datapack, will resolve the crash.

Most crashes will (hopefully) not be caused by you, though, so they may be harder to fix and could require reporting to the mod authors. But before we get into how to make a good bug report, let’s talk a little more about reading logs.

In general, the log file contains a ton of information which doesn’t affect you at all. It will largely be mods communicating what they are doing in the modpack instance - either accommodating config changes, altering behavior based on other installed mods, or simply announcing that they have finished loading. Most lines will be prefixed with a code: INFO, WARN, and ERROR are the most common. INFO is just what it sounds like, and can be generally glossed over. WARN is slightly more worth paying attention to, although in most cases it isn’t a big deal. ERROR is where most of the important lines will be, although again, sometimes it too can be safely ignored. But sometimes there will be errors which ought to be fixed even if they don’t cause immediate crashes. It’s a good idea to keep an eye out for lines that say [ERROR]: Failed to (xyz), and consider reporting those to the mod authors. Additionally, many times when you see an indented stacktrace, that can be worth reporting as well, as it could affect gameplay or cause crashes when those errors are interacted with.

How to Report Bugs More Gooder

Reporting bugs is an important job of modpack makers, since we’re the ones most likely to encounter them. Now, before I get into the details here, I want to talk about end user delegation. As a modpack maker, you’ll get a LOT of people reporting crashes or issues which are with the mods themselves and not with the modpack. In some cases, you won’t even be able to replicate the crash, so you can’t test it. In many cases, it’s good practice to tell the user to report the crash to the mod author and include their logs.

This delegation is important for your mental health, and the betterment of the modpack in general. I used to take every user report and try to report to the mod authors myself, which lead to horrible games of telephone, and a ton of wasted time on my part. I grew very burned out on the game and stopped updating the modpack because all my time was spent bug testing and reporting. These days, I will report a crash if it happens to me, or in certain other cases when I have the capacity. Otherwise, I will give the user a link to the mod’s issue tracker and ask that they get support there. It has significantly improved my mood and how much work actually gets done on the modpack.

Okay, rant over. How do you report a bug or a crash? You find the mod’s issue tracker, whether it’s on Github, Curseforge, or Discord, and make a new issue there. Describe what you think caused the issue (“I put charcoal in the modded furnace”) and what happened (“the game crashed to desktop” or “the charcoal simply disappeared”). Include the crash report, if one generated, and your latest.log. On Github you can drag and drop these files onto the text box and it will upload and link them for you. On other platforms, you’ll need to upload the text first. I recommend gist.github.com for this, because you can include the text from both the crash report and the latest.log in the same gist link.

Pro tip: when selecting your crash or log text, use the CTRL+A hotkey to automatically select all. Then CTRL+C to copy it and CTRL+V to paste it into your gist.

Whatever you do, do not paste your log or crash report directly into the text box (unless specifically told to)! This is super obnoxious for people to scroll through. However, it’s good practice to include a small excerpt from the crash report, so that others can find the issue through google or Github search. I recommend using the first line before the stacktrace.