Where Crash Logs Live
First stop after a crash: .minecraft/crash-reports/ — the newest txt is your report (failed launches land in the launcher log). Reports are long but only three parts matter: the Description (one line on what broke), the stack trace (the java.lang.XXXException lines), and Suspected Mods (the game's own culprit list, ~70% accurate). 90% of debugging uses only these three.
Four Common Conflict Types
Crash messages vary endlessly, but the root causes fall into four buckets:
| Type | Typical Keywords | Cause | Fix |
|---|---|---|---|
| Mixin failure | MixinApplyError / MixinTargetNotFound | Two mods patch the same code, or version mismatch | Downgrade one, or find a compat patch |
| Registry ID clash | Duplicate key / entry already exists | Two mods register the same item/block ID | Change the ID prefix in config |
| Missing API | NoSuchMethodError / NoClassDefFoundError | Missing dependency (Fabric API, KotlinLib...) | Install the missing library |
| Version mismatch | expects Minecraft 1.x.y | Mod built for a different game version | Download the matching build |
The Bisection Workflow
When Suspected Mods isn't conclusive, bisect: 1) move half your mods out and launch; 2) crash gone? culprit is in the removed half; still crashing? it's in the kept half; 3) halve the suspect pool again — 3-4 rounds pinpoints one mod. 100 mods = at most 7 rounds. Pro tip: test recently-installed mods first; 80% of conflicts come from the newest addition.
Prevention Beats Cure
Three habits avoid 90% of conflicts: 1) verify game version + loader (Forge/Fabric) match exactly; 2) install every required library; 3) never overwrite your mods folder on a big update — create a fresh instance and migrate in batches. Add a profiler (Spark) and a launcher with dependency resolution, and hour-long debugging becomes minutes.