locked
DllImport: Unable to load DLL 'Engine.dll': Not enough storage RRS feed

  • Question

  • I have a Excel template VSTO project and a class library project.  When the user clicks a button in the vsto project, it executes a method in the class library which needs to execute a method in a win32 dll.  I've added the DLL to the the class library project and set it to copy to the output directory.

    I have the following code in the class:

    [DllImport("Engine.dll",CharSet=CharSet.Auto)] 
    static extern int ExecuteOptimization(System.String accountName, int mode); 


    And then I execute the following statement in my function

    int returnCode = ExecuteOptimization(ConfigurationPath, 0); 

    I then get a DllNoteFoundException wiht the following message:

    Unable to load DLL 'Engine.dll': Not enough storage is available to process this command. (Exception from HRESULT: 0x80070008)

    I know it is finding the DLL because I get a different error if I remove the DLL.  ConfigurationPath is a String.

    Any help would be much appreciated.  Thank you!
    Tuesday, February 24, 2009 11:58 PM

Answers

  • Well, in 32-bit Windows, you have about two and a half GBs of address space per process. So you might want to check to ensure that you aren't close to that limit for whatever program is hosting the VSTO code.

    Secondly, you might have run out of available RAM, and the memory swap file either has no available space either, or it might be fragmented enough to not fit the DLL's data. A quick check on Task Manager could show how much total memory is being used up. Again, if you are too close to the border, you might get allocation problems.

    Alternately, I've seen various libraries incorrectly throw this code for non-memory related issues. For example, it could be thrown when the library code detects there isn't enough disk space to do a write operation it wants to do.

    With regards to the DLL allocating its own memory, yes they all do, but it's where it happens that matters here. Some libraries just load and don't do anything until the host process actually calls some library function. That would show up as a different problem. In this case, it looks like the allocation is happening in the "entry point" function of the DLL, which is called by the OS as soon as the library loads. That error would bubble to the Load operation like you see here.

    One question though, in the lightweight app that successfully loads the DLL, is that a .NET program as well? Is it also a VSTO project?
    -Rob Teixeira
    • Marked as answer by Zhi-Xin Ye Tuesday, March 3, 2009 9:49 AM
    Wednesday, February 25, 2009 11:48 PM

All replies

  • Just looks like you're running out of memory. The error code for HRESULT 0x80070008 basically means the process can't allocate enough memory. I'm not sure if the DLL itself can't fit into memory, or if this is bubbled up from the library's own initialization code, which could be doing memory allocation internally for its own purposes.

    It's happening on that line because P/Invoke lazy-loads libraries. That is to say, they don't get loaded until the first time a function gets called.
    -Rob Teixeira
    Wednesday, February 25, 2009 12:54 AM
  • When running, the DLL only allocates about 15 MB at first and peaks at about 150 MB of memory.  I see this when running it via another utility.  Do you know what is determining the memory limit?  I know the DLL functions, I have a light GUI that executes it.  The DLL is certainly allocating memory internally, it has to.
    Wednesday, February 25, 2009 6:04 PM
  • Well, in 32-bit Windows, you have about two and a half GBs of address space per process. So you might want to check to ensure that you aren't close to that limit for whatever program is hosting the VSTO code.

    Secondly, you might have run out of available RAM, and the memory swap file either has no available space either, or it might be fragmented enough to not fit the DLL's data. A quick check on Task Manager could show how much total memory is being used up. Again, if you are too close to the border, you might get allocation problems.

    Alternately, I've seen various libraries incorrectly throw this code for non-memory related issues. For example, it could be thrown when the library code detects there isn't enough disk space to do a write operation it wants to do.

    With regards to the DLL allocating its own memory, yes they all do, but it's where it happens that matters here. Some libraries just load and don't do anything until the host process actually calls some library function. That would show up as a different problem. In this case, it looks like the allocation is happening in the "entry point" function of the DLL, which is called by the OS as soon as the library loads. That error would bubble to the Load operation like you see here.

    One question though, in the lightweight app that successfully loads the DLL, is that a .NET program as well? Is it also a VSTO project?
    -Rob Teixeira
    • Marked as answer by Zhi-Xin Ye Tuesday, March 3, 2009 9:49 AM
    Wednesday, February 25, 2009 11:48 PM