---
title: "Fix: Plugins Show 'bad load' After Upgrading to AMXX 1.9/1.10"
excerpt: "Why your AMX Mod X plugins report 'bad load' after an upgrade, how to tell a Metamod failure from an AMXX one, and the module mismatch that causes almost all of it."
category: "errors"
tags: "amxmodx, upgrade"
image: ""
read_time: "8 min read"
---
<p>You dropped a newer AMX Mod X over an old install, restarted, and now half your plugins sit in the list with the status <code>bad load</code>. This is almost never a corrupt plugin. It is a version-mixing problem: the AMXX core got upgraded but its <em>modules</em> did not, and a plugin that needs a module the core can no longer load fails at start. The good news is that <code>bad load</code> is a precise symptom, and once you know where to read it, the fix is mechanical.</p>

<h2>1. Read the right list first</h2>
<p>There are two different "bad load" states and they live in two different lists. Check both from the server console (or RCON):</p>
<pre>meta list
amxx plugins
amxx modules</pre>
<p><code>meta list</code> is Metamod's view. If <code>amxmodx_mm</code> itself shows <code>bad load</code> here, AMXX never even started and every plugin will look broken — that is an engine/ABI problem, not a per-plugin one. <code>amxx plugins</code> is AMXX's own view; a plugin marked <code>bad load</code> there means the AMXX core loaded fine but that specific plugin could not.</p>

<h2>2. If amxmodx_mm is 'bad load' in meta list</h2>
<p>This means Metamod could not load the AMXX core binary. The usual causes:</p>
<ul>
<li>Wrong architecture — a 64-bit or Windows binary in a Linux tree. Confirm with <code>file addons/amxmodx/dlls/amxmodx_mm_i386.so</code>; it must say <em>ELF 32-bit LSB shared object, Intel 80386</em>.</li>
<li>A stale path in <code>addons/metamod/plugins.ini</code> pointing at a file you deleted.</li>
<li>Metamod itself is too old for the ABI. If you are still on classic Metamod, move to <a href="/tutorials/install-metamod-r">Metamod-r</a>.</li>
</ul>
<p>Fix that before touching anything else — nothing below matters until <code>meta list</code> shows <code>amxmodx_mm</code> as <code>RUN</code>.</p>

<h2>3. Replace the modules, not just the core</h2>
<p>This is the actual cause in the large majority of upgrade cases. AMXX modules (<code>fakemeta_amxx_i386.so</code>, <code>hamsandwich_amxx_i386.so</code>, <code>cstrike_amxx_i386.so</code>, <code>sqlite_amxx_i386.so</code>, and so on) are versioned <strong>together</strong> with the core. When you upgraded, you likely overwrote <code>dlls/amxmodx_mm_i386.so</code> and the <code>plugins/</code> folder but left the old 1.8.2 modules in <code>addons/amxmodx/modules/</code>. A 1.8.2 module against a 1.10 core fails to load, and every plugin that <code>#include</code>d it is now missing its natives.</p>
<p>Copy the entire modules directory from the same release you upgraded to:</p>
<pre>cp /path/to/amxx-1.10/addons/amxmodx/modules/*.so \
   /home/steam/hlds/cstrike/addons/amxmodx/modules/</pre>
<p>Then check what actually loaded:</p>
<pre>amxx modules</pre>
<p>Any module that is not <code>running</code> here is your smoking gun. The AMXX log will name it — look in <code>addons/amxmodx/logs/</code> for a line such as <code>Module requires a newer version of AMX Mod X</code> or a native-not-found error.</p>

<h2>4. Recompile plugins that use changed natives</h2>
<p>Old <code>.amxx</code> bytecode usually keeps working across versions, but a plugin that called a native which was renamed or removed will still <code>bad load</code> even with the right module present. The log entry looks like:</p>
<pre>Plugin "yourplugin.amxx" failed to load: Function not found</pre>
<p>Recompile the <code>.sma</code> against the matching AMXX includes. If you do not have the source, you have to find a build that targets your version. See <a href="/tutorials/install-amx-mod-x-1-9">installing AMXX 1.9</a> for how the versions line up, and <a href="/tutorials/upgrade-amxmodx-1-8-2-to-1-10">the full 1.8.2 to 1.10 upgrade</a> for the complete file list you must swap.</p>

<h2>5. Check plugins.ini and configs</h2>
<p>A plugin only loads if it is listed in <code>addons/amxmodx/configs/plugins.ini</code> and the <code>.amxx</code> file exists in <code>addons/amxmodx/plugins/</code>. A typo or a Windows/Linux filename-case mismatch shows as <code>bad load</code> too. Linux is case-sensitive; <code>AdminMenu.amxx</code> and <code>adminmenu.amxx</code> are different files.</p>

<h2>Common errors</h2>
<ul>
<li><strong><code>bad load</code> in <code>amxx plugins</code> but modules are fine</strong> — the plugin needs a native from a module that is present but a different version. Line up all modules to one release.</li>
<li><strong><code>Module requires a newer version of AMX Mod X</code></strong> — a module is <em>newer</em> than the core. You upgraded modules but not the core; do both.</li>
<li><strong>Everything is <code>bad load</code> at once</strong> — read <code>meta list</code>; the AMXX core itself failed and this is not a per-plugin issue.</li>
<li><strong>Works on Windows, breaks on Linux after copying</strong> — filename case, or you copied <code>_amxx.dll</code> modules into a Linux install. Linux needs the <code>_i386.so</code> files.</li>
</ul>

<h2>Verification</h2>
<p>Restart the server and run:</p>
<pre>meta list
amxx modules
amxx plugins</pre>
<p>You are done when <code>amxmodx_mm</code> is <code>RUN</code>, every module is <code>running</code>, and every plugin is <code>running</code> with none left in <code>bad load</code>. Change the map once and re-check — a plugin that loads on boot but references a missing native only in a late code path can still be healthy in the list, so spot-test the features you actually rely on. If a single plugin remains stubborn, isolate it with <a href="/tutorials/find-crashing-plugin">the plugin-isolation method</a>.</p>