About a year ago I was working on building our DotTwain ActiveX control and wrote two articles on some useful tips that I discovered. Since that time, I’ve seen a problem on a few customer computers where, after upgrading once, the control would never run. Instead, it would just try to reinstall after every page load.
After much frustration, it turned out that the problem is related to a little-known Internet Explorer registry entry called VerCache.
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{GUID}] "VerCache"
I figured this out after noticing that every machine exhibiting this problem had the same value for VerCache. Once the VerCache was set to this value, uninstalling did nothing. The repeated-reinstallation behavior happened with any new version installed which shared the control GUID.
What’s a VerCache?
Strangely enough, searching for “VerCache” ActiveX gives you little more than an IE Team blog post and one MSDN forums entry.
At first, I was very excited when I found this IE team blog post. It appeared that I had found my solution.
Here in the above mentioned screenshots they both are having same file date time stamps and that Causes the VerCache registry key to not get updated.
To resolve this , ensure that at least one of these parameters - “Created” date time stamp, “Modified” date time stamp or the file size, on the updated control is different from the old version of the control and you should be GTG!
Unfortunately, this information seems to be incorrect, or at least overly vague. I observed the same bad VerCache value on different machines with different version of the control. Each of these had different “created” and “modified” time stamps. In fact, the CAB, the installer in the CAB, and the control assembly itself each had different “created” and “modified” time stamps for every single version. I even tried updating the INF and setup launcher timestamps to no avail.
The only thing which did not vary consistently was file size as we rebuild and repackage our control for each DotImage version we release.
Some of the things I tried or considered.
Early on, I discovered simply deleting the registry key after uninstalling fixed the issue temporarily and was under the impression that it was a single bad version of the control causing this. So, I wrote a small cleaner utility to fix the issue. However, as time wore on it was apparent that this issue occurred in a somewhat random fashion with all versions of the control.
Another simple fix I thought about was updating the control GUID with each version. However, this would require updating both our documentation and demos with every build. Additionally, our customers would need to update their javascript with every upgrade. This was unacceptable.
The next thing I tried was to have the installer launch a custom console program on install which cleaned the registry value. This worked great in XP. However, in Windows 7 the console program, even as admin, did not have access to the registry values I wanted to delete.
Finally, a solution.
In the end the only solution I found worked consistently and met our needs was to put custom installer actions into the control itself. When both installing and uninstalling the installer calls the control’s custom actions which removes any existing VerCache value for the control.
First, I snagged a class I had made previously for cleaning guid-based registry entries:
Code Snippet
- public delegate bool RegActionBreakOnTrue(RegistryKey basekey, string key);
-
- public class EventArgs<T> : EventArgs { private T eventData; public EventArgs(T eventData) { this.eventData = eventData; } public T EventData { get { return eventData; } } }
-
- public class RegGuidCleaner
- {
- string _guid;
- public RegGuidCleaner(string guid)
- {
- _guid = guid;
- Locations = new string[] {};
- }
-
- public string[] Locations { get; set; }
-
- public RegistryKey GetPathBase(string path)
- {
- RegistryKey baseKey;
- if (path.StartsWith(@"HKEY_CURRENT_USER\"))
- baseKey = Registry.CurrentUser;
- else if (path.StartsWith(@"HKEY_LOCAL_MACHINE\"))
- baseKey = Registry.LocalMachine;
- else
- throw new ApplicationException("Unexpected location type: " + path);
- return baseKey;
- }
-
- private string GetBaselessPath(string location)
- {
- string truncatedLoc = location.Substring(location.IndexOf('\\') + 1);
- return truncatedLoc;
- }
-
- public void PerformRegActionForEach(RegActionBreakOnTrue action)
- {
- foreach (var location in Locations)
- {
- string fullPath = location + _guid;
- RegistryKey baseKey = GetPathBase(fullPath);
- string baselessPath = GetBaselessPath(fullPath);
-
- if (action(baseKey, baselessPath))
- break;
- }
- }
-
- public bool EnteriesExist
- {
- get
- {
- bool doesKeyExist = false;
- PerformRegActionForEach((baseKey, subkey) =>
- {
- var key = baseKey.OpenSubKey(subkey);
- if (key != null)
- {
- doesKeyExist = true;
- return true;
- }
- else
- return false;
- });
- return doesKeyExist;
- }
- }
-
- public void DeleteEntries()
- {
- PerformRegActionForEach((baseKey, subkey) =>
- {
- try
- {
- Messages(this, new EventArgs<String>("Deleting Registry Key: " + baseKey.ToString() + @"\" + subkey));
- baseKey.DeleteSubKeyTree(subkey);
- }
- catch (Exception ex)
- {
- Messages(this, new EventArgs<String>(ex.ToString()));
- }
-
- return false;
- });
- }
-
- public event EventHandler<EventArgs<String>> Messages = delegate { };
- }
Please forgive the catch (Exception ex). So far it has been unnecessary to handle failure cases for anything other than logging.
Next, I added a custom installer class to remove the entries:
Code Snippet
- [RunInstaller(true)]
- public partial class RegistryCleanerInstallerClass : Installer
- {
- public RegistryCleanerInstallerClass()
- {
- InitializeComponent();
- }
-
- private void CleanVerCache()
- {
- try
- {
- RegGuidCleaner cleaner = new RegGuidCleaner("{" + typeof(AcquisitionControl).GUID + "}");
- cleaner.Locations = new string[] {
- @"HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\",
- };
-
- cleaner.DeleteEntries();
- }
- catch { }
- }
-
- [System.Security.Permissions.SecurityPermission(System.Security.Permissions.SecurityAction.Demand)]
- public override void Install(IDictionary stateSaver)
- {
- base.Install(stateSaver);
- CleanVerCache();
- }
-
- [System.Security.Permissions.SecurityPermission(System.Security.Permissions.SecurityAction.Demand)]
- public override void Commit(IDictionary savedState)
- {
- base.Commit(savedState);
- }
-
- [System.Security.Permissions.SecurityPermission(System.Security.Permissions.SecurityAction.Demand)]
- public override void Rollback(IDictionary savedState)
- {
- base.Rollback(savedState);
- CleanVerCache();
- }
-
- [System.Security.Permissions.SecurityPermission(System.Security.Permissions.SecurityAction.Demand)]
- public override void Uninstall(IDictionary savedState)
- {
- base.Uninstall(savedState);
- CleanVerCache();
- }
- }
I also decided to move the com registration into a custom action as well. The installer-based registration had been intermittently not working which caused us to hand test every release version of the control before sending it out.
Code Snippet
- [RunInstaller(true)]
- public partial class ComRegisterInstallerClass : Installer
- {
- public ComRegisterInstallerClass()
- {
- InitializeComponent();
- }
-
- [System.Security.Permissions.SecurityPermission(System.Security.Permissions.SecurityAction.Demand)]
- public override void Install(IDictionary stateSaver)
- {
- base.Install(stateSaver);
-
- try
- {
- RegistrationServices regSrv = new System.Runtime.InteropServices.RegistrationServices();
-
- if (!regSrv.RegisterAssembly(
- this.GetType().Assembly, AssemblyRegistrationFlags.SetCodeBase))
- {
- throw new InstallException("Failed to register componenet for COM interop");
- }
- }
- catch
- {
- }
- }
-
- [System.Security.Permissions.SecurityPermission(System.Security.Permissions.SecurityAction.Demand)]
- public override void Commit(IDictionary savedState)
- {
- base.Commit(savedState);
- }
-
- [System.Security.Permissions.SecurityPermission(System.Security.Permissions.SecurityAction.Demand)]
- public override void Rollback(IDictionary savedState)
- {
- base.Rollback(savedState);
-
- try
- {
- RegistrationServices regSrv = new System.Runtime.InteropServices.RegistrationServices();
-
- if (!regSrv.UnregisterAssembly(this.GetType().Assembly))
- {
- throw new InstallException("Failed to unregister componenet for COM interop");
- }
- }
- catch
- {
- }
- }
-
- [System.Security.Permissions.SecurityPermission(System.Security.Permissions.SecurityAction.Demand)]
- public override void Uninstall(IDictionary savedState)
- {
- base.Uninstall(savedState);
-
- try
- {
- RegistrationServices regSrv = new System.Runtime.InteropServices.RegistrationServices();
-
- if (!regSrv.UnregisterAssembly(this.GetType().Assembly))
- {
- throw new InstallException("Failed to unregister componenet for COM interop");
- }
- }
- catch
- {
- }
- }
- }
Finally, I added the the custom action calls to the installer.
This still won’t allow an existing broken control to upgrade. However, after manually uninstalling the old control, the new one will install and work fine. At least that’s what I’ve found in IE 8.0.7600.16385 Update 0 on Windows 7 Enterprise 64-bit. ActiveX tends to be a bit of a moving target these days.
Now, let’s hope I never need speak of this again.