PInvoke cannot call a loaded DLL; error code is 1157 (0x0485)

[Richard Plante]

In my managed C# application, I invoke a native C++ DLL using PInvoke. Just
after starting the application I have the following memory model at slot 0.

+-------------------+ (0x02000000)
DLL 1
+-------------------+
DLL n
+-------------------+ (0x00700000)
FREE space
+-------------------+ (0x00100000)
EXE
+-------------------+ (0x00000000)

Thus, the free space between the executable and the DLL is equal to
0x00600000 (~6Mb). The DLL I am trying to invoke has plenty of space to
load and everything is fine at that moment. Since the DLL is loaded at
runtime, it will be located close to 0x00700000 since DLLs are loaded using
a top down memory scheme.

Then I intentionnaly allocate a huge block (~3Mb) of memory from my native
DLL and I play a bit with my application to force some managed bytes to be
allocated after the huge native block. The memory model is now like that:

+-------------------+ (0x02000000)
DLL 1
+-------------------+
DLL n
+-------------------+ (0x00700000)
Free space
+-------------------+
Managed bytes
+-------------------+ (0x00400000)
Native bytes
+-------------------+ (0x00100000)
EXE
+-------------------+ (0x00000000)

Next step is I release the huge block previously allocated from the native
DLL. Thus, I will get memory fragmentation.

+-------------------+ (0x02000000)
DLL 1
+-------------------+
DLL n
+-------------------+ (0x00700000)
Free space
+-------------------+
Managed bytes
+-------------------+ (0x00400000)
Free space
+-------------------+ (0x00100000)
EXE
+-------------------+ (0x00000000)

I now have the setup to get to my problem. Starting from that memory scheme,
I have close to 3Mb available over the "Managed bytes" region. As I play
with my application, the GC heap is growing up and code is getting jitted.
After playing for a while, I will consume the remaining memory 'til I get to
the "DLL n" location. At this specific moment, I won't ever be able to call
my native DLL using PInvoke, no matter the DLL was already loaded into the
memory. The error code obtained by a call to GetLastError is 1157 (0x485) =>
"One of the library files needed to run this application cannot be found.".

Is this error code is related to that fact that all DLLs are loaded using a
top down approach? How come the managed heap don't redirect its allocation
to the bottom "Free space" rather than the upper one? I guess it's
impossible to interleave the .text and .code sections of a DLL in such a
memory scheme. I was expecting the managed code to be MORE intelligent and
avoid wasting memory like that, knowing he will fail subsequent DLLs to
load.

If someone could shade a bit of light on this article, I would appreciate.

Thanks,
R

 

[Richard Plante]

I found good answers to my previous post at:
http://support.microsoft.com/default.aspx?scid=kb;en-us;326163

However, it doesn't explain why a DLL would fail to load no matter it is
already loaded into the memory. Loading the code segment of a DLL is done
using a memory top down algorithm, that's a fact. Its heap is not considered
in that load algorithm, isn't it? There must be something else that is
loaded on top the the DLL itself...