Fix: Out of Memory Errors in SSIS When Loading Older 32 bit DLLs

Fix: Out of Memory Errors in SSIS When Loading Older 32 bit DLLs

Day by day, we’re getting further away from needing to use 32-bit DLLs. One place where I keep coming across them, is when doing integration work. The problem is that there are many 32-bit drivers for older systems, and no-one is going to ever bother to write 64-bit drivers for them. So, if you have to use those drivers, you need to run the 32-bit versions. And SSIS has options that allow you to run 32-bit drivers.

Confusing error message

One customer was recently seeing Out of Memory exceptions when trying to load a 32 bit ODBC driver from within an SSIS package.

That’s one of the classic misleading error messages. I wrote about some of them here .

What’s actually happening

When the package was run from the command line using the dtexec utility, all was fine. When the package was run from within the SSIS Catalog, the same package refused to run. They had presumed it was some issue to do with 32-bit vs 64-bit drivers. In this case, the customer was lucky, and there was a 64-bit driver available, and using it instead, resolved the issue. But not everyone is so lucky.

It’s important to know that when you see an Out of Memory error on attempting to load a 32-bit DLL, it usually doesn’t mean anything about memory at all.

Under the covers, in 32 bit Windows, loading an accessing a function in a DLL was performed by:

  1. Making an API call to LoadLibrary() – this brought the DLL into memory if it wasn’t already present
  2. Making an API call to GetProcAddress() – because the DLL could be located anywhere in memory, there was a need to locate the actual memory address of the procedure in the DLL in its loaded location
  3. Making a call to the address returned by the GetProcAddress() call.

With my previous developer hat on, there are several places where I’ve seen this go wrong.

One is that people don’t check the return address from GetProcAddress(). It can return null if the procedure isn’t found. So someone who writes code that just says to call the address returned, without first checking to see if it is null, would end up generating the previous infamous this program has performed an illegal operation and will be shut down message that we used to see so often.

The less common problem was that LoadLibrary() had its own qwerks. The worst was that if it could not locate the DLL that it thought used to be there, the error returned was Out of Memory. I always thought that was one of the silliest error messages to ever come out of Windows, but it’s entirely relevant here.

When you see that error when attempting to load a 32 bit DLL, it’s time to check whether the DLL can be located by the process. The easiest option (although not necessarily the cleanest one) would be to make sure the DLL is in the GAC (global assembly cache).

2026-06-29