I created the msi installer for my software using the wix tool. I am using integration with Microsoft_VC140_CRT.msm.
<DirectoryRef Id="SystemFolder" DiskId ="1">
<Merge Id="VC140_CRT" SourceFile="..." Language ="0"/>
</DirectoryRef>
During installation on Win 10 x64, an error occurs and the installer cancels the changes made in the system. In this case, the installer marks in the system log a warning that the application attempted to install an earlier version of the protected file C: \ WINDOWS \ System32 \ ucrtbase.dll. Event ID 1030.
How to disable msi installer logging in the system log?
Related
We have a msi installer which we have created using the wix installer. This installer also includes certain device drivers that need to be installed. We install the device drivers via a custom action. This custom action executes a .bat file that contains the utility dpinst64 to install the driver package. I have used the following option with the dpinst64
#if /I "%PROCESSOR_ARCHITECTURE%" == "AMD64" (
rem echo Installing driver from 64-bit installer on Windows 7
rem dpinst64.exe /SW /S /PATH W7
dpinst64.exe /q /se /PATH W7
) else if /I "%PROCESSOR_ARCHITECTURE%" == "X86" (
rem echo Installing driver from 32-bit installer on Windows 7
dpinst32.exe /q /se /PATH W7
)
)
What happens is when the user double clicks on the msi, the user gets a prompt to enter his / her credentials. After this installation proceeds OK. When the time comes to install the drivers, the user is again prompted with the credential window. I would like to know how can I avoid this coming again. I was thinking since I have already provided my credentials, this should remain for the rest of the session. However this seems to be not the case.
Batch Files Considered Harmful: Batch files must be avoided at all cost for MSI deployment. They are clunky, obsolete and almost without error handling and generally feature no rollback.
WiX Driver Element: Recommend you try to use the WiX Driver Element instead. It uses the DIFx framework under the hood - as far as I know. A small, practical example found on github.com.
Previous Answer: Maybe see this previous answer for more on the difx:Driver construct:
<Component>
<File ... />
<difx:Driver ... />
</Component>
Links:
https://developer.microsoft.com/en-us/windows/hardware
WiX silent install unable to launch built in .EXE: WiX v3
WiX silent install unable to launch built in .EXE: WiX v3
Can't seem to get Wix to install driver
I am using WIX bootstrapper for installing the newer version of the Installed MSI. The issue is during the installation if one of my files in the MSI is being used by any of the processes, I want them to be queued for installation and prompt a message box telling the user to reboot the system so that the queued packages will be updated after rebooting.
I have an Excel Add-in that uses a Wix (3.10) install script. The installation works fine. However, if the user tries to remove the add-in through System | Apps & Features, it fails with "There is a problem with this Windows Installer package. A program required for this install to complete could not be run." Looking at the uninstall log, I see this:
Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: _BDF865EC_34B3_4B29_986C_98D6EC1A9807, location: C:\Windows\Installer\MSI2FE4.tmp, command: /uninstall="C:\Users\Windows10\AppData\Local\myCompany\myProduct\myAddin.dll" /privileges=user
The action that it is balking at is this:
<CustomAction Id="_BDF865EC_34B3_4B29_986C_98D6EC1A9807" BinaryKey="adxregistrator_exe" Execute="deferred" ExeCommand='/uninstall="[TARGETDIR]$(var.myProject.TargetFileName)" /privileges=user' Impersonate="yes" />
However, if I re-run my installer and select 'Remove', it uninstalls fine. Also, If I run the uninstall from a command line (using the msiexec command found in the registry entry for this product), it also uninstalls fine.
Also:
This only happens in Windows 10. Older versions of Windows are fine.
I have replicated on several machines, including a fresh install.
I have an older installer (a VS2010 Setup Project), the problem happens with that installer as well.
I have tried with UAC at different elevations, no difference.
I have seen other posts here about changing the Impersonate setting to "no", no difference.
It seems to me that there is a problem with the new Windows Apps & Features app, but I have yet to find anything on the Microsoft forums.
Update:
A Wix user posted this: DTF Bug with new Windows 10 Apps and Features. Also, we have tried a variety of commands (thinking it was a UAC issue), none of them work, even 'built-in' Windows commands fail.
I have run into the same issue and finally came with this solution:
Win 10 Apps & Features uninstaller checks for the WindowsInstaller registry value and behaves correctly when this value is not present
1) Define the custom action
<CustomAction Id="DeleteWindowsInstallerValue" Return="ignore" Directory="TARGETDIR" Execute="deferred" Impersonate="no"
ExeCommand= "reg.exe DELETE HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode] /v WindowsInstaller /f" />
2) schedule the action in the InstallExecuteSequence
<Custom Action="DeleteWindowsInstallerValue" Before="InstallFinalize"/>
Honza
I created an MSI with WIX that needs elevated permissions to work correctly. In the MSI Project, I specified this via
<Package [...] InstallPrivileges="elevated" />
Now I included this MSI in a custom bootsrapper project, based on WixWPF Bootstrapper.
As I understand it, the bootstrapper itself should not alter the machine state and thus should not require elevated privileges.
I would now expect the Bootstrapper to automatically launch the integrated MSI with elevated priviliges, prompting the user with a UAC dialog, if necessary. But it does not. Instead, the installation just fails.
It works however, when I run the bootstrapper executable explicitly as administrator.
How do I make the bootstrapper ask for elevated permissions when installing the MSI?
Since the INSTALLSCOPE attribute for the MSI was not set, it defaulted to Per-User install and the bootstrapper application considered that it does not need any ADMIN/Elevated rights to run it.
Now in your case, you are the author of the MSI and it was easy enough for you to add the InstallScope to the package element.
InstallScope="perMachine"
If you are not the author of the MSI, still bootstrapper provides a property which you can use to force the per-machine for the MSI/EXE.
MSIPackage - ForcePerMachine
EXEPackage - PerMachine
So why does Bootstrapper think that Per-Machine install needs elevated privileges and Per-User doesnt? Simple enough, per-user installation the registry value is written under HKEY_CURRENT_USER and for Per-machine installation the registry value is written under HKEY_LOCAL_MACHINE. Only Admin users can read/write to HKLM.
As a test case for an issue I'm having with application deployment, I built an MSI following the WiX Simple Setup tutorial and using the latest version of WiX 3.5. My test environment is a virtual machine running 64-bit Window 7 Ultimate.
If I login as an standard user (no administrative privileges), open an elevated command prompt and install the MSI using msiexec /i testproj.msi, the directories and files are created, but the test program is not listed in the Programs and Features section of the Control Panel.
The test program installs completely if I run it from an elevated command prompt while logged in as a user with administrative privileges, or if I run it from a non-elevated command prompt. In all cases, the dialog that says "Please wait while Windows configures Test Package" is displayed.
I'm testing this in a virtual machine, reverting to a preinstall snapshot each time to make sure the failed installations aren't interfering.
I've enabled logging (e.g. msiexec /i testproj.msi /L*v test.log), and in all cases, the log indicates the program was installed with no errors (return code of 0).
Why does the installation fail to register the program in the Programs and Features list when run from an elevated command prompt while logged in as a standard user?
Install the application from normal user account and then check the Add/Remove program in the administrator account. The entry must be present there. This can occur if you haven't specified ALLUSERS value to 1.
<Property Id="ALLUSERS" Value="1" />