Has anyone else experienced a trap as a result of an incomplete import
address table in a DLL?

My application has trapped on a call to a second-level DLL. The
first-level DLL, my DLL, is loaded dynamically and no error is reported
by NT (it is loaded with LoadLibrary() so DONT_RESOLVE_DLL_REFERENCE
does not come in to play). Later, a function within this dynamically
loaded DLL calls an imported function in a DLL upon which it has
explicit dependence. This call fails.

There are seven DLLs from which this DLL imports functions. The Win32 PE
loader has correctly resolved the import addresses in the IAT for the
first four DLLs when the error occurs. But the only time I have managed
to catch this trap within a de{*filter*}(It was pure luck -- I have heard of
the trap occurring a total of three times), the final three DLLs import
addresses had not been resolved. The one DLL which the jump should have
gone to was already loaded in the process' address space (I ran listdlls
after the trap so perhaps the load was a result of my load and the IAT
entries were simply unresolved).

How has the loader allowed the load of my DLL to complete without
successfully resolving these references? How could the loader not find
the already loaded DLL?

FYI, The last DLL for which references within my IAT were successfully
entered was a DLL which linked in Micro Focus Cobol. I have noticed some
flaky behavior when its' runtime library, mfrts32.dll is linked in to my
app but don't see how it could affect the loading of other DLLs.

I have searched the MSDN and Microsoft online with no luck. It
appears that what I have seen is impossible.

Any suggestions and/or comments would be appreciated. Thanks