| Previous | Next |
| STATUS_IO_PRIVILEGE_FAILED | STATUS_ENTRYPOINT_NOT_FOUND |
STATUS_ORDINAL_NOT_FOUND
Ordinal imports bind to a numeric export contract that can be more fragile than name lookup
STATUS_ORDINAL_NOT_FOUND is the user-mode counterpart of a missing numeric export. The PE export directory can expose functions by ordinal, and GetProcAddress accepts an ordinal in the low-order word. Microsoft cautions that ordinals are safest when the producer controls their stable assignment.
A same-named DLL is not enough. If the caller was linked against a different build whose .def file assigned another ordinal layout, the resolved module can load but fail the ordinal lookup. Inspect both the importing image's requested ordinal and the dependency's actual export address table. Do not infer the missing function name from a nearby ordinal because export ordinals need not form a semantic sequence.
Repair the matched component set or rebuild the caller against the supported import library. Replacing one DLL by hand can create additional ABI and signature problems. When designing a plugin or private DLL contract that must evolve, exported names are generally easier to diagnose and maintain unless ordinal stability is explicitly managed.
What to inspect
- The requested ordinal, importing image, resolved DLL path, architecture, version, and package provenance.
- The dependency export table and original module-definition or import-library data used by the caller build.
- Whether a partial deployment, rollback, or manual file replacement mixed binaries from different releases.
References
- Microsoft: GetProcAddress
- Microsoft: PE/COFF image format
- Microsoft: Link an executable to a DLL
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.