Error 429 - ActiveX Component Can't Create Object - Registry Error

I would closely inspect the registry key in installshield installation. The known cause of this message is hex null character somewhere in the key name.

The best would be to inspect the resulting msi file with Orca, to see the end result.

Another way is to use the same procmon to monitor registry writings during the installation.

I am not familiar with Orca.  Can you be more specific?

I checked the GUID for nulls and did not find any, I also ran procmon and have attached the log (renamed extension) file. The GUID for the DLL is d562742c-0181-4ac4-9892-092bc5715a5a.  I did not see anything unusual in the log file but I am not an expert at this.

I did notice the Product Code in Installshield is different {9080330C-5C05-428A-A138-E42F91315068} than the DLL.  Should this be the same as the DLL?  I have read through what little documentation that is supplied with Installshield and it does not really indicate that as being the case.
2014-07-17-LOGFILE.LOG

Let's start from beginning. You said that you receive error 429, "activex component can't create object". Do you know what object is that? If you don't, debug your VBA code and find out.

Once you know the object, let's try to do the same from vbscript: open notepad and create file with the following line:

set myobject=createobject("<the name of the object>")

substitute your object. Save the file as runme.vbs, and run. Will you receive the same error message?

I am a little confused about your post.  The object is contained within a DLL that is referenced in the VBA code in Access. Here is the code that fails:
DIM ITCCode as ITCClass.ITCCom
Set ITCCode = NEW ITCClass.ITCCom  <---This is where the error happens.

I did what you requested and received the error "ActiveX component can't create object: 'ITCCODE" which I would have expected because (albeit I do not know VB script very well) the DLL is not referenced.  

How do I reference the DLL in VBS?

ok, the object then is called ITCClass.ITCCom . So try this vbs:

set myobject=createobject("ITCClass.ITCCom")

...in vbs you don't reference, "createobject" takes care of that.

Open command line and run this:

regsvr32 <full path to your dll>

then try vbs again, see if the error is gone.

I did just that and got the same error as above.

I tried these:
C:\Windows\SysWOW64>regsvr32 "C:\Program Files (x86)\ITC\ITC\itcclass.dll"
C:\Windows\SysWOW64>regsvr32 "C:\Program Files (x86)\ITC\ITC\itcclass.tlb"
C:\Windows\system32>regsvr32 "C:\Program Files (x86)\ITC\ITC\itcclass.tlb"

"The module "blah blah" was loaded but the entry-point DllRegisterServer was not found." was what was received for the DLL

The module "blah blah" may not compatible with the version of Windows that you're running.  Check if the module is compatable with an x86 (32 bit) or x64 (64-bit) version of regsvr32.exe was what was received for the TLB file.  

I tried it with the version of regsvr32 in the sysWOW64 folder and the one in the system32 folder.  Same result either way.

If the dll fails to register correctly, it's 100% fault of the developer of this dll. You have two choices:

1. contact the developer; don't mention the installation or Access, because they will blame those. Mention only the fact that regsvr32 ran successfully, but then createobject fails. This is ironclad proof that the dll is wrong.

2.  run process monitor, monitor file and registry activity, find out what's missing, and recreate it by hand in the registry. If it works, put the fix in the installation.

Of course, #2 is quite sophisticated undertaking, especially since you said you have limited experience with COM; so it makes sense only if the developer does not cooperate.

To do #2, modify vbscript:

msgbox "ready to createobject"
set a = createobject("ITCClass.ITCCom")

run vbscript; when you see the message, run process monitor, and immediately click "OK" in the message, once the error is on the screen, immediately stop process monitor. You can filter only for process wscript, to make it easier. Then inspect the trace and find out what has failed.

The positive side is that if you manage to resolve #2, you will have all reasons to change "but I am not an expert at this" to "and I am quite an expert at this." :-)

try

C:\Windows\system32>regsvr32 "C:\Program Files (x86)\ITC\ITC\itcclass.dll"

(not .tlb)

This is a .NET DLL so the TLB is what registers not the DLL. Not sure why this is the case and he DLL will not register on a 32 bit machine either, the TLB does.

I am the developer.  What could be wrong with the code?  It only fails on a 64 bit machine and it is being built with the target CPU = "Any CPU".

If this is .net dll, then it has to be registered by regasm, with the option /codebase.

Let's take a step back for a minute.  In VS2008 using the old packaging (setup) it works fine on a 32 bit and 64 bit machine.  It does not work on VS2013 with Installshield.

What was the value of the property "Register" of the primary output in vs2008 s&d project?

vsdrpCOM

vsdrpCOM means that all registry information has been extracted from the dll by Visual Studio and then Installer created those registry keys by itself.

So in order to find out why it's not working now on Windows 2012, there are two possibilities: either something is wrong with the dll itself, or with the installation.

That's why I suggested that you register it bypassing the installation. Since this is .net dll, this should be done by regasm. If you find that once it's registered by regasm, it works, but when it's registered by the installation, it does not, it will mean that the fault is in the installation. Then, the next step will be to compare registry keys created by both, and find the difference. If however you find that it does not work even when registered by regasm, then it will mean that something is wrong with the dll itself.

I would experiment with creating a trivial project in visual studio - create COM class with one public method, create the installation, install, then try to createobject and call the method from vbscript.

I got this message when I tried to regasm:

RegAsm : warning RA0000 : Registering an unsigned assembly with /codebase can cause your assembly to interfere with other applications that may be installed on
the same computer. The /codebase switch is intended to be used only with signed
assemblies. Please give your assembly a strong name and re-register it.
Types registered successfully

I am going to correct this but do you think this is the cause?

I cannot sign the assembly.  There is a 3rd party COM object/interface that errors during the build when I try to sign the assembly I am building.  It is older code that I do not have access to and is no longer supported and it does not have a strong name.

However, I tried  regasm with the /codebase switch and it works even though I get that warning.

Based on what you are saying, are you recommending I bypass the install and do this with a batch file?  How can I resolve this?

The warning is only a warning, it still should work (and does).

> Based on what you are saying, are you recommending I bypass the install and do this with a batch file?  How can I resolve this?

No, as I said, the next step is to inspect the difference between the registry entries created by installshield and registry entries created by regasm. Something will be different, and depending on what is is, it will have to be addressed.

There are two ways to inspect. One is looking into the MSI using capable tool such as Orca (which requires being familiar with the structure of MSI); another is to inspect registry entries in the system created by each method (which requires being familiar with COM-related registry information, so you know where to look). The third is to upload you installation (renamed from .msi to .txt) for us to take a look.

Does your limited installshield offer any other way to register COM? such as, in VS2008 besides vsdrpCOM you had vsdrpSelfReg. Is there an equivalent in Installshield?

I cannot find an option to change the method of registering a COM file in the limited edition, of course most of the options are not available.  However I am still looking.  It sure would be nice if the folks at Installshield would answer my support question.

I did add a custom step to run regasm  /codebase which is NOT a long term solution however it did work.  

I am not familiar with MSIs.  I can get around in the registry and understand it but I do not know com-related registry information.  

I have attached the setup renamed to *.txt.
setup---Copy.txt

Very, Very helpful.  Thanks

It worked.  Thanks for being helpful.

FYI: I knew the custom action was not going to work every time I did it as a test.  I have removed it from the project.  Again, thanks.

As a final note - I think, the reason why your installation, even with pretty much all COM registration missing, still worked on some machines, is most likely because it was already installed on those machines, such as by the previous version. Always test installations only on clean machines. The easiest way is to have several v.m.'s with different operating systems, freshly installed, and to have a snapshot of each made immediately after the installation. Then you can always reset the v.m. to that clean state with one click, and test.