Guidefor players4 min read
"Embeddium instance tainted by mods" is not a crash
Embeddium prints a taint warning naming every mod that patched its internals. It is a support disclaimer, not an error, and removing the named mod usually makes things worse. How to read the line and what it is actually telling you.
The line, in full
Embeddium ships a component called the mixin taint detector. When another mod patches Embeddium's own classes, it logs this:
[Render thread/ERROR] [Embeddium-MixinTaintDetector/]: Mod mixin into Embeddium internals
detected. This instance is now tainted. The Embeddium team does not provide any guarantee
of support for issues encountered while such mods are installed.
[Render thread/WARN] [Embeddium-MixinTaintDetector/]: Mod(s) [entity_texture_features] are
modifying Embeddium class me.jellysquid.mods.sodium.client.render.vertex.buffer.SodiumBufferBuilder,
which may cause instability.
If the game later crashes for any reason at all, the crash report opens with the short version:
---- Minecraft Crash Report ----
// Embeddium instance tainted by mods: [oculus]
// Please do not reach out for Embeddium support without removing these mods first.
Read that as a sentence and it sounds like an accusation. It is not one. It is a support policy, printed automatically, listing which mods reached into Embeddium's code.
What it actually means
Embeddium's maintainer put it plainly when someone opened an issue titled "This instance is now tainted???" in February 2025: "This is fine and expected; it's letting you know that another mod (in this case, Oculus) has modified Embeddium, and if you crash, it might not be caused by Embeddium alone."
That is the whole thing. The detector fires at load time, before anything has gone wrong, and it fires on every setup where a mod mixes into Embeddium. On a normal Forge or NeoForge instance with shaders, that is the expected state, because Oculus patches Embeddium by design. So do Entity Texture Features, Nvidium, and most of the Sodium addon mods. The taint notice is Embeddium saying "these mods changed my code, so if you file a bug I may not be able to reproduce it," not "these mods broke your game."
Why it gets blamed anyway
Two design choices make this message land badly. The first line goes out at ERROR level, and the summary is copied into the crash report header. Those are the two places a player scans first, so a disclaimer ends up occupying the position a cause would occupy.
The result is people filing the message itself as the bug. One real crash report from March 2025 opens with // Embeddium instance tainted by mods: [oculus] and then, twenty lines down, gets to the actual failure: a RuntimeException thrown out of Forge's GameData.postRegisterEvents while initializing the game. That is a registry problem during mod loading. Embeddium had nothing to do with it. The taint line was true and irrelevant at the same time.
It also gets reported to the wrong projects. Entity Texture Features has an issue on its tracker whose title is literally "Embeddium instance tainted by mods: Entity Texture Features, Nvidium," filed by someone whose game crashed on a 1.20.1 Forge instance running Sinytra Connector. Embeddium's own tracker has the same pattern from the other side: an issue from December 2024 titled after the taint line, from a player whose game crashed on the loading screen with [entity_texture_features, valkyrienskies, vivecraft, oculus] named, and whose crash report said "Suspected Mods: NONE" in one place and "Suspected Mods: Minecraft" in another. Another from the same week reported random freezes fifteen minutes into play, in unfamiliar chunks. Different bugs, different subsystems, same header line pasted as though it explained either of them.
How to read it properly
The first line is boilerplate. Skip it. The WARN lines under it are the useful part, because each one names a specific mod and a specific Embeddium class.
That mapping is worth something when you do have a real problem. If entity models are rendering wrong, and a warn line says a mod modified EntityRenderer, you have a candidate. If your chat text is fine and your chunks are fine and the only warn line points at a vertex buffer class you are not having trouble with, you have ruled something out. Use it as a directory of who touched what, which is exactly what the detector was built to produce.
Then diagnose the crash normally. Read the Description line, then the deepest Caused by in the stack trace, and see which mod's package actually appears in the frames. Running the report through the crash log reader does that for you.
When it does matter
There is one situation where the line is decisive: when you are about to report a bug to Embeddium. If your instance is tainted, the maintainers may well ask you to reproduce it without the named mods before they look further. That is what "please do not reach out for support without removing these mods first" is asking for. Reproduce it clean, then report, and if it stops happening without the named mod you have found a genuine incompatibility worth filing against whichever project you prefer.
Outside that, the correct response to a taint warning on a working game is nothing at all. Removing a named mod because of it is how people turn a working setup into a broken one, which is the more general trap covered in why performance mods crash when you stack too many of them: the mod you suspect first is rarely the mod the log is actually pointing at.
