Out of memory (Error 7) in VBA - when calling Fortran Dll

[Jackie_J_]

Hi All, I am experiencing a frustrating "Out of memory" problem when I call my Fortran dll from a macro in Excel 2007 VBA. Running the dll only needs 500 Mb memory, but there is actually 2.9 Gb memory available. How can it run Out Of Memory? Descriptions of my question: I have developed a Fortan dll, which is called from a Excel 2007 macro. When I click a button, the macro will send two input arrays into the dll, then the dll performs calculations (mainly Computational Fluid Dynamics calculations, invoving creating arrays and iterations), and then an output array willl be transfered back into Excel after calling. In Fortran dll, I created a number of 2 dimensional arrays, in this way: "integer, parameter::M=600" "integer, parameter::N=2000" "real,save:: Temperature(1:M,1:N)" ...... You can see that I saved all the variables in the main subroutine. But I didn't use any allocatable arrays. I find that after VBA finished calling the Fortran dll, about 500 Mb memory was not released. It's still there. The memory was not released until Excel is closed. Everything works well on my computer and other computers with similar hardware conditions, but in my customer's computer, they always have the "Out of memory (Run-time error 7)" problem. This error occured shortlry after it started runing (runing dll normally takes 5 minutes, the error occured at 10 seconds. I think it occured just after initiallization). In VBA help, the description of Error 7 is: More memory was required than is available, or a 64K segment boundary was encountered. This error has the following causes and solutions: You have too many applications, documents, or source files open. You have a module or procedure that's too large. You are running Microsoft Windows in standard mode. You are running Microsoft Windows in enhanced mode, but have run out of virtual memory. You have terminate-and-stay-resident programs running. You have many device drivers loaded. You have run out of space for Public variables. I don't know which one applies to my case. Can anyone give me some light on this error? How can it run Out Of Memory since only 500 Mb is need and 2.9 Gb memory is available? Thanks very much! (Sorry about my poor English.) Thanks, Jackie

[Bernard]

It seems that the large usage of memory is reported from within Excel 2007 process  when the Fortran DLL is loaded and mapped.In such a situation your Fortran code allocation could have hit the predefined value.

[IanH]

You can see that I saved all the variables in the main subroutine. But I didn't use any allocatable arrays.
I find that after VBA finished calling the Fortran dll, about 500 Mb memory was not released. It's still there. The memory was not released until Excel is closed.

Because the variables are saved, the DLL doesn't release the memory associated with them until the DLL is unloaded.  Unless you explicitly unload the DLL beforehand, the DLL will be unloaded when Excel is closed.

The help for error 7 appears to be for a 16 bit implementation of Excel and/or Windows.

The storage for saved variables is often (always?) specified "statically" in the relevant DLL or EXE - that is, the storage area is set aside as part of the process of loading the DLL into memory and not as part of the execution of code in the DLL proper.  If there is insufficient contiguous virtual memory address space for the required static storage, then the loading of the DLL will fail.  Note we are talking virtual address space, which has much more to do with the software environment rather than the hardware.

Are you sure that any code in your DLL is being executed at all?  Perhaps put some write statements that send their output to a log file to trace the execution of the code in your DLL on your clients machine.  If some of those write statements are executed then you can place more of them to try and track down the problematic executable statement that is causing the error.

If none of your write statements are executed then it indicates that there is insufficient contiguous free virtual memory address space for the static requirements of the DLL

Differences in the amount of contiguous free address space between computers can vary due to the bitness (32/64) of the executable or DLL (this makes an astronomical difference, but presumably isn't relevant in your case), the bitness and version of the host operating system and the number and nature of other DLL's loaded into the address space of the relevant process.  (Because Excel has various add-in capabilities and makes extensive use of the shell's capabilities, this could vary quite a bit.)

A requirement for 500 MB of contiguous free memory (if that's what your DLL is actually asking for) in a 32 bit address space that is being shared with a beast like Excel (you won't have anything like 2.9 GB of available contiguous address space - on many Windows versions that's not even possible) is quite significant.  I'm not surprised you find the occasional issue.  After you confirm that a lack of contiguous address space is the problem then you might have to rethink your approach (Could you perform the calculations in a different process, which would have its own private address space to play in?  Could you move to 64 bit Excel?).

[DavidWhite]

If you move to 64 bit Excel, your DLL will also have to be 64 bit, otherwise Excel won't be able to load the DLL.

I discovered this when a client had two machines, one with 64-bit Excel, the other 32-bit (both Office 2010).  My 32-bit DLL's installed and ran correctly on the 32-bit version, but repeatedly ended up with DLL not found error on 64-bit Office.  The error message, unfortunately, does not really reflect that the DLL can't be loaded rather than it not being found!

David

[Jackie_J_]

Thanks iliyapolak, IanH and David for your very helpful comments! Thanks!
Now I can understand that for the static requirements of my DLL,  it is the contiguous free virtual memory address space that  makes sense rather than the physical memory. Also the bitness (32/64) of the DLL and Excel is also important, they need to be compatible. It seems to me the bitness of the operating system is not as important.

I have checked my DLL and EXCEL, they are all 32 bit, although they are running on my 64 bit operating system. (I checked DLL using Dependency Walkers and I can find the CPU of all DLLs are of "x86" type. So I say they are 32 bit.). But I am not sure about the bitness and version of EXCEL on the client machine. I will check that.

The client has two machines, one with 8 Gb RAM, the other 2.9 Gb RAM. My DLL works well on the 8 Gb RAM machine, but fails on the 2.9 Gb machine. On my friends' 4 Gb machines with 32 bit EXCEL, my DLL also works.

My further question is:
If the bitnees of EXCEL on the client machine is 64 bit, I think the error message would be "Dll not found", rather than "Out of memory" (as indicated by David).
If the bitness of EXCEL on the client machine is also 32 bit (the most possible reason I think), can I conclude that the reason is the client's RAM is too small?

Thanks again,
Jackie

[Jackie_J_]

Thanks iliyapolak, IanH and David for your very helpful comments! Thanks!
Now I can understand that for the static requirements of my DLL,  it is the contiguous free virtual memory address space that  makes sense rather than the physical memory. Also the bitness (32/64) of the DLL and Excel is also important, they need to be compatible. It seems to me the bitness of the operating system is not as important.

I have checked my DLL and EXCEL, they are all 32 bit, although they are running on my 64 bit operating system. (I checked DLL using Dependency Walkers and I can find the CPU of all DLLs are of "x86" type. So I say they are 32 bit.). But I am not sure about the bitness and version of EXCEL on the client machine. I will check that.

The client has two machines, one with 8 Gb RAM, the other 2.9 Gb RAM. My DLL works well on the 8 Gb RAM machine, but fails on the 2.9 Gb machine. On my friends' 4 Gb machines with 32 bit EXCEL, my DLL also works.

My further question is:
If the bitnees of EXCEL on the client machine is 64 bit, I think the error message would be "Dll not found", rather than "Out of memory" (as indicated by David).
If the bitness of EXCEL on the client machine is also 32 bit (the most possible reason I think), can I conclude that the reason is the client's RAM is too small?

Thanks again,
Jackie

[Jackie_J_]

Thanks iliyapolak, IanH and David for your very helpful comments! Thanks!
Now I can understand that for the static requirements of my DLL,  it is the contiguous free virtual memory address space that  makes sense rather than the physical memory. Also the bitness (32/64) of the DLL and Excel is also important, they need to be compatible. It seems to me the bitness of the operating system is not as important.

I have checked my DLL and EXCEL, they are all 32 bit, although they are running on my 64 bit operating system. (I checked DLL using Dependency Walkers and I can find the CPU of all DLLs are of "x86" type. So I say they are 32 bit.). But I am not sure about the bitness and version of EXCEL on the client machine. I will check that.

The client has two machines, one with 8 Gb RAM, the other 2.9 Gb RAM. My DLL works well on the 8 Gb RAM machine, but fails on the 2.9 Gb machine. On my friends' 4 Gb machines with 32 bit EXCEL, my DLL also works.

My further question is:
If the bitnees of EXCEL on the client machine is 64 bit, I think the error message would be "Dll not found", rather than "Out of memory" (as indicated by David).
If the bitness of EXCEL on the client machine is also 32 bit (the most possible reason I think), can I conclude that the reason is the client's RAM is too small?

Thanks again,
Jackie

[Bernard]

Actually user process can operate within 2GB of  user address space.

[IanH]

Jackie J. wrote:

Thanks iliyapolak, IanH and David for your very helpful comments! Thanks!
Now I can understand that for the static requirements of my DLL,  it is the contiguous free virtual memory address space that  makes sense rather than the physical memory.

...

The client has two machines, one with 8 Gb RAM, the other 2.9 Gb RAM. My DLL works well on the 8 Gb RAM machine, but fails on the 2.9 Gb machine. On my friends' 4 Gb machines with 32 bit EXCEL, my DLL also works.

My further question is:
If the bitnees of EXCEL on the client machine is 64 bit, I think the error message would be "Dll not found", rather than "Out of memory" (as indicated by David).
If the bitness of EXCEL on the client machine is also 32 bit (the most possible reason I think), can I conclude that the reason is the client's RAM is too small?

As David says - if your client has 64 bit excel - your DLL will not load.  I can't comment on the specific error message.

The bitness of the operating system may still be the important factor.  With the design of Windows, a 32 bit process running on a 64 bit operating system may get to use more of its 32 bit address space than the same 32 bit process running on a 32 bit operating system (particularly given certain linker switches, but also as a consequence of the nature of the 32 bit sub-environment on a 64 bit machine).  The 8 GB machine is likely to be running a 64 bit operating system, the 2.9 GB machine less so.  What bitness operating system is your friend running?

If it is a lack of contiguous virtual address space that is causing the issue (you need to confirm this!) then that would be my next guess as the cause of the apparent variation.

Physical memory shouldn't really come into it, unless the user has limited the size of their swap file.

You or your client can use the vmmap tool from sysinternals to get an understanding of what is occupying a particular process' address space.  When I run it here on my 64 bit OS looking at the free memory space of a new 32 bit excel process, it tells me that the largest single free block of memory in the process' address space is ~450 MB, despite having 1.5 GB total free memory available in the process' address space.

[Bernard]

@IanH

You said exactly what I wanted to recommend.Good advise on using Vmmap tool.

[Bernard]

As it was stated by M.Russinovich in his blog x86 process running inside WoW can use up to 4GB of address space.