What the error means
Mods keep their settings in config specs. NeoForge loads each config file at a fixed point while the game or the server starts, and a mod that reads a value before its file is loaded gets this IllegalStateException instead of a value. The check sits in NeoForge's ModConfigSpec$ConfigValue.getRaw and uses Guava's Preconditions.checkState, which is why the top of the stack trace shows Guava and NeoForge rather than the mod.
NeoForge has four config types, and each one is read at a different moment:
| Config type | Loaded on | Read |
|---|---|---|
| STARTUP | The player's game and the server | As soon as the mod registers it |
| CLIENT | The player's game only, never a dedicated server | Just before FMLCommonSetupEvent |
| COMMON | The player's game and the server | Just before FMLCommonSetupEvent |
| SERVER | The player's game and the server; a world can override it | Just before ServerAboutToStartEvent |
So on a dedicated server, any read of a CLIENT value fails, however late it happens. A read of a SERVER value during mod setup fails too, because that file is read only when the server is about to start, and so does a read of a COMMON value from a mod's constructor, which runs before common setup.
That is also why the same pack can start on your own computer and crash on the server: your game reads the CLIENT config before mod setup, and the server never reads it.
Note
Forge and older NeoForge behave differently. In the Forge source from 1.16 to the current branch, and in NeoForge for Minecraft 1.20.4 and 1.20.6, a normal server gets the setting's default value back instead of this error; where the check exists at all, it runs only in a mod developer's test environment. NeoForge for Minecraft 1.21.1 and later throws it on every server.
Exact error messages
The lines as they appear in a NeoForge crash report or log. The parts in angle brackets change from crash to crash, and NeoForge prints a prefix such as MC-BOOTSTRAP/<module>@<version>/ or TRANSFORMER/<module>@<version>/ in front of each stack frame.
| Exact line in the log | What it tells you |
|---|---|
| java.lang.IllegalStateException: Cannot get config value before config is loaded. | The error itself. It names neither the mod nor the setting; the stack trace under it shows which code asked. |
| -- Mod loading issue for: <modid> -- | A crash report section heading that names the mod outright. If this error sits under it, that is the mod to look at. |
| Mod file: <No mod information provided> | The loader could not tie the failure to a mod file. Read the stack trace in the same section to find the mod. |
| at com.google.common.base.Preconditions.checkState(Preconditions.java:<line>) | Guava's check, the line that throws. Library code, not the culprit: skip it. |
| at net.neoforged.neoforge.common.ModConfigSpec$ConfigValue.get(ModConfigSpec.java:<line>) | NeoForge's config getter, with getRaw just above it. Also not the culprit: the frame directly below the getter is the code that asked for the value. |
How to find the mod in the stack trace
- Open the newest file in crash-reports/, or logs/latest.log, and find the line Cannot get config value before config is loaded.
- If the crash report section it sits in is headed Mod loading issue for: <modid>, or its Mod file line names a jar, you have the mod. If it says <No mod information provided>, keep going.
- Read the stack trace under the error from the top. Skip the Guava frame (com.google.common.base.Preconditions.checkState) and NeoForge's getter frames (ModConfigSpec$ConfigValue.getRaw and .get).
- The next frame is the code that asked for the value. In its TRANSFORMER/<modid>@<version>/ prefix, the text before the @ is usually the mod id, and the name in the square brackets at the end of the line is the jar (ignore everything after .jar).
- If that frame belongs to Minecraft or NeoForge rather than a mod, the read came through a patch or a callback. Look a few frames further down for the first one that belongs to a mod, and treat it as a lead to test, not proof.
- Match the mod id or jar name to a file in your mods folder.
How to fix it
- Back up the world folder first.
- Check whether the mod is meant for servers at all. If its CurseForge or Modrinth page lists it as client-side only, remove it from the server's mods folder and keep it on each player's game. Client-only mods do not need a server copy to work.
- If the mod is meant to run on servers, update it to the newest build for your exact Minecraft and NeoForge versions. A later build may read the setting at a point where it is loaded.
- If the newest build still crashes, report it on the mod's issue tracker and attach the full crash report. The fix belongs in the mod: it has to read the value later, or keep the setting in a config type the server loads.
- Until there is a fixed build, take the mod off the server if the pack runs without it, or ask the pack's author which build they tested.
Warning
Editing or deleting the config file does not fix this. The file is not wrong; the mod asked for the value too early. A CLIENT config file copied into the server's config folder is still never loaded, because NeoForge loads that type only on a player's game.
Client-only mods that fail in other ways print invalid dist DEDICATED_SERVER instead. That guide covers them.
Read the client-only mods guideIs this line always the crash?
No. A mod can catch the exception, log it and carry on, and the server keeps starting. We have seen a large NeoForge pack print this line more than a hundred times during a start that finished normally. It is the cause only when the server stops and the line sits in the crash report's Mod loading issue section, or at the bottom of the last error before the server stopped.
What MineXHost's launcher does with this crash
MineXEngine, our launcher, has no rule aimed at this error on customer servers. Crash recovery there is identify-only by default: the engine reports what it can tie to a file in your console and leaves your mods folder as you uploaded it, apart from a few narrow cases such as client-only mods, which the client-only mods guide describes.
For this crash it may not name a mod at all. The exception is thrown inside NeoForge's config code, and the engine version on customer servers does not read past that code to the mod that made the call, so the steps above are the reliable way to find it.
With the default console setting, the console shows the first copy of a repeated exception in full and hides its exact repeats, so a mod that hits this error in a loop does not bury everything else; logs/latest.log keeps every copy. Before the first boot, the launcher also moves mods that are known or declare themselves client-only to mods/.quarantined/, on customer servers too. A mod that reaches this crash was not caught by that check, so the steps above still apply.
Choosing a pack for a server? Our modpacks hub lists the packs our QA Lab has boot-tested, and each pack's page shows its latest test result and what that test covers.
Modpacks our QA Lab has boot-testedMineXHost runs NeoForge and Forge packs on MineXEngine. Our launcher detects the modpack, picks the right Minecraft loader and Java version, tunes the JVM for your RAM, and auto-recovers from the crashes that normally end a modded server's evening. Pick your RAM, paste the pack, and play.
See hosting plansFrequently asked questions
What does “Cannot get config value before config is loaded” mean?
Cannot get config value before config is loaded is an IllegalStateException that NeoForge throws when a mod reads one of its config settings before NeoForge has loaded the file that holds it, and on a dedicated server the first thing to check is a client setting, because NeoForge never loads client configs on a server. The message names no mod; the stack trace under it shows which mod asked for the value.
How do I find which mod caused it?
Find the mod by reading the stack trace under the error from the top: skip Guava's Preconditions.checkState frame and NeoForge's ModConfigSpec$ConfigValue getter frames, and the very next frame is the code that asked for the value; its prefix normally shows the mod id before the @, and the jar name sits in square brackets at the end. A crash report section headed Mod loading issue for: <modid> names the mod outright.
Why does the modpack start on my computer but crash the server?
A modpack can start on your own computer and crash a dedicated server with this error because NeoForge reads CLIENT configs on a player's game just before mod setup, but never loads them on a dedicated server, so a mod that reads a client setting during setup only fails on the server. If that mod is client-side only, remove it from the server and keep it on players' games.
Does this error happen on Forge servers too?
On a normal Forge server this error should not appear, because in the Forge source we checked, from 1.16 to the current branch, reading a config before it loads returns the setting's default value outside a mod developer's test environment, while NeoForge for Minecraft 1.21.1 and later throws the error on every server. If you do see it on another loader, the same stack-trace steps find the mod.
Does MineXHost fix this crash automatically?
MineXHost does not fix this crash automatically: crash recovery on customer servers is identify-only by default, so MineXEngine leaves your mods folder as you uploaded it, and for this error it may not name a mod at all, because the exception is thrown inside NeoForge's config code rather than in the mod's own code. Use the stack-trace steps on this page to find the mod, then update, report or remove it.