The message, in both of its wordings
Forge and NeoForge strip client-only code out of the server at load time and throw when something asks for it anyway. The exact wording depends on how old the pack is, which matters because searching for the wrong one finds nothing.
| Minecraft era | What the log says | Thrown by |
|---|---|---|
| 1.13 and newer (Forge, NeoForge) | Attempted to load class ... for invalid dist DEDICATED_SERVER | RuntimeDistCleaner, the @OnlyIn(Dist.CLIENT) stripper |
| 1.7.10 to 1.12.2 (legacy Forge) | Attempted to load class ... for invalid side SERVER | SideTransformer |
| Either era, during mod construction | Failed to create mod instance | The mod's own constructor touching a client class |
| Either era, in the transformer | RuntimeDistCleaner/DISTXFORM | The class-stripping transformer itself |
Tip
On 1.7.10 and 1.12.2 the class in the message is usually obfuscated. You will see names like bao, bdw or bjf. Those are Minecraft's own classes under the old mappings. They tell you nothing about which mod is at fault, so do not search for them.
Exact error messages
Modern Forge and NeoForge print the refused class with slashes instead of dots. The class changes from crash to crash; these are common ones, and each hints at the kind of mod that asked for it. The mod itself is still found in the stack trace, not in this line.
| Exact line in the log | What it tells you |
|---|---|
| Attempted to load class net/minecraft/client/gui/screens/Screen for invalid dist DEDICATED_SERVER | Screen is the base class of every menu and GUI screen. A mod built or opened a screen from code the server also runs. Config-menu, HUD and inventory mods are typical examples. |
| Attempted to load class com/mojang/blaze3d/vertex/PoseStack for invalid dist DEDICATED_SERVER | PoseStack holds the position and rotation used while drawing models and GUI elements. A mod's rendering code ran on the server, for example from a rendering, cosmetic or animation mod. |
| Attempted to load class net/minecraft/client/Minecraft for invalid dist DEDICATED_SERVER | Minecraft is the client game object itself, which a dedicated server never creates. Any mod that reaches for the running client, its window, player or settings, can trigger it. |
| Attempted to load class bao for invalid side SERVER | The legacy Forge form on 1.7.10, where bao is the obfuscated name of that same client Minecraft class. Ignore the short name and read the stack. |
| Failed to create mod instance. ModID: <id> | The one wording that names the mod directly. Next to a dist error it means the mod's own constructor touched a client class while loading, so <id> is the mod to look at first. |
Why the named class is never the culprit
The class in the message is the class that was refused, and it is a Minecraft client class every single time, something like net.minecraft.client.Minecraft or net.minecraft.client.gui.screens.Screen. Removing it is not an option and it is not broken. What you need is the mod that asked for it, and that is in the stack trace, not the message.
- Scroll to the stack under the exception and read downwards past the loader frames (cpw.mods, net.minecraftforge, net.neoforged, org.spongepowered).
- The first package that is none of those belongs to a mod, for example com.someauthor.somemod.
- Match that package to a jar in mods/. Most mods use their own name in the package, so this is usually obvious once you know to look there.
- If the crash says “Failed to create mod instance”, the log normally names the mod id directly on that line. Take it.
Two corpora matter here and they are not the same file. The console you see in the panel is stdout and stderr; the full construction stack and the RuntimeDistCleaner frames often appear only in crash-reports/*.txt. If the console tail is thin, read the crash report.
The mods this happens to
Almost every case is a client-side mod that ended up in a server's mods folder because the pack was installed from its client zip. The families that show up repeatedly:
- Rendering and performance mods that bind native graphics libraries. A NoClassDefFoundError naming org/lwjgl alongside a named render mod is the same crash with a different message.
- Shader and lighting mods, which exist entirely to change how the game draws.
- Cosmetic loaders and account overlays, whose stub loaders install themselves before the mod list is even read.
- Minimaps, HUD mods, inventory tweaks and anything whose whole feature is a screen.
Tip
1.7.10 is a deliberate exception to the org/lwjgl rule: some legacy packs use LWJGL server-side on purpose, so an lwjgl error there is not automatically a client mod.
How to fix it
- Back up the world folder.
- Move the mod the stack named out of mods/ and restart. Client-only mods do not need a server copy. Keep it in your own client mods folder and it still works in multiplayer.
- Expect more than one. Client packs routinely ship a dozen client-only mods, and the server surfaces them a few at a time as each boot gets further than the last.
- Where the pack publishes a server pack, use it. That is the same pack with the client-only mods already removed, and it saves the whole exercise.
- Check the mod's page before removing it permanently: a mod tagged Client-side only on Modrinth, or Client on CurseForge, is meant to be absent from the server.
The awkward case: a server mod that requires a client mod
Sometimes the client-only mod cannot simply be removed, because another mod in the pack declares it as a required dependency. Remove it and the loader refuses to start over a missing dependency; keep it and the dist check kills the server. The pack is not bootable on a dedicated server as shipped.
The real fix is to remove the requiring mod as well, if you can live without it, or to use the pack's server pack where one exists. If neither is acceptable, this is a pack bug worth reporting to its author. It is not something a host can configure around.
What MineXHost's launcher does with this crash
MineXEngine recognises both wordings, the construction-time variant and the transformer variant, and reads the stack rather than the message to attribute the mod. Where the class in the message is obfuscated it drops the attribution rather than guessing, because an obfuscated Minecraft class genuinely does not identify a mod, and a guess there removes the wrong file.
Before each boot, the engine moves known client-only mods into mods/.quarantined/: mods that declare themselves client-only in their own metadata, client rendering mods such as Sodium and Iris, a list of client mods proven to crash a dedicated server, and client loader stubs such as Essential's. A mod that a kept mod hard-requires is spared. That is why most client packs boot here without a hand-edit.
Some client-only mods that crash the boot are moved to the same folder on a customer server too, because the server cannot start while the mod is present. When the crash shows the loader stripping client-only code and a mod failed to load during mod construction, every mod that failed there is moved. When the invalid dist DEDICATED_SERVER crash comes from a mixin, only mods the engine can show are client-only are moved. The files are moved, not deleted. Other crashes are identify-only: crash recovery names the file and leaves your mods folder alone.
For the dependency deadlock above, the engine detects that the pack cannot boot as shipped and writes a proposal naming every file that would have to go, with the evidence for each. The panel shows you that list and applies nothing until you approve it.
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-testedModpacks where our QA Lab saw this error
Our QA Lab installs and boots public modpacks on test servers. For each pack below, MineXEngine recorded this error in at least one of the pack's most recent public tests (up to 10 are read). Each pack still has a listed page, so at least 50% of its tests with a clear result passed and one passed in the last 45 days. These are test servers, not customer servers.
- One Piece SeaSick: 2 of its 7 most recent public tests
- Beyond The Weather: 1 of its 7 most recent public tests
- Cozy Farming Life: 1 of its 7 most recent public tests
- CraftZ - Zombie Survival (Modrinth): 1 of its 9 most recent public tests
- Create & things: 1 of its 6 most recent public tests
- Deja Vu | EnderVerse: 1 of its 7 most recent public tests
- Forged in Dragonfire: 1 of its 7 most recent public tests
- Infinity Legends (Palladium): 1 of its 8 most recent public tests
- Inside the Darkness - Horror: 1 of its 8 most recent public tests
- Jujutsu Kaisen: 1 of its 9 most recent public tests
- Sanity: 1 of its 6 most recent public tests
- Scarecrows / Бабайки [HORROR] OLD DISCONTINUED: 1 of its 7 most recent public tests
All tested packs are on the modpacks hub.
MineXHost runs CurseForge and Modrinth modpacks 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 “invalid dist DEDICATED_SERVER” mean?
“invalid dist DEDICATED_SERVER” is Forge and NeoForge refusing to load a client-only Minecraft class on a dedicated server. Client code is stripped out of the server at load time, so when a mod asks for a rendering, GUI or input class the loader throws rather than hand it something that is not there. The class named in the message is a Minecraft class and is never the problem; the mod that asked for it is further down the stack trace. On Minecraft 1.7.10 to 1.12.2 the same failure is worded “for invalid side SERVER” instead.
Which mod is causing “Attempted to load class ... for invalid side SERVER”?
Read the stack trace under the exception and find the first package that is not a loader package. Skip cpw.mods, net.minecraftforge, net.neoforged and org.spongepowered, and the next package down belongs to a mod. That package name normally matches a jar in your mods folder. Do not search for the class in the message itself: on 1.7.10 and 1.12.2 it is an obfuscated Minecraft class such as bao or bdw, and it identifies nothing.
Can I run a client modpack as a server by just uploading it?
Usually not without removing the client-only mods first, because a client pack ships shaders, minimaps, HUD mods and rendering optimisers that cannot run on a dedicated server, and each one crashes the boot until it is gone. If the pack publishes a server pack, use that: it is the same pack with those mods already removed. MineXHost's launcher moves known client-only mods, such as those that declare themselves client-only, client rendering mods and the Essential loader, into mods/.quarantined/ before the server boots, which handles most of them.
A mod I need requires a client-only mod. What now?
A pack whose server-side mod hard-requires a client-only mod cannot boot on a dedicated server as shipped, and that is a pack bug rather than a hosting problem. Removing the client-only mod trips a missing-dependency error from the mod that requires it, and keeping it trips the dist check. Your options are to remove both mods, to use the pack's official server pack if one exists, or to report it to the pack author. No host-side setting resolves it.
Is a NoClassDefFoundError mentioning org/lwjgl the same problem?
Yes, on Minecraft 1.13 and newer that error is almost always the same client-mod problem, because LWJGL is the native graphics and input library and a mod reaching for it on a dedicated server is a rendering mod that should not be installed there. Look for the render or shader mod named nearby in the log. Minecraft 1.7.10 is the exception: some legacy packs use LWJGL server-side deliberately, so the same error there does not by itself prove a client mod is at fault.