SpaceCoastLife
asked on
Mscomctl.ocx in memory?
I have an Access application that utilizes the mscomctl.ocx common library. With last week's Microsoft security update, they removed some 'vulnerable' controls from the library (one of which we were using). Therefore, we had to release a new version of our program with a new reference within our Access project to the 'new' mscomctl.ocx file and package it in our installer file.
It works like a charm in almost every instance, except one customer I am having problems with. For some reason half of their PC's are still throwing an error when they access the form that utilizes this control. I've tried manually re-registering, unregistering and re-registering the control to no avail. One thing I did notice is that another program that is loaded on these PC's utilizes it's own copy of mscomctl.ocx in a completely different directory.
So, my question is - I'm wondering if ocx files get loaded into memory somewhere and that perhaps what is happening is that my program is not even trying to use the 'new' ocx file, but rather reverting to an old version that is sitting in memory somewhere?
It works like a charm in almost every instance, except one customer I am having problems with. For some reason half of their PC's are still throwing an error when they access the form that utilizes this control. I've tried manually re-registering, unregistering and re-registering the control to no avail. One thing I did notice is that another program that is loaded on these PC's utilizes it's own copy of mscomctl.ocx in a completely different directory.
So, my question is - I'm wondering if ocx files get loaded into memory somewhere and that perhaps what is happening is that my program is not even trying to use the 'new' ocx file, but rather reverting to an old version that is sitting in memory somewhere?
ASKER
Jim,
Already tried that. It has worked on several other machines at this customer's location, but still 3 of them elude me. Where would the O cache folder be and how can I clear it just in case that is the culprit?
Already tried that. It has worked on several other machines at this customer's location, but still 3 of them elude me. Where would the O cache folder be and how can I clear it just in case that is the culprit?
I just double checked and it's no longer used. What I would try is:
1. Clearing C:\TEMP and C:\Windows\TEMP
2. Do a search of the drive for mscomctl.ocx. For any outside of C:\windows\system32 (and just for the moment), rename them to .old (or use your name).
3. re-register the one in C:\windows\system32 again.
4. Reboot
5. Load your app. Remove the current reference. Close the app and Access.
6. re-open, readd the reference, and do a compile and save.
See if that fixes it and doesn't break anything else. If it does break anything, rename the .old's back to .ocx and then see if your app still works.
Jim.
1. Clearing C:\TEMP and C:\Windows\TEMP
2. Do a search of the drive for mscomctl.ocx. For any outside of C:\windows\system32 (and just for the moment), rename them to .old (or use your name).
3. re-register the one in C:\windows\system32 again.
4. Reboot
5. Load your app. Remove the current reference. Close the app and Access.
6. re-open, readd the reference, and do a compile and save.
See if that fixes it and doesn't break anything else. If it does break anything, rename the .old's back to .ocx and then see if your app still works.
Jim.
ASKER
The customer is deployed an mde, not an mdb so I cannot access the references.
<<e customer is deployed an mde, not an mdb so I cannot access the references. >>
Do everything but steps 5 and 6 and see if it runs. if not, you'll need to put a MDB on there, run steps 5 & 6, check that it works, and if so, create a new MDE, and then get rid of the MDB.
Jim.
Do everything but steps 5 and 6 and see if it runs. if not, you'll need to put a MDB on there, run steps 5 & 6, check that it works, and if so, create a new MDE, and then get rid of the MDB.
Jim.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you for all the suggestions, however, none of them have worked.
FYI,
Fixes from Microsoft:
Office 2003:
http://support.microsoft.com/kb/2687323
Office 2007:
http://support.microsoft.com/kb/2687441
Office 2010:
http://support.microsoft.com/kb/2597986
Trick is that the control needs to be un-registered and a registry key deleted for the old control, then re-registered for the new control.
Jim.
Fixes from Microsoft:
Office 2003:
http://support.microsoft.com/kb/2687323
Office 2007:
http://support.microsoft.com/kb/2687441
Office 2010:
http://support.microsoft.com/kb/2597986
Trick is that the control needs to be un-registered and a registry key deleted for the old control, then re-registered for the new control.
Jim.
<<So, my question is - I'm wondering if ocx files get loaded into memory somewhere and that perhaps what is happening is that my program is not even trying to use the 'new' ocx file, but rather reverting to an old version that is sitting in memory somewhere? >>
There used to be an Occache folder with IE 4.0 and earlier, but don't believe there is one now. I would:
1. Make sure your pointed to the one in C:\windows\system32 with your VBA reference.
2. re-register that control
3. reboot and then try the app.
Jim.