Startup Issue with Minecraft - Java null pointer exception on boot

System Information

Field Value
Operating System Linux - Debian GNU/Linux 11 on x86_64
Product AMP ‘Decadeus’ v2.4.6.6 (Mainline)
Virtualization QEMU_KVM
Application Minecraft
Module MinecraftModule
Running in Container No
Current State Failed

Problem Description


The server was running fine, then crashed earlier this evening. When I tried to start the server back up, the console was saying that it was trying to boot a backup level file.

I restored a backup from this morning and the server works fine.

I then deleted the level.dat.old file from the backup of the latest world folder, and restored it on the server. I then tried to boot but it now fails with the following exception:

---- Minecraft Crash Report ----
// Oops.

Time: 10/18/23 11:08 PM
Description: Exception getting block type in world

java.lang.RuntimeException: java.lang.NullPointerException
at codechicken.wirelessredstone.core.SaveManager.resetWorld(
at codechicken.wirelessredstone.core.RedstoneEtherServer.init(
at codechicken.wirelessredstone.core.RedstoneEther.loadServerWorld(
at codechicken.wirelessredstone.core.WRCoreEventHandler.onChunkDataLoad(
at cpw.mods.fml.common.eventhandler.ASMEventHandler_524_WRCoreEventHandler_onChunkDataLoad_Load.invoke(.dynamic)
at cpw.mods.fml.common.eventhandler.ASMEventHandler.invoke(
at net.minecraftforge.common.chunkio.ChunkIOProvider.callStage2(
at net.minecraftforge.common.chunkio.ChunkIOProvider.callStage2(
at net.minecraftforge.common.util.AsynchronousExecutor.skipQueue(
at net.minecraftforge.common.util.AsynchronousExecutor.getSkipQueue(
at net.minecraftforge.common.chunkio.ChunkIOExecutor.syncChunkLoad(
at net.minecraft.server.MinecraftServer.func_71247_a(
at net.minecraft.server.dedicated.DedicatedServer.func_71197_b(
at net.minecraft.server.MinecraftServer$
Caused by: java.lang.NullPointerException
at codechicken.core.CommonUtils.getSaveLocation(
at codechicken.core.CommonUtils.getSaveLocation(
at codechicken.wirelessredstone.core.SaveManager.resetWorld(
… 27 more

Reproduction Steps

  • Restore working backup
  • Restore current world folder
  • Server fails to boot

I wouldn’t recommend deleting any of the .dat files, those are pretty important.
When restoring backup, I’d suggest deleting the world folder before restoring a backup, as there may be some new data that doesn’t get overridden (especially when working with modded data).

Understood, I’ve restored those files. I have been deleting the world folder each time I restore the backup.

When I try to start the server with the level.dat_old file still in the world folder, I get this error:

Server thread/WARN: Forge Mod Loader detected that the backup level.dat is being used.
This may happen due to a bug or corruption, continuing can damage
your world beyond repair or lose data / progress.
It's recommended to create a world backup before continuing.

Run the command /fml confirm or or /fml cancel to proceed.

Alternatively start the server with -Dfml.queryResult=confirm or -Dfml.queryResult=cancel to preselect the answer.

If I confirm, it loops back the error, if I cancel, it cancels the startup.

Oh weird, got a couple ideas on how to maybe resolve this:

  • Might be able to copy the world’s current level.dat and rename it to level.dat.old, see if that somehow sorts things out.
  • Download one of the older backups to your PC, then grab those level.dat files and import them

The backup’s level.dat and level.dat_old files are 0kb, so it looks like the only usuable backup is the much older one :frowning:

Thank you anyway!

You might be able to try and use those old level.dats with the latest backup, they mostly contain world metadata, so it should be fine in theory (at least I hope)

Okay so now there’s a new error with the working backup’s level.dat file being imported into the latest world folder backup:

Exception in thread "main"
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
at java.awt.GraphicsEnvironment.checkHeadless(
at java.awt.Window.<init>(
at java.awt.Frame.<init>(
at java.awt.Frame.<init>(
at javax.swing.SwingUtilities$SharedOwnerFrame.<init>(
at javax.swing.SwingUtilities.getSharedOwnerFrame(
at javax.swing.JOptionPane.getRootFrame(
at javax.swing.JOptionPane.showOptionDialog(
at javax.swing.JOptionPane.showMessageDialog(
at javax.swing.JOptionPane.showMessageDialog(
at net.minecraftforge.installer.SimpleInstaller.launchGui(
at net.minecraftforge.installer.SimpleInstaller.main(

Oh that’s an unrelated, really strange error that comes up occasionally.
Might want to try and stop/start the instance to see if that kicks it over.
What Forge version are you on?

I get the same error even after stop/starting the instance.

I’m on Forge version, but when I look at the file it says java @user_jvm_args.txt @libraries/net/minecraftforge/forge/1.20-46.0.14/unix_args.txt "$@" which seems wrong to me?

AMP doesn’t use the as far as I’m aware, it just builds it’s own start command (since that’s all the is)

Oh wait, 1.7.10?
That should be moderately easy to solve if it’s throwing up that weird display error again

Yeah it’s still giving the weird display error, no matter which backup I switch to now :confused:

Current ideas:

  1. Add nogui under Java and MemoryAdditional java options


  1. Under Server Settings
  • Switch the server type to Custom
  • Set the server Jar to forge-1.7.10-
  • set Custom startup arguments to -Xmx{Memory} -jar {JarFile} nogui

You really are a wizard, thank you so much. Option 2 was the answer. Server is up and running and on the latest save.

Frustratingly, I’d tried option 1 myself earlier but that hadn’t worked.

Thank you again, you’re a legend!

No probs!
I think AMP might have a filter with option 1 to make sure that nogui isn’t plopped in the middle of the args

You need to use Server Settings → Additional server arguments for anything passed to the jar, rather than to java

Thought AMP added nogui anyway?

AMP usually does, but occasionally it’ll randomly pull this noise

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.