- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- please wait while windows configures ...
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
please wait while windows configures ...
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Is there another way to control this in InstallShield?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Are there any eventlog that shows whats trigger the msi installer?
Please help!
/Magnus
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
See Searching for a Broken Feature or Component for more information.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
- 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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)