Hi I built a VS 2005 Setup and Deployment project and i'm able to install the setup without any problems. But, if I reboot my computer, the setup utility is being run again, asking me to install the software again (It already exists). I have not run into this problem before, any help would be greatly apperciated.
Thanks!
This is what I see in the windows event viewer, under application:
Event Type: Warning
Event Source: MsiInstaller
Event Category: None
Event ID: 1001
Date: 3/6/2009
Time: 8:14:49 AM
Description:
Detection of product '{2B4F800C-FA4E-42D9-93D3-C3DC4A4FCAB7}', feature 'AlwaysInstall' failed during request for component '{D2D7B4BF-6CCA-11D5-8B3F-00105A9846E9}'
I don't recall seeing the 'AlwaysInstall' property anywhere in the project, where do I set or un-set this??
Is it possible that prior to the reboot one of the installed files has been modified for some reason?
I'm not familiar with the error message, but perhaps Windows installer is attempting to repair the installation on reboot?
Have you tried installing the product once, then prior to rebooting running the installer again and selecting the repair option and seeing if this succeeds? If the repair fails at this point, run it again from the command line with verbose logging turned on:
msiexec /lv logfile.txt /i "MyInstaller.msi"
and when the error message pops up check out the last thing to happen in the log file.
I don't know about this specific error, but I have seen similar behavior when I sometimes deleted some seemingly nonessential parts of the application, such as possibly desktop shortcuts, Start Menu shortcuts, config files installed by the original installer, etc. Next time I'd try to run the app, msiexec would kick in and try to reinstall the application.
Related
There is a hotfix version of Tortoise Git and my PC refuses to install it. It keeps saying Windows Explorer is running, even when it is not showing the Task Manager.
Is there any other way I can get this upgrade to install?
Update
I decided to start Windows 10 in Safe Mode so we can be sure that nothing is running. Yet it still would not perform the upgrade (with Administrator privileges):
I used Task Manager and I could not see gitdll.dll in the list of running processes.
1.download hotfixes
2.restart windows (don't open any apps after restart)
3.run Task Manager (from windows bar)
4.run hotfix from menu of Task Manager -- File -- Run new task
I have the same issue; I solved it by running:
listdlls64 -d "c:\Program Files\TortoiseGit\bin\gitdll.dll"
and used task manager to manually kill all processes that were using the dll, including explorer.exe. This seems entirely unnecessary but it's what worked for me.
Why so many processes (including LogonUI.exe, OpenWith.exe, splwow64.exe, etc.) attached to gitdll.dll, is unknown, and seems like an issue that can be solved. We know that explorer uses that dll, but you would think the installer/updater would expect that and be able to work around it.
In 2.10.x hotfixes there was a bug in the hotfix updater which was unable to offer a restart for replacing gitdll.dll during a restart cycle. A failure to replace this file caused lots of crashes (cf. https://tortoisegit.org/issue/3599).
Please download the full installer for TortoiseGit and install it (https://tortoisegit.org/download/; there might be a warning regarding a possible downgrade, this can be ignored).
Generally
The .MSI installer and newer hotfixes offer two options when installing:
Try to restart open processes - this might fail as described in https://stackoverflow.com/a/61026137/3906760 based on some third-party software.
Requiring no closing/restart of open programs but the replace the file on reboot. This should work in any case because the file is replaced before starting any programs using it.
I tried both types of installer:
Hotfix
Full
And both were refusing to work. I then occurred to me that all the icons were flashing on my desktop and it was stuck. This was consistent behaviour.
So I decided to switch of my Star Dock Fences:
Right-click Desktop and select Configure Fences:
Scroll-down to the bottom of the pop-up window and un-tick Enable Fences:
Close the window.
Now I was able to install the hot-fix. Interestingly the installer was only complaining about the Windows Explorer still running and did not list Fences.
I hope this helps any others who have struggles upgrading TortoiseGit.
I have successfully installed disabling AVIR and allowing the installer to close as much as it wants
Error 1001. An exception occurred while uninstalling. This exception
will be ignored and the uninstall will continue. However, the
application might not be fully uninstalled after the uninstall is
complete
I can't uninstall or install the application. This particular box is not able to access the internet and I don't have physical access so most of the googleable results are not useful since they suggest running an exe from Microsoft.
What are the manual steps to resolving this issues. There is no way I can physically reach this machine nor does there seem to be a way for me to get files onto it. This is code that I'm developing and testing. I've tried repair and remove which fails out. I've scoured the registry but I must be missing something here.
If this is better on SuperUsers I'll gladly move it.
I had the same uninstall issue removing an application that I wrote that includes two Windows Services, ergo custom actions were unavoidable. I solved it be running PC Tools Registry Mechanic. Unfortunately, Symantec has retired that product. However, Microsoft Fixit has been known to help with registry related problems. http://support.microsoft.com/mats/Program_Install_and_Uninstall
1001 always means an InstallUtil (Installer Class) custom action has failed. It's impossible to give you a more detailed answer because, well, it's a "custom" action. There is no telling what code is throwing an exception.
If you want to save this machine and not have to rebuild it, you have to log the uninstall to get the name of the custom action that's failing, use ORCA to tweak the MSI to cut out the custom action, recache the MSI and perform an uninstall.
You've now learned the hardway why to:
1) Always use VM's to test your MSI during the development / test life cycle
2) Avoid using custom actions whenever possible
3) Never use InstallUtil custom actions. They are not a good pattern or practice.
1.Goto control panel then right click to get repair option.
2.Repair it and again uninstall after repair.
Here you go the software is uninstalled..
Make a verbose log file:
msiexec.exe /I "File.msi" /QN /L*V "C:\Temp\msilog.log"
/I = run installation sequence
/L*V "C:\Temp\msilog.log"= verbose logging
/QN = run completely silently
Open it in notepad, and search for value 3. Also check the system's event log for any clues.
Most MSI errors like this will probably involve custom actions, or service configuration like Chris says.
If this is really important to chase down you should get hold of Orca - the SDK tool used to inspect MSI files. You can see some screenshots of the tool in operation in this answer. And then inspect the Custom Action table and the end of the InstallExecuteSequence table (order by sequence number) and report what entries you find there.
Unfortunately it seems the only way to get hold of Orca is by installing the Windows SDK. Alternatively you can download a trial version of one of the third party installer tools.
My guess is that there is an immediate mode custom action after InstallFinalize that is returning an error code of some sort. In short you can report all items AFTER InstallFinalize in the InstallExecuteSequence and we can probably narrow it down.
That resolve the 1001 problem uninstalling windows service in Windows Server 2012 R2 I did:
Go to program and select Modify Service
Select repair Service
Close the applet, select again Modify Service
Now Select uninstall.
I hope this help
it starts up windows installer with random applications on my machine . . after i click cancel a few times, it loads vb6 fine.
any ideas why this is happening?
To stop this behavior:
Start VB6
Open the Add-Ins dialog
Uncheck the "Visual Component Manager" Add-In
Source:
After VS2010, SP1, VB6 launches VS2010 installer
This is what a Windows Installer repair looks like. It means that something is broken in one of the installed products on your system. Ideally it's a one-off repair so you might be better off letting it runs its course and do the repair, except of course if it asks for a install CD that you don't have.
The Windows event log (Application) will have MsiInstaller entries saying what product and component has the problem.
It's possible a previous installation has not completed correctly.
Use the utility at the following link to remove any rogue installations files:
http://support.microsoft.com/kb/290301 (broken link Aug.2017, leaving URL for "historical purposes").
As PhilDW has pointed out this is a Windows Installer Self-Repair issue, and can often be resolved by allowing the self-repair to complete once. At other times the problem persists and it should be fixed by other means. Even when the self-repair completes and the problem goes away, it can still resurface once you launch the conflicting application. Windows Installer is not easy to deal with.
In your particular case you might be able to get away with a "workaround" rather than a fix. By locating the main VB6 EXE file on disk (in its main installation directory) and manually creating a shortcut to it on your desktop, you might be able to successfully launch VB6 via this new shortcut without the self-repair kicking in. It might be worth a try.
This shortcut trick will not remove the underlying problem, but might help to "bypass it". Just for the record: the reason this might work is that the new, manually created shortcut is not "advertised" and will not trigger a key-path check of the installed product when launched. This is Windows Installer's way to verify that a product is correctly installed. Note that even if the workaround works, self-repair might still result during application use because of faulty COM data being detected (which is very likely the cause of the whole problem you are seeing, but give the manually created shortcut a try).
There is a rather comprehensive "article" on self-repair here: How can I determine what causes repeated Windows Installer self-repair? which might help to track down the cause of the self-repair kicking off in the first place, but fixing it can be a rather complicated process (so try the workaround first). It is a long article because there are so many different ways self-repair can occur. The common denominator is that different installers on your system are fighting over a shared setting that they keep updating with their own values on each application launch in an endless loop. The last application to launch will overwrite the registry or file system with its own setting.
This worked for me, for VS2010 RC:
"Please wait while windows configures Microsoft Visual studio 2010 Ultimate."
THe work around that fixes the issue for me was to run the following via the admin cmd prompt.
Md "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\common7\IDE\FromGAC"
from http://social.msdn.microsoft.com/Forums/en-SG/vsprereleaseannouncements/thread/572a0f8a-16b0-4e1d-b581-16be36a9b564
This was also happned to me.
Whenever i tried to open vb6, it started windows installer to configure "Autocad".
Autocad had not broken. and it was working fine.
I tried removing and reinstalling Windows Installer, But it did not solved the issue.
Then i installed Microsoft's "Windows Installer Clean Up Utility 2" from given link.
Using this utility i removed the autocad from "Windows Installers" Database.
After that VB6 never started installer again.
Keep in mind 'removing any entry from installer's database may be risky, but i had no choice. So do it on your own risk.
Download "Windows Installer Clean Up Utility 2" (this is a deprecated, unsupported and unsafe tool to use - Aug.2017. I will leave the link in for "historical purposes", don't use it).
This is the error that is thrown by our automated build suite on Windows 2008, while running ICEs (after migrating from WiX 2.0 to WiX 3.0):
LGHT0217: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.". in light.exe(0, 0)
The FAQ is now deleted, however, the text from it said:
In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.
Additionally, these are the errors that show up in the event log:
MSIInstaller: Failed to connect to server. Error: 0x80070005
Product: [ProductName] -- Error 1719. The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.
Intuitively:
VBScript and JScript were registered under admin.
Integration service has permissions for the desktop interaction and all the files
Builds succeed, when executed manually on the same machine by another user or even user logged in as integration account (via RDP)
I'm out of ideas so far.
How do I solve this problem while keeping ICE validation?
End of the story:
After fiddling with the permissions of the integration account, DCOM, service activation, etc. without any luck, I finally simply disabled ICE validation in the continuous integration build, while still keeping it in the local build.
To disable ICE validation you can set SuppressValidation to true in the .wixproj file:
<PropertyGroup>
<SuppressValidation>true</SuppressValidation>
</PropertyGroup>
Or pass the -sval command line option to light.exe.
Adding the TFS build controller account to local admin group and restarting the windows service did the job for me.
I found the root cause. I tried everything I found, including custom validator extension similar to one posted in Re: [WiX-users] light.exe failed randomly when running ICEs..
It's not a concurrency issue as suggested in various threads. It's caused by a too large Process Environment Block (PEB).
It turns out Windows Installer can’t handle a process environment block larger than 32 kB. In my environment, due to number of variables set by the build system and their size (for example, PATH variable containing multiple duplicated values), PEB was about 34 kB.
Interestingly, per Environment Variables, Windows XP and 2003 had a hard limit of PEB set to 32 kilobytes. That would probably cause an easy-to-catch build break in an earlier phase of the build. Newer Windows' doesn’t have such limit, but I guess that Windows Installer developers limited their internal environment buffers to 32 kB and fail gracefully when the value is exceeded.
The problem can be easily reproduced:
Create a .bat file which sets environment variables which size exceeds 32 kB. For example, it can be 32 lines of set Variable<number>=<text longer than 1024 characters>
Launch cmd.exe
Execute the batch file you created
From the same cmd.exe window:
Try building the MSI package using WiX with ICE validation on OR
Run smoke.exe to validate your package OR
Simply run msiexec /i Package.msi
All the above commands will end up reporting Error 1719 - Windows Installer could not be accessed.
So, the solution is - review your build scripts and reduce number and size of environment variables so they all fit into 32 kB. You can easily verify the results by running:
set > environment.txt
The goal is to get file environment.txt smaller than ~30 kB.
The correct description (without a solution, except if adding the CruiseControl account into local administrators group can pass as a solution) of the problem:
Quote from Wix 3.5 & Cruise Control gives errorLGHT0217:
ICE validation needs an interactive account or administrator privileges to be
happy. See for example WiX Projects vs. TFS 2010 Team Build (2009-11-14) or Re: [WiX-users] Help with building patch (2009-11-20).
imagi is totally right! I could not believe this is the true answer. Supressing validation and making TFS user Administrator are not good solutions. Plus I could not find NT\Authority to add it to Administrators group and was totally stuck in this.
I got the same error on Windows Server 2012 Datacenter as Build Agent.
To solve the problem :
List item
Go to Environment Variables on the build agent machine
Create two System Variables
"PF86" which is equal to "C:\Program Files (x86)"
"PF" which is equal to "C:\Program Files"
They are so short because I want to save characters.I made them without the final backslash because TEMP, TMP and others were made so and I decided to stick to MS standard for these variables.
Edit PATH variable by substituting every "C:\Program Files (x86)" with %PF86% and every "C:\Program Files" with %PF%
Close and build and enjoy!
It worked for me. :)
UPDATE
I found a better solution : Rapid Environment Editor will do all this and even more for you. Automatically.
I faced the same problem and did not like to suppress ICE validation. My setup: I used my own computer as a build agent on Visual Studio Online (VSO). My solution was to change the account used to run the service on my machine. Instead of using Network Service or Local Service I simply made the service log on with my own account which had all the necessary rights.
From http://wix.sourceforge.net/faq.html#Error217:
In WiX v3, Light automatically runs validation--
Windows Installer Internal Consistency Evaluators (ICEs)
--after every successful build. Validation is a
great way to catch common authoring errors that can lead to service problems,
which is why it’s now run by default. Unfortunately, there’s a common issue
that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to
fail. For details on the cause and how to fix it, see
Heath Stewart's Blog
and
Aaron Stebner's WebLog.
I was getting same ICE error, but the problem turned to be corrupted Windows Installer Service.
This solution worked for me:
http://support.microsoft.com/kb/315353
Log on to your computer as an administrator.
Click Start, and then click Run.
In the Open box, type cmd, and then click OK.
At the command prompt, type msiexec.exe /unregister, and then press ENTER.
Type msiexec /regserver, and then press ENTER.
Restart Windows
Also, verify that the SYSTEM account has full control access permissions to the
HKEY_CLASSES_ROOT hive in the Windows registry. In some cases, you may also have to add Administrator accounts.
I have some suggestions.
Try updating the Microsoft Installer version on the build server
Make sure you use the newest release of WiX 3.0, since it's 3.0 release stable now.
If all else fails, try running the build service under a specific build user who you can fiddle with permissions for...
I got this error from my Azure build agent running on-premises.
My solution was to upgrade its user account from "Network Service" to "Local system account".
Go to your build machine and restart the Windows Installer service
None of the above suggestions worked for me, for me the anti-virus (mcafee) came into the picture and looks like it updated the vbscript.dll registry entry to a wrong DLL location. These are the things to keep in mind:
Some of the WiX ICE validations are implemented using VBSCRIPT.
So while compiling the MSI, the build server would need access to the c:\windows\system32\vbscript.dll.
Chances are that somehow the user that runs your build lost access to this DLL.
As mentioned in the above answers do look for the admin access/registry access and make sure your user has it.
Here are the steps that I took to fix the issue:
Open cmd (run as admin) on the build agent machine.
Run RegEdit
Select the root, then click ctrl + f and Search for the following registry entry : {B54F3741-5B07-11cf-A4B0-00AA004A55E8}
Look for the InprocServer32\Default Key
On my build agent, the path was replaced with a mcafee DLL location. I updated the path back to c:\windows\system32\vbscript.dll
Editing the registry entry was not easy, as it was a protected registry entry. I used the below link to get access permissions changed before I could edit the property: Edit protected registry entry
Once I updated the path, everything started working as usual.
My solution is similar to Vladimir's one. My CI user was admin of the computer.
But the following steps were mandatory to allow my jenkins build to succeed:
log in as CI user using rdp
open a dos command prompt
execute: %windir%\system32\msiexec.exe /unregister
execute: %windir%\system32\msiexec.exe /regserver
then i got a successfull job
I have a setup project created by Visual Studio 2005, and consists of both a C# .NET 2.0 project and C++ MFC project, and the C++ run time. It works properly when run from the main console, but when run over a Terminal Server session on a Windows XP target, the install fails in the following way -
When the Setup.exe is invoked, it immediately crashes before the first welcome screen is displayed. When invoked over a physical console, the setup runs normally.
I figured I could go back to a lab machine to debug, but it runs fine on a lab machine over Terminal Server.
I see other descriptions of setup problems over Terminal Server sessions, but I don't see a definite solution. Both machines have a nearly identical configuration except that the one that is failing also has the GoToMyPC Host installed.
Has anyone else seen these problems, and how can I troubleshoot this?
Thanks,
I had LOTS of issues with developing installers (and software in general) for terminal server. I hate that damn thing.
Anyway, VS Setup Projects are just .msi files, and run using the Windows installer framework.
This will drop a log file when it errors out, they're called MSIc183.LOG (swap the c183 for some random numbers and letters), and they go in your logged-in-user account's temp directory.
The easiest way to find that is to type %TEMP% into the windows explorer address bar - once you're there have a look for these log files, they might give you a clue.
Note - Under terminal server, sometimes the logs don't go directly into %TEMP%, but under numbered subdirectories. If you can't find any MSIXYZ.LOG files in there, look for directories called 1, 2, and so on, and look in those.
If you find a log file, but can't get any clues from it, post it here. I've looked at more than I care to thing about, so I may be able to help
Before installing, drop to a command prompt and type
CHANGE USER /INSTALL
Then install your software. Once the install has completed, drop back to the command prompt and type:
CHANGE USER /EXECUTE
Alternatively, don't start the installation by a double click but instead go to Add/Remove Programs and select "install software" from there.
Good luck!