This application is a plugin for a larger application. To complete our installation, we need to run a batch script provided by the main application. The batch script errors saying that a certain registry key doesn't exist, but it exists in the WOW6432 part of the registry. It appears that the custom action is being ran as 64-bit, attempting to fetch the registry without the WOW6432. I have no access or control of the batch file, so I can't change that to check both parts of the registry.
How can I make sure the custom action is ran as 32-bit?
The cmd process is running in 64-bit mode when the batch file is ran.
Edit: To check if it is running 64 vs 32, I created a seperate batch script which checks looks for a registry key in HKLM/Software/SomeKey. The key is actually located in HKLM/Software/Wow6432/SomeKey. Manually running it with %windir%\SysWow64\cmd.exe (task manager flags this process as *32) works fine. Running it with the regular cmd.exe it cannot find the registry key. Putting this same batch file as a custom action in wix results in the non-*32 cmd to open and the regkey search failure.
I set this batch in Wix like this:
<CustomAction Id="batchCA" Property="BATCHFILE" ExeCommand="" Execute="deferred" />
Where BATCHFILE is a property set the the batchfile path. i.e "C:\temp\batch.cmd". It seems to run fine, but am I doing this wrong?
You should explicitly specify the command-line exe to be 32bit. So instead of directly calling your batch like "yourScriptName.cmd", you should use this:
%windir%\SysWoW64\cmd.exe /c yourScriptName.cmd
Related
i am trying to execute netcfg.exe /U ms_pacer etc to uninstall some bindings to the network adapter. now everytime i pass the command through vbscript the command prompt throws an error saying 'netcfg.exe' is not recognized as an internal or external command, operable program or batch file.
if i put it in a batch file and double click on it it runs fine. but again if i execute that batchfile through a .run in vbscript it gives the same error. i read somewhere that it could be environment variable issue, but tried setting environment, looks good but the command keeps throwing the error again and again. tried it in powershell but no go, please someone guide.
Ok found the answer, when running a 32 bit compiled application which needs to access another native windows application there is a catch. though windows has provided a set of 32-bit set of native applications in a 64 Bit OS, but has not changed names of files, and have been relocated in another folder i.e. %windir%\SysWoW64\ , now everytime a 32 bit application tries to access c:\windows\system32 on a 64 bit, it gets redirected to %windir%\SysWoW64\, now if one wants to refer to 64 bit native application then do %windir%\Sysnative
I have a Wix Bootstrapper which installs/updates a number of MSIs. The MSI runs and updates fine, and the Bootstrapper will run fine for an initial install. I attempted to test Updating with the Boostrapper, however, and every time it will not even launch, and spawn a large number of processes and Setup_XXXXXXXXXXXXX_Failed.txt files in the %Temp% folder. each of these failed.txt files contain the following at the end:
[3098:23F8][2014-06-10T11:03:00]e000: Error 0x800705b4: Failed to open parent pipe: \.\pipe\BurnPipe.{087217E1-A4F3-4951-8319-06031945DA08}
[3098:23F8][2014-06-10T11:03:00]e000: Error 0x800705b4: Failed to connect to unelevated process.
[3098:23F8][2014-06-10T11:03:00]e000: Error 0x800705b4: Failed to run per-machine mode
The numbers vary between files but the errors remain the same.
I am running this Bootstrapper Exe with various command line arguments to tell it what MSIs to install and to provide it with Install Location and various arguments for Custom Actions.
This was reported at http://wixtoolset.org/issues/3890/. I just recently fixed it, the next WiX build shouldn't spawn a large number of processes.
However, the underlying problem was that Burn was receiving a command line that CommandLineToArgvW couldn't parse. You need to make sure that all double quotes are properly escaped, and that when using double quotes for spaces that there is an even number of them.
A problem that has been plaguing me for nearly a week now.
I am trying to get an install of IIS to take place through the command line in VB. I understand that i need to be setting up an Unattended xml script to call, but here is a fundamental bit that is confusing me:
If i run the command : ' start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer; ' it executes perfectly within CMD.exe.
If i add the command to a batch file and run the batch file, it runs perfectly.
If i call the command using : Dim myProcess As Process = Process.Start("cmd.exe", "/k start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;"), then it fails with an error of:
////////////////////////////////////////////////////////////////////////////////////////////////////////////
Operation failed with 0x8007000B ////
////
An attempt was made to run the program in an incorrect format ////
////////////////////////////////////////////////////////////////////////////////////////////////////////
If i call the batch file mentioned earlier, then i get the exact same error.
How can it work perfectly with the two first examples but fail when it is called through VB?
Thanks for any help!
Your VB.NET program is very likely to be running in 32-bit mode and will start the 32-bit version of cmd.exe. The one from c:\windows\syswow64 instead of the one from c:\windows\system32 that you used before. Getting BadImageFormatException starts to become likely.
Project + Properties, Compile tab, set the Target CPU to AnyCPU and untick the "Prefer 32-bit" option. On older versions of VS click the Advanced Compile Options button to get to the setting.
I am trying to work for an application where i need to embed registry code in my program. Basically this is a Windows App.
My registry code is
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\DesktopBackground\Shell]
"icon"=""
"Position"="Bottom"
[HKEY_CLASSES_ROOT\DesktopBackground\Shell]
#="system.exe -L"
This code is stored in a registry file. All i need to do is invoke this script on an event handler say button_click.
Options i have is write this code as a string and execute this string.. or simply have a collection of *.reg files which i may execute on button_click.
I understand my app requires UAC, and i would be giving that permission for my app in App Manifest.
Can anyone pls suggest me how to execute registry file (.reg) stored placed in a folder
Use Process.Start with a ProcessStart.UseShellExecute = True
I'm using c#, .net 4, WIX 3.5, Windows Vista.
I have made my application compatible with RestartManager by p/invoking the RegisterApplicationRestart method and by handling the WM_QUERYENDSESSION and WM_ENDSESSION window messages (I return new IntPtr(1);).
If I try to update my application manually, then everything works as it should:
Launch application;
Launch msi file containing new app version;
During the installation/update, I'm prompted to close the running application;
Upon continuing the running app is closed, install completes, and the app is restarted;
If I try to update my application from the application itself, then I run into problems:
1) Launch application;
2) Download the new msi file;
3) Launch msi file with:
using (System.Diagnostics.Process p = new System.Diagnostics.Process())
{
p.StartInfo.UseShellExecute = false;
p.StartInfo.FileName = "msiexec";
p.StartInfo.Arguments = "/i \"" + downloadPath + "\" /passive";
p.StartInfo.UserName = "Administrator";
p.StartInfo.Password = securePassword;
p.Start();
}
4) Because I'm using passive mode, the application is closed automatically;
5) After the installation, my application is not restarted and under Event Viewer I have an
Event 10007 - Application or service 'MyApp' could not be restarted.
I have tried:
Not to use passive mode for msiexec;
Launch msiexec via cmd.exe (cmd.exe /C "msiexec /i ....") - in the hopes that launching msiexec from another process would solve the problem;
Wait for 60+ seconds before launching the msi update (shouldn't be relevant in my scenario, but MSDN documentation has something about it...)
But none of the above has worked (always the same result).
Having to launch the setup with elevated permissions might have something to do with the issue, because during the manual update I get a warning in the Event Viewer - Application MyApp (pid 3220) cannot be restarted - Application SID does not match Conductor SID.
Despite this, restarting the app still works. Googleing the warning yields no good/specific results, only that this warning is probably caused by running the msi in an elevated prompt.
How do I fix (or workaround) this issue, so that I can update my application from the application itself and restart my application afterwards?
Edit - extra testing:
There doesn't seem to be a need to respond to WM_QUERYENDSESSION and WM_ENDSESSION messages, because application restart during a manual upgrade works without them, so we can rule them out;
If I don't provide administrator credentials to the application initiated upgrade and instead I type them in during the upgrade, then app restarting works;
If I run an elevated command prompt and initiate an application upgrade from there (manually), then app restarting still works;
In order for application upgrade to work at all under Standard user accounts (so far I tested under an Administrator account with UAC), then I also have to set p.StartInfo.LoadUserProfile = true;. Otherwise nothing happens. (application restart still doesn't work though);
I tried all other process StartInfo parameters that I could set - WorkingDirectory, Redirect, Verb
(= "runas") - no change in results;
I installed Vista SP2 onto the virtual machine that I have been testing on (so far ran SP1), but no change;
I performed an "automatic" application upgrade with verbose logging. In the end there was an error message - RESTART MANAGER: Failed while restarting applications. Error: 352. That error code is very generic (http://msdn.microsoft.com/cs-cz/library/aa373665), inorder to get more detailed info I would have to write my own installer that would call RmGetList after the error, then I might get more details (this though is something I'm not willing to do);
Edit 2 - msi log file:
http://mommi.planet.ee/muu/log.txt
Assuming that the manual process indeed works without any problem it seems that your need for Administrator privileges in combination with the "updating itself" leads to these problems. I see the following options:
create a batch file to execute the update
When you want to update call this batch file (with elevated privileges), make the app close itself... the batch file should wait some seconds, then check whether the app is still running (and close it in case) and then run the commandline you need to run msiexec - don't restart the app from within msiexec but after a successfull run of msiexec from the batch file.
create a batch file which is always used to start the app
When the time comes to update you just end the app. Either the batch file check for an available update and applies it, starting the app after successfull update OR the app set some environment variable which is then accordingly processed by the rest of the batch file.