I am in the process of upgrading some dated VBScript automation for Powershell on one of our servers running Windows Server 2012 R2. Currently, I'm working on replacing a script that requires the creation of a COM object from a third-party 32-bit DLL. First, I installed the third-party program that contains the DLL; it installed fine and runs correctly. I then attempted to create the COM object in Powershell, which failed and gave me back the error "80040154 Class Not Registered" with a CLSID that was NOT all zeros.
I attempted to troubleshoot and found that it created the COM object if I used the Powershell (x86). I figured then that maybe that the DLL was not registered for 64 bit Powershell, and used sysWoW64/regsvr32 to register the DLL. This did not solve the issue, so I also registered it with system32/regsvr32 which also did not solve it.
I then turned to Google and found this solution from 2009: Solution Link. This actually did solve the problem, allowing the COM object to be created and used in 64-bit Powershell. However, this is very much a hack and having to edit the registry by hand isn't the most maintainable solution.
So, my question is this: how should I properly set up a 32-bit DLL to run with 64-bit Powershell? What is the "proper" way of performing the above solution?
Best Answer
If you're stuck with that kind of DLL, you'll probably have the best luck if you run the script with the 32 bit version of Powershell or VBscript from the SysWow64 path. It may seem backwards, but the 64 bit EXE's are located in System32.