I don't know if it's a bug or not, but this is probably related to the "Bitness" COM+ component property: Components Collection

As stated in the doc, "Bitness" can be set to 1 (32-bit) or 2 (64-bit). You can read the Bitness value for a given component using this kind of C# code:

    COMAdminCatalog catalog = new COMAdminCatalogClass();

    ICatalogCollection appCollection = (ICatalogCollection)catalog.GetCollection("Applications");
    appCollection.Populate();

    // browse all apps
    foreach (COMAdminCatalogObject app in appCollection)
    {
        Console.WriteLine("application=" + app.Name);
        // browse all components
        ICatalogCollection compCollection = (ICatalogCollection)appCollection.GetCollection("Components", app.Key);
        compCollection.Populate();
        foreach (COMAdminCatalogObject comp in compCollection)
        {
            Console.WriteLine(" component=" + comp.Name);
            Console.WriteLine(" bitness=" + comp.get_Value("Bitness"));
        }

    }

Unfortunately, Bitness is a ReadOnly property. From what I understand, the underlying COM registration process uses the bitness of the process actually doing the registration to determine how to set this property.

This is implicitely explained in this article: Serviced Components in 32-bit and 64-bit Architectures

As you see in the table, 64 or 32 bit registration depends on the version of the tool you use. That's why a tool such as Regsvcs.exe comes in two flavors: 32 and 64 bits and how your component is registered simply depends on this. Also, pay attention to the fact things may be different if the COM+ application is empty or not.

I guess it means your running .EXE should be compiled in 64-bit.