Serious Bug in Installshield X Extract COM at Build
I have recently upgraded an Installscript MSI installation project from Developer 8 to Installshield X.
On running the new instalation the product installed and ran OK, however when uninstalling and rebooting the target PC I had lost all my network settings and could not access the network. As this was a Win2K machine I had to rebuild the whole hard disk to get the IP configuration data back.
I found that the following registry key tree had been deleted during the uninstall.
After much searching I found that the reason this key was deleted was because the Extract COM at Build for one of the COM dlls in the installation was creating the following entry in the msi Registry table
Key = SYSTEM\CurrentControlSet\Services\Tcpip\Parameters : Name = * Component = SASMTP.dll
The Extract COM at Build function for the same DLL in Developer 8 had this for the same table entry. (Value = blank)
Key= SYSTEM\CurrentControlSet\Services\Tcpip\Parameters : Name= Component = SASMTP.dll
It looks to me like this is a bug in the Installshield X implementation of the Extract at build function, as the DLL itself is a third party one which has not changed from the Developer 8 installation.
If I edit the MSI file using orca I can delete the * from the table entry and the uninstall works correctly, without deleting the TCPIP parameters registry keys.
I have a couple of log files and registry snaphsots to show the results, if anyone is interested.
I assume the only way to get past this is to set the Dll to self register, then the registry table entries wont be created in the first place.
Hope this saves someone spending three days chasing their tails.
While I agree that this is a pretty serious symptom, I just wanted to offer a slight alternative for this scenario. Since the DLL in question is not changing, you can pre-extract the COM information into your project itself. Then you can edit it if necessary, and still reap the MSI benefits of having registration in the MSI instead of through self-registration.
This is a less palatable alternative when the DLL changes often, especially so if the registration can change.
By the way, if you know of any generally available available DLLs that reproduce this, it'd be great if you'd submit a bug report through http://www.installshield.com/feedback/ that references where to get the DLL one can test with.
I think your suggestion will work for this COM DLL as it is not one that will change between releases.
I have run the Component wizard on the COM dll in question to extract all the required COM information and then rebuilt the installation.
On checking the registry table in the reulting .msi database, the [System\CurrentControlSet\Services\TCPIP\Parameters] registry key is present but this time does not have the * for the Name field.
The table entries for this component are identical to those produced using COM Extract at Build in Developer 8.
IS 11 Pro has it also
I experienced this in IS 11 also ... It took me several hours to find a solution for this. CurrentControlSet has bakups in registry
HKLM\SYSTEM\ControlSet001 002 and so on.
So what you have to do is to look in one of these backups (or on another mahcine but this is more complicated)
and export HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\Tcpip to a .reg file. (its not only parameters node that its affected) but before that be sure it contains the proper (complete structure)
have to contain data (ip, net mask, domain ..etc)
After you export it to a file, edit the file and replace ControlSet00x with CurrentControlSet in the entire file and run the registry file.
It works after this, but you have to make sure that all ControlSet00x are fine, because, at eachi system boot one of the 00x ControlSets are restored to CurrentControlSet, so all must be correct
Another possibility is to take this configuration from another machine and adapt it... sometimes it could be the only option.
Ah and don't forget to disable the extract com info at build flag
Last edited by clehene; 11-21-2005 at 03:50 AM.
I ended up doing a couple of things.
1. I used Michaels suggestion and pre-extracted the COM data from the dll into my installshield project. As he says this is OK if the dll in question doesnt change.
2. In the Installscript I wrote two functions to store / restore the TCPIP registry keys to / from a temporary reg store.
I call "Store_TCPIP_ParametersRegistry()" in the OnBegin event handler and "Restore_TCPIP_ParametersRegistry()" in the OnEnd event handler for the installation.
The functions I wrote are below.
// FUNCTION: Store_TCPIP_ParametersRegistry()
// DESCN: This function copies the vulnerable TCPIP registry keys to a temp
// reg store in case the major upgrade of a previous version deletes
// the TCPIP parameters.
// The stored data is replaced in the registry after the installation of
// this version prior to demanding a reboot.
// The following keys are copied to
// Copy the HKLM/SYSTEM/CurrentControlSet/Services/TCPIP/Parameters
// hive. to a temp reg key
RegDBCopyKeys ("SYSTEM\\CurrentControlSet\\Services\\TCPIP\\Parameters", "SOFTWARE\\MyTempKey\\CurrentControlSet\\Services\\tcpip\\parameters", HKEY_LOCAL_MACHINE, HKEY_LOCAL_MACHINE);
RegDBCopyKeys("SYSTEM\\ControlSet001\\Services\\TCPIP\\Parameters","SOFTWARE\\MyTempKey\\ControlSet001\\Services\\tcpip\\parameters", HKEY_LOCAL_MACHINE, HKEY_LOCAL_MACHINE);
RegDBCopyKeys("SYSTEM\\ControlSet002\\Services\\TCPIP\\Parameters", "SOFTWARE\\MyTempKey\\ControlSet002\\Services\\tcpip\\parameters", HKEY_LOCAL_MACHINE, HKEY_LOCAL_MACHINE);
// FUNCTION: Replace_TCPIP_ParametersRegistry()
// DESCN: This function is designed to replace the copied TCP_IP
// parameters keys to their original locations.
// The temp keys are then deleted.
number nvType, nvSize;
// read the corresponding element from each list in turn
// and set it to the registry if the reg key does not exist.
if (RegDBGetKeyValueEx("SYSTEM\\CurrentControlSet\\Services\\TCPIP\\Parameters", "Domain", nvType, svValue, nvSize) < 0) then
// the key did not exist so copy the keys back from the temporary store.
RegDBCopyKeys( "SOFTWARE\\MyTempKey\\ControlSet001\\Services\\tcpip\\parameters" , "SYSTEM\\ControlSet001\\Services\\TCPIP\\Parameters",
RegDBCopyKeys( "SOFTWARE\\MyTempKey\\ControlSet002\\Services\\tcpip\\parameters", "SYSTEM\\ControlSet002\\Services\\TCPIP\\Parameters",
// delete temp copy of tcp_ip registry entries
This was a bit belt and braces but did get me past the problem.