Which ESO Addon Is Crashing My UI? Read the Error, Then Halve the List

What this page was checked against

Built 2026-08-22. Checked against the live game as it stood that day: interface (API) version 101050, which is Update 50, live since 2026-06-08. The next interface bump, Update 51, goes live on PC/Mac on September 28, 2026. Every rule quoted below carries the date it was fetched — all of the ESOUI quotes on this page were fetched on 2026-08-22, and the Update 51 date was verified at the ZeniMax announcement on 2026-08-19 and not re-fetched since.

You can read your own client's number in-game. The ESOUI dependency sticky gives the command verbatim: "/script d(GetAPIVersion())" (esoui.com/forums/showthread.php?t=9149, fetched 2026-08-22). If that prints 101050 you are on the same build this page was written against.

Step zero: turn the detail on, or the error will not name the line

ESOUI's troubleshooting sticky, fetched 2026-08-22, verbatim (including the source's run-together word): "Attention: If the numberis missing you need to enable them at the ingame addon manager (press ESC to get to the menu -> AddOns) and enable the checkbox "Advanced UI errors"." Without it you get a shorter message and the line number can be absent, which is the one part of the error that lets the author find the fault.

The popup itself has a second control. Same post, verbatim: "please click on the "Show more" checkbox (keyboard mode) / the "More info" keybind (gamepad mode) at the bottom left to see all relevant information about the error message". Do that before you copy anything.

One more thing on that popup that almost nobody knows and that costs nothing to capture: the hexadecimal code in the header line (the sticky's example is C2AA5088) is what ZeniMax uses to locate the error on their side. If you ever report an interface error to ZeniMax rather than to an addon author, that code is the payload.

Read the error: the first path segment after AddOns/ is the folderCommunity-reported

An ESO Lua error names the file it failed in, in the form user:/AddOns/<Folder>/<file>.lua:<line>, followed by the message and usually a stack traceback. The segment immediately after AddOns/ is a folder name in your live\AddOns directory, and that folder belongs to exactly one installed download. We label this claim community-reported rather than confirmed for one reason: we could not retrieve a first-party ZeniMax description of the error-string format on 2026-08-22. What we can show is real errors, published by addon authors themselves, that have exactly this shape.

A real one, from Master Merchant's own changelog for version 3.7.64 (read from our addon corpus 2026-08-22), verbatim: "user:/AddOns/MasterMerchant/Libs/LibGuildStore/Data.lua:362: operator * is not supported for number * nil". Read it left to right: the folder is MasterMerchant, so the download is Master Merchant 3.0. LibGuildStore appears deeper in the path — that is a library bundled inside Master Merchant's own folder, not a separate install. Our folder index confirms it: the folder name LibGuildStore appears in Master Merchant 3.0's file list and is not owned by a standalone download.

Another, from HodorReflexes' changelog entry dated 2025.04.08 (same corpus, same read date), verbatim: "user:/AddOns/LibGroupBroadcast/HandlerManager.lua:34: Handler name 'GroupResources' has already been registered by 'LibGroupResources'." Here the folder IS a standalone library — LibGroupBroadcast is its own download — and the message names a second library as the conflicting party. Which brings us to the next rule.

• user:/AddOns/ — fixed prefix, ignore it.
• <Folder>/ — THIS is the answer. One folder in your live\AddOns directory.
• <file>.lua — which source file inside it. May sit in subfolders (Libs/, src/, ui/); still the same addon.
• :<line> — the line number. Present only with "Advanced UI errors" on. The author needs it.

The library named in the error is usually the victim, not the culpritCommunity-reported

This is stated outright by ESOUI's troubleshooting sticky, fetched 2026-08-22, verbatim: "Important: It must not be the causing addon but could be just a library which is missing." A library errors where it is used, and it is used by whatever called it — which may be any of the other addons on your list. Deleting the library because its name is in the message is the classic wrong move.

The same post gives the control test, verbatim: "Disable ALL other addons then ingame except the one that raises the error and test if the same error is reproducable with only the addon enabled." If the error survives with only that addon (and its dependencies) enabled, you have your culprit. If it vanishes, the fault is an interaction and you need the bisect below.

Treat the inference as an inference: "the named library is usually the victim" is a rule of thumb supported by the sticky's warning, not a measured proportion. We have not measured how often it holds.

Before you disable anything: record what is on, and back up

Bisecting means switching dozens of things off. If you do not record the starting state you will not be able to get back to it, and the file that holds it has a name. The troubleshooting sticky, fetched 2026-08-22, verbatim: "Search for UserSettings.txt or AddOnSettings.txt file on your harddrives/sdds and check which folder it is in (with the most up2date date and time!). Below this folder, in the subfolder AddOns, your addons need to be located so the game will find them as well."

AddOnSettings.txt sits in the live\ folder, one level above AddOns, beside UserSettings.txt. Copy it with the game closed and you have your enabled set on record. Copy live\SavedVariables at the same time and you have every addon's accumulated data. The request sticky, fetched 2026-08-22, verbatim: "SavedVariablse are stored in live/SavedVariables but we do not have access to the files directly, only via the ZO_SavedVars wrapper class" — and, on why it must be done with the game closed, verbatim: "Any altered data on the disk file will be overwritten from internal game memory at that point!"

The same sticky names the two environment faults that make add-ons look broken when they are not, verbatim: "OneDrive is not supported within ESO!" and Windows Defender controlled-folder access preventing the file being written. If your Documents folder is redirected into OneDrive, check that before you bisect anything — you may be editing one AddOns folder while the game reads another.

No error at all? Halve the list — forty addons in about six passesUnverified

This is arithmetic, and we are labelling it as our procedure rather than as documented guidance. Each pass halves the suspect pool, so the number of passes is how many times you can halve forty before you reach one: six, because two to the sixth is sixty-four and sixty-four is more than forty. Turning them off ten at a time takes longer and tells you less per pass.

The loop: at character select, open Add-Ons, disable half the list, log in, reproduce. If the fault is still there it is in the half that is still on; if it has gone it is in the half you switched off. Keep the half that contains it, halve again. Six rounds and you are on one addon. Keep the libraries enabled throughout — switching a library off will break every addon that needs it and manufacture a second, fake fault.

One honest gap in the loop: we could not establish, from any source retrieved on 2026-08-22, whether /reloadui applies an enable/disable change made on the character-select screen. What IS documented is the neighbouring fact — the troubleshooting sticky, fetched 2026-08-22, verbatim: "The game read those txt files in total at first client login, and not always "in total" if you just do a character switch or /reloadui ingame)." So the conservative loop, and the one we describe, goes back to character select each round. If you find /reloadui applies the toggle for you, your loop is faster than ours.

Use what you already know to shorten it. If a batch of addons was updated last night, start by disabling exactly that batch — that is one pass that can eliminate most of the pool, and it is information no procedure can give you.

The no-error failure class: stutter, freezes, long loadsUnverified

Not every addon fault raises a Lua error, and the ones that do not are the ones people spend weeks on: frame-rate collapse in trials, a stutter every few seconds, a store or inventory screen that takes several seconds to open, memory that climbs over a session. None of these produce a popup, so none of the error-reading above applies.

We are explicit about the instrument gap: we could not establish, from any source retrieved on 2026-08-22, that the client writes an error or performance log you can read. The documented error surface is the in-game popup and nothing else. That means for the no-error class the only instrument documented anywhere is the control test — everything off, then halve — and the only evidence you will have is your own reproduction.

Two discriminations worth making before you blame an addon at all. Does it happen with every addon disabled? Then it is not an addon. Does it happen only in one zone, one activity or one UI screen? Then bisect while doing that specific thing, not while standing in a city — a fault that only fires when a large inventory is indexed will not reproduce anywhere else.

Turning a folder name into an addon (and why that is not trivial)

The folder name in the error is not the name on the listing. LibMapPins is published under that name and installs a folder called LibMapPins-1.0. Searching a site for the folder name frequently finds nothing, which is why we built an index instead.

The index is a measurement, not a guess: across the 3,163 addons in our 2026-08-19 feed snapshot, the corpus scan (built 2026-08-22) finds 3,192 distinct install-folder names, of which 240 are shipped by more than one download. For those 240 the folder name alone does not identify the addon, so each folder page lists every candidate, marks which one actually owns the folder, and orders the rest by download count. LibAddonMenu-2.0 is the extreme: 87 different downloads ship a folder by that name.

Paste your error line into the resolver and it does this lookup for you; the folder index is browsable if you would rather look it up yourself.

Reporting it so the author can actually act

Send it to the right place. ESOUI's own guidance, fetched 2026-08-22, verbatim: "Do not use the forums to request new features. Use the addon comments of the particular addon you want new features for as the authors will see this way easier than having to search any forums." For a bug it is the same destination: the troubleshooting sticky says to "search the addon here at www.esoui.com via the addon search, top right corner of the website. Switch to the comments there and write the following information:" — followed by the date and time, the complete error text, the steps to reproduce, and confirmation that the addon and its dependencies are up to date.

Send text, not a picture. Same sticky, fetched 2026-08-22, verbatim: "Please do not create screenshots and send the screenshot of the error messages! They will be missing information then." We could not establish, from any source retrieved that day, whether the popup's text can be selected and copied directly — sources disagree and we did not test it. The instruction about what to SEND is unambiguous regardless: it is the text. If the popup will not give it to you, retype it; the first line and the line number are the load-bearing part.

If nothing comes back, there is a documented escalation. The request sticky, fetched 2026-08-22, verbatim: "If no answer was given for ~2-4 weeks you may ask for someone here at this forum https://www.esoui.com/forums/forumdisplay.php?f=164 to provide help/a fix".

On whether the author will answer at all: the only signal that exists is the date of their last release, which we print on every addon page. That is a weak signal and we are not going to pretend otherwise — it tells you the author was active on that date and nothing about today.

What this guide cannot tell youUnverified

Which of your forty it is, from text alone. Nothing on this page or anywhere else can name the culprit without either an error message from your client or a bisect you run yourself. Any page that shortlists suspects from a catalogue is guessing.

Whether the error popup's text can be selected and copied. Sources disagree, we did not test it, and we are not going to settle it by assertion. What is settled is what to send: the text.

Whether /reloadui applies an enable/disable change. Unestablished on 2026-08-22; the loop above goes via character select for that reason.

Whether the client writes any log you can read. We found no source establishing one on 2026-08-22. If there is one, this page does not know about it.

How often the library named in an error is the victim rather than the culprit. The warning is documented; the proportion is not measured.

Anything about console. There is no add-on folder to open, no character-select add-on list of this kind, and no external installer — see the console guide. Nothing in this procedure transfers.