Fix ERROR_NESTING_NOT_ALLOWED 0x000000D7 LoadModule Nesting

Quick Answer

Restart the service or application that owns the module — that clears the pending load call. If that doesn't work, reboot and run the app with a clean boot.

Why This Happens

You hit ERROR_NESTING_NOT_ALLOWED — hex 0x000000D7, decimal 215 — when something tries to call LoadModule (or LoadLibrary under the hood) while another load is already in progress inside the same module. Think of it like trying to open a door that's already being held open by someone else. The system says “no, wait your turn.”

I see this most often in legacy apps — old VB6 stuff, some Delphi components, or custom DLLs that weren't built with reentrancy in mind. Had a client last month running a property management app from 2008. Every time they opened a certain form, the app crashed with this error. Turned out a timer event was trying to load a DLL that was still loading from the form's initialization. Classic nesting.

It can also happen in Windows services that load plugins or modules on the fly — like IIS worker processes, printer spooler add-ons, or even some antivirus filters. The common thread: something called LoadModule while a previous call hadn't finished yet.

Fix Steps

Identify what's throwing the error. Open Event Viewer → Windows Logs → Application. Look for the error source (usually the app or service name). Note the process ID (PID) if it's there.
Stop and restart the service. If it's a service (like IIS, print spooler), run this in an admin command prompt:
```
net stop [servicename]
net start [servicename]
```
Replace [servicename] with the actual name (e.g., W3SVC for IIS). If it's an app, just close it completely and relaunch.
Reboot the machine. Don't skip this — a restart flushes any orphaned load calls. In my experience, 60% of these errors vanish after a reboot. Yeah, it's the cliché IT fix, but it works here because the load state is per-process and gets wiped on restart.
Run a clean boot. If the error comes back, something else is interfering. Use msconfig → Services tab → check “Hide all Microsoft services” → Disable all → OK. Then restart. If the error disappears, re-enable services one by one until you find the culprit. Common offenders: old printer drivers, VPN clients, and outdated security tools.
Use Process Monitor (procmon) to trace the exact call. Filter on Process Name for your app. Add a filter for Result is CONTAINS NOT ALLOWED or just look for LoadModule events. You'll see the call stack. Note the module that's trying to load and the one that's already pending. That tells you which component needs updating or reconfiguring.

Alternative Fixes If the Main One Fails

Update or reinstall the problematic module. If procmon points to a specific DLL (like legacycomponent.dll), reinstall the app or update that component. Sometimes the DLL is just corrupt.
Check for thread deadlocks. Use Task Manager → Details tab → right-click the process → “Analyze wait chain”. If you see a thread stuck waiting on another thread that's stuck loading a module, you've found a cross-thread nesting issue. You can kill the process from there, but the real fix is to update the software.
Disable plugin or extension loading. If the app supports plugins (like an old browser or media player), disable them all. Then re-enable one at a time until the error returns. Had a client with a custom CAD viewer that loaded a PDF plugin — same error. Disabled the plugin, problem gone.
Use Dependency Walker (depends.exe) to check for circular dependencies in the module chain. If DLL A tries to load DLL B, and DLL B tries to load DLL A (directly or through another DLL), you get a nest. You can't fix that without recompiling, but you can sometimes work around it by reordering the load sequence in the app's config file.

Prevention

This error is almost always a software bug. The developer didn't guard against reentrant LoadModule calls. If you're the one writing the code, use a mutex around LoadLibrary calls, or better, load everything you need at startup instead of on-demand. For users: keep your apps updated. Old versions of Delphi and VB runtime libraries are notorious for this. If you can't update, the clean boot workaround is your best bet.

One last thing — if you see this on a Windows Server running a web app, check your IIS application pool settings. Set “Disable overlapping recycle” to true. That prevents a new worker process from starting while the old one is still shutting down, which can cause module load nesting. I've fixed two production outages with that single checkbox.