We have a VB6 application that uses a COM object to communicate with an email package. The app runs autonomously and every once in a blue moon the COM DLL seems to become unregistered. A quick call to RegSvr32 and the system is back to happy.
We tried implementing a quick fix that registers the DLL every time the application is going to need it, but that doesn’t seem to have worked.
This has become quite an annoyance.
In case you are wondering the app just calls a shell command.
Shell "regsvr32 /s " & """" & pathName & """"
Does anyone have a idea of what can cause a COM DLL to become unregistered?
I've seen strange things happen with COM DLLs due to virus scanners and anti-spyware software. If you can, try disabling these apps if you have them.
Just a guess but is the DLL, or more likely another version of the same DLL, being registered at different file location? For a COM DLL if it were the same version and were being called normally (by GUID or name) it shouldn't matter, I don't think, but worth checking.
I do have a solution to this problem now. The email package is Outlook and that is key to the issue. The COM object was not actually becoming unregistered in the system it was failing to load in Outlook which seems to be a more common occurance, though still rare. Apparently there are some odd situations where outlook will just stop loading COM add ins all together.
For a link to a KB article KB945743
The solution is to unload the COM object from Outlook and reload it.
OR something is unregistering it or another version newer or older of the same com object is running and autoregistering the com in the same path of the executable, this is weird but this can occur
And one of them will not run if both applications are executed, one will fail
VB6 com files are autoregistered if the com file is in the same path of the executable