please wait while windows configures ...

[Magnus]

Hello, please help me understand why my customers received this message (see attachment).

Our developers/customers need to change a *.exe file in the release folder, I when they do, they receive "Please wait while windows configures ...".

I have turned of all (I think) Advertised settings on the program shortcut in InstallShield, that that won’t help at all. Is there any way to do this?

Thanks for helping me !!!

/Magnus

[Magnus]

What is the trigger?

[Magnus]

The problem seems to be that the changed file was defined as an key file in InstallShield: http://forum.installsite.net/index.php?showtopic=19869

Is there another way to control this in InstallShield?

[Magnus]

Can this have something to do with MergeModules?

Are there any eventlog that shows whats trigger the msi installer?

Please help!

/Magnus

[joshstechnij]

Auto repair information is logged as two separate MsiInstaller events in the Application event log on the machine (use Event Viewer to view the entries). One log entry indicates what component in the MSI triggered the auto repair check (an advertised entry point such as an advertised shortcut, file extension/verb registered with the Extension and Verb tables of the MSI, or a COM class ID registered with the Class table of the MSI). The other entry indicates what resource Windows Installer believes was missing.

See Searching for a Broken Feature or Component for more information.

[Magnus]

Thank you, Is there any way I can turn of this auto repair behaviour in my installation?

When browsing the Event log, I can see that there is an .ocx file that seems to trigger the reinstallation. This ocx component is set to "Self register".

I don't know why this ocx file generates this event?

Regards
/Magnus

[joshstechnij]

The triggering component needs to contain one or more of the following advertised entry points to actually trigger an auto repair operation:
- An advertised shortcut (unlikely on a component containing an OCX)
- A file extension/verb registered with the Extension and Verb tables (again unlikely on a component with an OCX)
- A COM class ID registered with the Class table (normally populated through COM extraction)
- An MSI API call in the application such as MsiProvideComponent, MsiQueryFeatureState, MsiGetComponentPath, MsiLocateComponent

The most likely entry point from the above possibilities is the COM class ID. If you open your MSI package in Orca or InstallShield and look at the Class table, is the component code from the auto repair entry listed in any records of the table? If so, this would serve as a trigger point whenever this class is instantiated (through CoCreateInstance or any equivalent). This data would likely only have been populated through COM extraction (COM extract at build or by right-clicking the file in the IDE and selecting 'Extract COM Data for Key File'). Changing to self-registration instead of using an COM extracted data should eliminate this entry point.

As far as disabling auto repair for your project, there isn't really any foolproof way to do so. You can try to eliminate any advertised entry points, or isolate them in a standalone parent feature that is hidden (auto repair works up from the feature containing an entry point).

The following articles might provide some useful information:
INFO: Description of Resiliency in Windows Installer
How To Disable Windows Installer Resiliency

Note that in the last article, the suggestion provided completely disables Windows Installer so no MSI package will be configurable at that point.

[Magnus]

Thanks, your answer where very helpful.

[Magnus]

I removed the ”COM Extract at Build” for my ocx files in my installshield project and installed in. When I differ the two installations, the only thing that differ is the "InprocServer32" under registry entry [HKEY_CLASSES_ROOT\CLSID\{41F841C7-AE16-11D5-8817-0050DA6EF5E5}\InprocServer32].

When removing the "InprocServer32", the auto repair no longer starts. Is it safe to just let the customer remove this key by running a .reg file containing:

[FONT="Courier New"][HKEY_CLASSES_ROOT\CLSID\{41F841C7-AE16-11D5-8817-0050DA6EF5E5}\InprocServer32]
"InprocServer32"=-[/FONT]

More about InprocServer32 can be found here: http://blogs.msdn.com/b/astebner/archive/2005/01/13/352649.aspx

[Videstra]

I too was having the same issue. Remove ALL Com Extract at Build options from your com components. Do this under Installation Designer -> Components  for each component.  I make sure ALL components have this set to No. 

Next, for every com component you are distributing you need to open the component (double click) and select files (personally I think it's good practice to have only ONE file for each component).  Right-click on the file and make sure Self Register is checked.

But First: make sure the file does indeed need to be registered.  If you are redistributing controls from a third party not every file will need to be registered.  Unfortunately I haven't found a quick way to determine this so I run Regsrv32.exe on every file from an administrative command prompt.  If it needs to be registered you will get a success popup box.   If it doesn't need to be registered you will get an error about not finding an entry point.  That's cool, just ignore it and make sure you do not check Self Register.

Note: I have had a couple of components that NEED to be registered not return either a success or error.  If that is the case then assume it needs to be registered and check Self Register.

Note 2: if your components are 32 bit make sure you are testing with Regsvr32 from c:\windows\syswow64 instead of the one from c:\windows\system32.  The one in syswow64 is for 32 bit controls, the one in system32 is for 64 bit controls.