| Previous | Next |
| ERROR_LOCKED | ERROR_NESTING_NOT_ALLOWED |
ERROR_TOO_MANY_MODULES
What ERROR_TOO_MANY_MODULES means
Too many dynamic-link modules are attached to the process or to the module being loaded. The result indicates a loader or compatibility-subsystem module-count limit. It can be caused by true plugin proliferation, repeated load operations that are never balanced, or a dependency graph that expands unexpectedly.
Common causes
- A plugin host loads a new copy for each request
- Modules remain referenced because unload conditions are never met
- Recursive dependency discovery repeatedly loads variants
- A legacy subsystem enforces a smaller module table than modern Windows
How to investigate
- Enumerate loaded modules and group duplicate paths or versions
- Track LoadLibrary-style calls and matching releases
- Inspect plugin discovery for recursion or repeated aliases
- Compare the failing module count with a clean process baseline
Developer guidance
Cache module handles, normalize paths, and define plugin lifetime. Do not unload code while callbacks or function pointers remain active, but also do not acquire redundant references indefinitely.
Administrator and support guidance
Capture a module list before restart. Duplicate versions or repeated temporary paths often identify the loader defect.
How this code differs from related results
This differs from address-space exhaustion: the module-table limit can be reached even when substantial memory remains.
Evidence worth collecting
For ERROR_TOO_MANY_MODULES, begin the trace at the operation where a plugin host loads a new copy for each request. Preserve the exact API boundary, numeric result, process and thread identifiers, relevant object state, and the component version. The first verification point should be to enumerate loaded modules and group duplicate paths or versions. This evidence distinguishes the specific this result contract from a later secondary failure.
Recovery and verification
Recovery for it should address the observed condition rather than merely retrying the same call. After the change, reproduce the scenario in which a plugin host loads a new copy for each request, then confirm that the intended operation completes and that cleanup returns all associated resources. Also verify that the next repeated operation follows the same successful path without increasing the resource class implicated by this result.
When to escalate
Escalate this result with a minimal reproduction focused on the failing loader boundary. Include the operating-system build, binary architecture, runtime or compatibility-layer version, the exact input values, and a timestamped trace showing a plugin host loads a new copy for each request. For the result escalation record, note whether changing concurrency, object lifetime, target process, module set, or endpoint location alters the result.
References
Looking for a different code? Search another status or error code.