"%1 is not a valid Win32 app" error loading plugin

Using XE2 w/ your plugins: My development machine is running Win7 SP2 32-bit.  One of our QA machines is running Win7 SP2 64-bit.  I have an app and plugins that are complied as 32-bit (building this as 64-bit is not an option; we have way too many customers still on 32-bit platforms), that dynamically loads 3 plugins at start-up, 2 of which interface a COM object.  The app and plugins work fine on my development machine and on a co-worker's Win7 32-bit machine that also has XE2 installed on it.  However, on the 64-bit QA machine that does not have any development tools installed on it, I get the following EPackageError exception attempting to load one of the plugins:

%1 is not a valid Win32 app

I've tried juggling the load order of the 3 plugins, and the error always occurs on the same plugin.  I've tried building with various compiler and debugging options, and still get the error.  As far as I can tell, all the necessary BPLs are on the target machine.

Any ideas would be greatly appreciated!


Most of our development machines here are 64bit and so far, we haven't see this issue here. Have you checked if this is specifically related to the COM object use in one of the plugins? Did you perform a test if you could use this COM object without issues directly from the main application (i.e. NOT via a plugin) in your application on the Win64 machine?

Bruno -

I will test those things.  However, two of the plugins access the same COM server via their own instance of the same interface component (the COM server is a service that interfaces several different types of industrial process-control
hardware; the
plugins allow me to tailor support for the different devices on each
customer's system), and one of those plugins does load and run properly on the 64-bit platform.  Also, the plugins do not attempt to connect to the server until after the plugin has loaded and other initialization code is called in the plugin to connect to the ABS database, load config settings and the like, so my suspicion is that it's not related specifically to the COM object, but to some combination of what other things are used by the plugin package.

I'll test the COM object from the main app on the 64-bit platform and let you know.