Terrell,
The answer is a bit complicated and the link provided previously is not completely accurate. It is likely just luck as to why one works and the other doesn't. The development and run-time environment should allocate memory in essentially the same ways. Basically, 32-bit apps have a maximum of 4GB of virtual memory space total. This is used not just for storing user data like images, but also all the DLLs and other resources the application uses must all share this space. On a default Windows 32-bit setup, this is actually only 2GB because the kernel traditionally owns the upper half of that memory address range.
Secondly, once something has been assigned an address, it generally cannot be moved unless it is first free'd and then re-allocated. What this means is that the 2/4GB of address space tends to get fragmented quite a bit. When you are allocating your 128MB image it must occupy a contiguous piece of virtual memory (not physically contiguous, just virtually). Many times the memory space is so fragmented that getting multiple large chunks of this size is hard of not impossible. What I image might be happening is just the slight differences in the built-app versus running within the development environment is changing the memory layout slightly and causing such that maybe there aren't enough big blocks still free.
There are a couple of things you can do to try to help. The first would be getting the tool here:
VMMap http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx
This nice tool lets you see the virtual memory map for a process. You can see how many blocks of memory are free and how big they are if you play with the sorting options. This will let you confirm what you are seeing.
Additionally, as I alluded to above, there is a way to increase the amount of virtual memory available to a 32-bit process from the default 2GB to either 3 or 4GB. The latest versions of LabVIEW are compiled with the /LARGEADDRESSAWARE flag that tells them that they can handle the whole 32-bit address range. If you boot your 32-bit system with the /3GB switch any such apps will now have 3GB of address space. Additionally, if you run such apps on a 64-bit OS, those apps will now have 4GB of virtual memory. This can help the amount of large free blocks immensely. You can look in VMMap to see how much memory a running application has access to to see if your built app has access to the same amount of memory in total as the LabVIEW development environment.
Lastly, the next option would be to consider moving to a 64-bit version of LabVIEW. With LabVIEW 2009 64-bit you effectively have a virtual unlimited memory address space and this becomes a non-issue. You'll have to pair that with the 2009 versions of Vision Acquisition and Vision Development Module and run on a 64-bit OS of course.
Hope this helps a bit,
Eric
