Where I work we have a lot of in-house developed macros and programs. Many of these use serial communication to send and receive data and controls to instrumentation. Life was good until mid-2009.
What happened? Well that is the question that I have yet to find a good answer. The main issue is that the MSCOMM32.OCX control was given a killbit. To put it very simple Windows was told not to allow this control to run and this resulted in many programs breaking.
Normally such ‘killbits’ are put in place for security vulnerabilities. However this does not seem to be the case as I have yet to find any tech documents stating there is an exploit in this control. Rather it seems that development had stopped on it and as a result it could potentially be a problem. As a result it was given the killbit.
Seems like a bit of a knee jerk reaction but I can see why you would want to gently nudge people away from using outdated controls. No development means if a security flaw is found it will not be patched.
The correct solution is to update the macros and applications to use API calls or supported OCX objects. However you can disable a killbit in the registery. Just remember that the next killbit patch, or in this case IE security patch, will apply the killbit and block the control.
Navigate to the following key and change the value to 0000, it will be at 0400
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{648A5600-2C6E-101B-82B6-000000000014}]
"Compatibility Flags"=dword:00000000