OS: Windows XP Home SP2 with Automatic updates every day at 3AM; Machine: Toshiba Satellite M35X-S311; 80% of hard drive free.
My trial version of Office 2003 expired 1/31/06 (no warning messages received prior). I couldn’t access Control Panel (system32/CoPM.cpl error). No System Restore points prior to 1/31/06.
Ever since 1/31/06, windows installer pops up on every application (explorer, print, office). “Preparing to Install just hangs there for a couple of minutes — for everything.
Spyware, adware and malware has been scanned and removed. I’ve also had my machine scanned by Hijack this, Norton SystemWorks and Registry Mechanic, and no problem can be found.
I’ve been to the MS support pages, and have tried
- update installer (did not help)
- Modify the Registry (article 265194; effective for Office 2000)
- I’ve downloaded Windows Install Cleanup, but am not experienced enough to handle any problems that may ensue
I can’t begin to tell you how much this affects my work. I’ve lost 5 days of writing — which is how I earn my living — and I’m obsessed with getting my computer back the way it used to be.
Please tell me how to fix this — this is a major disaster for me.
I’m sorry to hear you’re having these problems. It sounds like it’s quite frustrating and you’ve run out of options. If the following information doesn’t allow you to unblock yourself, I encourage you to call Microsoft Product Support Services.
I try and answer question in three parts:
- why is this happening?
- what is really failing?
- how can I fix this?
- Why is this happening?
- What is really failing?
- Every time I launch my application, Windows Installer performs an installation. How can I determine the cause of the on-demand installation?
- How can I figure out why my package fails to install?
- a client program is trying to assure the correct state of an application.
- a client is calling a Windows Installer API (such as MsiGetComponentPath)
- the system is in an inconsistent state and thereby unable to fulfill the request
- two or more packages installed to the system are inconsistent creating a conflict on the system.
- the sequence of system (Windows Installer system service) and application (client code and application packaging) functionality is unable to correct the triggering state thus the event is triggered again
- How can I fix this?
- Repair (msiexec /famus …)
- Uninstall and reinstall (msiexec /x … followed by msiexec /i …)
- Install again (msiexec REINSTALLMODE=”famus” /i … )
Creating stable corporate computing platforms was a pillar for the Total Cost of Ownership initiative for the Windows 2000 generation of releases. Part of that effort was the Windows Installer Resiliency features. In the controlled environment of corporate computing, these errors do not occur because the accompanying infrastructure is maintained to automatically respond to these issues thereby reducing total cost of ownership for the corporate customer.
Generally, home computers are subject to much less supervisory oversight and assistance. Without the help of a professional administrator, the quality of the application experience on Windows is at the discretion of the software vendor. Software vendor do make mistakes with the Windows Installer Resiliency features and thus you have this experience.
This specific problem is frequently written about in periodicals user assistance columns. I noted this in the blog entry “Stop Installation Idiocy” PCWorld’s Hassle Free PC article
The Windows Installer Frequently Asked Questions has FAQ items titled:
These entries will allow you to turn on Windows event logging and Windows Installer package logging which enable you to determine the which executable (client) and application (package) are providing misinformation to the Windows Installer service.
Behind the covers, it kind of works this way
Generally, start by contacting the Software Vendor(s) that is (are) causing the problem. The event and install logs enabled by the above should allow you to find the offending combination. As a PC is actually a commons, there may be more than one Software Vendor involved. The Software Vendor should be able to tell you how to repair their applications. This is a well traveled troubleshooting route traveled by corporate administrators.
Some home users will give up at this point because they don’t have the time or geek-like persistence to work through all the details. Other home users will say they don’t have media any more, the software company does not exist any more, or that was an unofficial copy of the application. Still others find their software provider unable to help them due to lack of knowledge, lack of experience, or a propensity to blame the other software provider.
Boiler plate suggestions from an ISV may include (in no particular order)
You should be able to try this on your own too.
MSIZap is the the Windows Installer tool that offers to disconnect the Windows Installer portion of the chain. MSIZap just operates on the Windows Installer store of information. MSIZap does not touch the the resources (files and registry keys) of the application. By using MSIZap to remove Windows Installer’s knowledge of the application, the calls to the Windows Installer APIs will fail due to unrecognized parameters. The risk to removing the Windows Installer internal data is in how well the client that is calling the Windows Installer APIs responds to return codes (INSTALLSTATE_UNKNOWN for example). From the Windows Installer point of view, MSIZap is a tool of last resort as it eliminates Windows Installer from the equation.
As one will note in the “Stop Installation Idiocy” PCWorld’s Hassle Free PC article, MSIZap is a choice user assistance columnists choose to call out.
Hope this helps…