Enigma Protector

We have a 32 bit compiled .NET 4.0 application that has an embedded x86 ActiveX control.

We have set the following options when packing the software:

Map executable files using temporary file
Share virtual system to child processes
Allow running of virtual executable files

We also set HKEY_CLASSES_ROOT and HKEY_LOCAL_MACHINE as a virtual registry and compressed the package.

We get the following error when starting the packed application directly on 40% of one of our customers machines but not on the other 60%. All machines are running Windows XP SP3 32 bit and have .NET 4.0 framework installed.

Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

Any idea what the problem might be?

Note we are using Enigma Virtual Box 5.80 Build 20121129

Just to let you know that our customer tried a manual installation with the unpacked version of our software now on the systems where the packed version gave the above error and it worked fine. They had to manually call regsvr32 etc. to register the ActiveX control.

So this confirms that there must be some kind of compatibility issue here. What kind of thing could be the problem?

This customer is able/willing to run debug tests etc. if it will help to solve the issue.

A reminder that the error we get when the packed software is used (on 40% of the XP machines for the customer only) is:

Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

Can you please send us non packed sample at vbox@enigmaprotector.com?

I would be glad to help to identify the problem.

I have sent the non packed sample to you for analysis.

Thank you very much for your help to try and resolve this.

Please check your email, I have sent you new version of EVB that probably fixes this problem.

Thank you. We tried with enigma virtual box v6.0. This change to enigma virtual box did seem to prevent the "Class not registered" error but the customer was still unable to run the packed version directly on their XP machines. So there must be some other issue also.

Now the customer gets a different application error message from the packed application which signifies that either a .INI file in the %WINDOWS FOLDER% can not be found by the embedded ActiveX or the file was found and the relative path inside that .INI file used by the ActiveX inside the application was not going to the correct path after registration of the embedded ActiveX. This problem appears on some machines at the customer site only.

Any idea how we can fix it?

Issue is application specific, carried to discussion by emails.