Hi it's been few days having different Google Video Support Pluggin Installer tasks running
It happens the same this folk described here:
v78 of Chrome, Win 10, Every few hours a new instance of the video plugin installer exe kicks off and runs in parallel with the other(s) in place. Each instance takes ~ half a core and there is also always one MsiExec that terminates (similar usage) when the process is manually killed in task manager. The processes originate from \users\\appdata\local\google\update\install{GUID} - deleting the directories / files does no good, the updater downloads it after a few hours and tries again.
Video plugin installer is v 19.9.2600.0, 10,692,592 bytes
I'd like a way to stop this automated install or have it succeed. It seems I can do neither right now.
Any solutions to this in place?
Thank you in advance!
Quick Questions: 1) Are you behind an internet proxy server? 2) What is your security tool / malware suite / anti-virus? Can you
temporarily disable it whilst the installation finishes? 3) Have a look
in the "Deployment Mnemonic" section here? (for various causes of
deployment failure). 4) You can try to log in as another user and install fresh - see if that works. If it does, then you need a Chrome profile cleanup? 5) There is always the reboot. Always try that first to get it out of the way as the "one-size-doesn't-fit-anyone-at-all-really fix".
Technical: If I were to guess the problem is a custom action in the MSI that gets stuck "somehow". How many msiexec.exe entries are in the tast list and what context are they in? (user, system). There can be many msiexec.exe processes. Below is information on how to debug custom action failures (and other failures) by log analysis.
Logging: If this really is an MSI installer (Windows Installer), then you can try to enable MSI logging policy to create a log file for all MSI installations that run by following the instructions in the section "Globally for all setups on a machine" here. You will then find a log file in the TEMP folder after the installer has run (whenever that might be). Look for *.log files with a random name. Just sort the folder by change date to see the most recent files.
Open Temp folder: Windows Key > Tap R > Type: %TEMP% > Press: Enter.
Debugging: You can search the log for "value 3" first to find errors (see Rob Mensching's explanation in that link). You can find more information on interpreting MSI log files in the section "Interpreting MSI Log Files" here: Enable installation logs for MSI installer without any command line arguments
Related
We made some changes to the installation and updating process of our Windows app recently, and some users are now complaining that Windows sometimes automatically deletes the main application .exe file.
It usually occurs after users update app using built-in web update feature. The feature is implemented using .msi built in Advanced Installer tool.
We are struggling to figure out what is causing this, and haven't found a way to consistently reproduce the issue (though we've seen it happen as well).
Here's what changed with our installation and web updating process:
The main installer for our application is now a standard .msi, which becomes a part of the Windows installation system and is natively manageable by Group Policy and other system features, such as rollback or versions. In previous versions that did not have this problem, our installer was a .exe built with the SetupBuilder tool.
We introduced the redesigned web updater feature inside the app (to update to new versions within the app). It uses the same .msi as the main deliverable as for installation. .msi is downloaded from our server in a form of .exe which is then extracts MSI and starts it. MSI then updates file in our installation. These .exe and .msi is built with Advanced Installer tool which provides such a web update feature to developers. In previous versions that did not have this problem, our web update feature was developed with SetupBuilder tool which provided a custom web update files - .exe web updater that downloads a number of web update files containing patch to our app.
The goal of a transition to the standard .msi installer was to make it easy for our clients to deploy the app in organizations - say, mass deploy using group policies and other similar tools.
Has anyone else experienced a problem like this? Any ideas on how to troubleshoot and try to reproduce?
Theory: Before doing anything else: The first thing I would ask the people who report the problem is if they have re-packaged your older, legacy (non-MSI) setup to be their own MSI file? This can cause a well-known upgrade problem along the lines of what you explain (file missing). Please check first. Tell them to uninstall the existing version and then install the new one - that is the simplest way. Not always enough (some obscure problems possible).
Mismatched component GUIDs could cause missing files after upgrade, as could file version downgrade scenarios and various other technicalities. You could try to install to a new default location on disk to avoid these problems. The reason this can work is very technical and hard to explain tersely. Essentially you de-couple yourself from "the sins of the past". It is generally enough to change the name of the file in question: for example MyApp.exe to MyAppNew.exe or maybe add the major version: MyApp5.exe, but maybe try the folder change first ProgramFiles\MyCompany\MyApp => ProgramFiles\MyCompany\MyApp5.
How do you configure your upgrade? View "Upgrades", what is selected: "Uninstall old version first and then install new version" or "Install new version first and then uninstall old version".
Blog Entry:: Why Windows Installer removes files during a major upgrade if they go backwards in version numbers (might be of help).
Deployment Debugging: For open ended debugging of MSI and deployment problems in general one obviously needs to gather intel and that means logging and system inspection.
Logging: First try to get a proper log file for the systems where this problem occurs. In Advanced Installer you can tick the "Enable verbose logging" in the Install Parameters view to enable verbose logging for all package installations. This adds the MsiLogging property to the compiled MSI and every installation of the MSI will cause a MSI log file with a random name to be created in the TMP folder. View the folder, sort by date and the file should be at the top. Suggest you do this and then tell the users to send you the log files when relevant. Maybe you have this setting enabled already?
Further Logging: There are many ways to enable logging, and you can find a description here: Enable installation logs for MSI installer without any command line arguments. The MsiLogging property is just one possibility.
To log a single MSI setup: http://www.installsite.org/pages/en/msifaq/a/1022.htm.
To enable global logging for all MSI operations on the machine: Please see this FAQ-entry from installsite.org, section "Globally for all setups on a machine" - for the exact procedure.
How to interpret an MSI Log File.
When i try to start one application (for instance application A.exe) error was throwing from already installed msi file (for Ex: B.msi) as "The feature you are trying to use is on a network resource that is unavailable or enter an alternate path to a folder containing the installation package 'B.msi'"
I have read some articles related to this error but all of them explaining if installer have any issues (if file have been damaged, deleted, moved, or quarantined by an anti-virus application) this error will occur but here when I try to launch one application then it is showing above mentioned error with another package name (B.msi) which I already installed.
Please let me know the cause of this issue it would be helpful to trace out this issue.
Note: For older version of our application don't have this issue (For creating installer earlier we have used Wise tool now using WIX tool. Is there any issue with WIX installer?).
Self-Repair Problems: This is generally a self-repair issue. I have written more times about this than I care to count, I'll see if I can send you here: MSI self-repair - the scourge of society.
Explanation: What is actually happening is that your installation goes through an integrity check when launced via an advertised shortcut, and a resource is found to be missing. The MSI will then try to repair itself (self-repair), but it is unable to find the required source files to retrieve the file it needs to reinstall - since the source files are no longer available at the location where you installed from. It is a good idea to install from a permanently available network location using administrative installations - especially for corporations.
Missing Source Files Resolution: In your case - to sort out the missing source files - you can either uninstall and reinstall (uninstall should not need source access in normal cases), and then preserve the installation files at a permanently available location (solving the problem for the future), or you can browse to the installation source when you are prompted to do so for your current installation (and there are some ways to automate setting new source paths). The installation source must be the one used to install the software originally (unless you know how to hack it, which is very involved).
Self-Repair Resolution: To sort out the actual self-repair conflict, you essentially need to find the culprit component causing the repair in the event viewer and then find some way to resolve the situation. All linked or explained in the above answer (repeated here). Proposed "real-world solutions" can be found in section 5 here: What do I do when launching an application triggers repeating, endless Windows Installer self-repair? As a workaround, you might want to try to launch the EXE files in question directly, to verify that the self-repair does not happen (generally this will prevent the self-repair, but it can still happen if there is a COM conflict or some other advanced conflict).
You can see a list of "Primary Cause of Self-Repair" some way down in this answer: How can I determine what causes repeated Windows Installer self-repair? (bad MSI packages with conflicting resources - COM conflicts?, security software quarantining files unexpectedly, cleanup scripts wrecking havoc, etc...). I would recommend you skim this list for ideas.
Uninstall Problems: This "installation source not found" problem can also occur so it prevents uninstall in special cases. Here is an answer which tries to summarize aspects of this problem: Powershell Silent Uninstall "Microsoft Report Viewer Runtime 2012" (somewhat too elaborate, but worth skimming I think).
Some Links (for reference and easy retrieval):
Installshield 2013 Installscript MSI: Wrong .msi location during Repair
Wix / MSI : Unable to uninstall
Uninstall without an MSI file
This seems to be a common behavior for a VS Setup Projects:
1) Created a WPF application.
2) Created Setup Project for the app. Straight forward and all defaults.
3) Built Setup Project and clicked Install on it.
Here is what happens next:
1) Setup starts.
2) All preliminary dialogues pass by.
3) Setup says Click "Next" to start installation.
4) "Next" button is clicked.
5) Setup says [my product] is being installed, "Please wait...", then freezes for 20-40 seconds without visually doing much, as seen by Task Manager/Resource Monitor. Just bloody sleeps!
Sleeping screenshot
6) It installs my application within a fraction of second, files are actually copying, etc. Progress bar jumps!
The important thing: this "sleeping" can be fixed. SOMEHOW. Example is Araxis Merge Setup, which is characteristically Visual Studio's, and it doesn't sleep, proceeds (with progress bar) straight in.
So, a million dollar question, HOW?
Thanks.
Do the install and create a verbose log to see where that wait is. msiexec /i [path to msi file] /l*vx [path to text log file]
Some of the possibilities are:
A System Restore point is being taken, that may take a while on some systems. You could try installing the MSI with a command line MSIFASTINSTALL=1 to see if disabling the restore makes a difference:
https://msdn.microsoft.com/en-us/library/dd408005(v=vs.85).aspx
If there are a lot of files already installed that you are updating (because it's an upgrade maybe) there's a lot that goes on in the InstallValidate action to decide what files need updating. The same is true if many of the files being installed have versions on disk that are in use but will be updated - owning processes need to be identified for files-in-use issues.
If you include some VC++ merge modules I vaguely recall some long-running things going on in certain versions, related to SxS. The only built-in custom action might be a check for the NET FW if you're using that, but that shouldn't take a long time.
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
I created a MSI package with visual studio. It works fine for 80% of the users (some have errors with privileges and the like), but for two users the installation fails with the error message:
The feature you are trying to use is on a network resource that is unavailable
Which I find very odd because all the MSI does is set some registry values and put an OCX control into the system. Nothing with any network devices or anything else.
It also refers to a install[1].msi (when the actual MSI is called install.msi) which it supposedly can't find, which is obvious, because such a file never existed and is neither required for the installation nor even referenced in it in any way.
The package tries to locate this non-existent other package under C:\Documents and Settings\XYZ\Local Settings\Temporary Internet Files\Content.IE5\M84S9GA4\, even though I started the MSI out of the local drive D:.
How can I resolve this / get closer the underlying cause?
A verbose log file should show you the exact error causing the issue. If it doesn't happen consistently, you'll probably be best served turning on the logging policy to get a log file all the time and when it repros, grab the log file really quick.
Alternatively, if you have a repro situation you can get a log file immediately by doing:
msiexec /i path\to\your.msi /l*v install.txt
As for the root cause, the fact that that the name is install[1].msi makes it sound like the MSI was downloaded using a web browser and launched out of the browser cache. The Windows Installer is very particular about the name of the MSI, you can read about that in an old blog entry of mine. The end result is that shipping a 'naked' MSI on the internet is never a good idea. Maybe you're seeing these errors when shipping a newer MSI? If so, that would make a lot of sense.
A verbose log file will show you for sure.