Using InstallShield 2018, I added Visual C++ 2015-2022 Runtime prerequisite to InstallShield setup project. When VC++ Runtime is installed first time on some computer, it may request reboot. The behavior of the setup is defined in InstallShield Prerequisite editor:
I selected the last option: Reboot the machine and resume on reboot. Resulting behavior: VC++ Runtime is installed, and computer goes to reboot, even without user prompt. After reboot, setup resumes.
I want to have the following behavior: If prerequisite needs a reboot, setup continues. In the end, when the product is installed, setup should ask user to reboot, user may accept or reject this.
What option in the list should I select, to get desired behavior? Their description is not clear enough.
Third option should get the desired behavior.
Note it, fail to resume if the machine is rebooted, and reboot after the installation.
For artificial reboot, you might play with 'PendingFileRenameOperations' value in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
Related
I am trying to install redhat (rhel8) in virtualBox 6.1 on a windows 10 64 bit Home edition machine.
I verified the checksum of the iso file after download and its correct (I compared the checksum against another friend iso file who is able to install properly), still I am getting exception like
dnf.exceptions.error some packages from local repository have incorrect checksum
I even tried to run troubleshooting, but it raise exceptin like
failed to start media check on /dev/sr0 virtualbox
I have downloaded the iso files from multiple places and every time it gives me the same exception.
Any help is highly aprreciated.
Finally I found the reason for the above error.
Virtual Box uses virtualization to run multiple Operating Systems and in one system (let's say a windows machine) only one of the application will be allowed to use system virtualization capability.
So we have to disable any manual virtualization if performed in the system.
So we can disable virtualization by following ways:
Search for “Turn Windows features on or off” in the Start menu, hit
the Enter key to open the Windows Features window. Here, scroll down
to Hyper-V and disable it by clearing checkbox next to it. Then click
OK
Disable Hyper-V by using command.
Press Windows logo key + X, then hit A to run Command Prompt as administrator. In Command Prompt window, type
bcdedit /set hypervisorlaunchtype off
and hit Enter key to execute this command.
Finally restart system.
I've got an Installscript MSI project that's behaving a bit oddly.
Following a successful installation, if I launch the installation file again, I get a pop-up with a question:
"Do you want to completely remove the selected application and all of its features?"
This, of course, is the expected behaviour.
If I select "No", the "InstallShield Wizard Completed" dialog is displayed, and it notifies me that "The wizard was interrupted before [the application] could be completely installed."
Again, this is all within expected behaviour.
The unexpected bit is that after closing this dialog, the application is partially removed from my machine. The installed files and registry keys are still present, but it no longer appears in Windows' "Apps & features", and if I run the installation file again it starts a new installation, as if the application had never been installed.
I tired enabling maintenance mode, but to no avail. Cancelling the maintenance dialog triggers the same partial removal.
Any clue what's going on here, or ideas to fix this?
I have also faced this issue when long back I was working on InstallShield scripting.
The unexpected bit is that after closing this dialog, the application
is partially removed from my machine. The installed files and registry
keys are still present, but it no longer appears in Windows' "Apps &
features",
Have you implemented the uninstall script functions in your installscript for uninstalling or updating the installation? You may look into these functions and verify the logic for those particular features or components.
and if I run the installation file again it starts a new installation,
as if the application had never been installed.
In the installer folder, where you have your installshield setup.exe, you have TEMP folder in that folder you have "Installation.ini" file, there it tracks the instances it has installed with that particular name.
So it might be because installshield is removing the entry from installation.ini file and when you are trying to install the same package again you are able to do this.
Everything used to work fine, but I haven't been using Virtual Box for several weeks. Now all of the sudden, I get the following exception when trying to start my Windows 10(32-Bit) VM. Note - Things were working fine several weeks ago. As far as I can tell, I haven't changed anything on my system that would cause this. The exception details are as follow:
VirtualBox - Error In supR3HardenedWinReSpawn (rc=-5640)
Please try reinstalling VirtualBox. where supR3HardenedWinReSpawn
what: 1 VERR_SUP_VP_THREAD_NOT_ALONE (-5640) - Process Verification
Failure: The process has more than one thread
I have been researching this for some time, to avail. Any help would be greatly appreciated.
There is a workaround:
Open VMbox manager
Run your VM with option "Detachable start"
Wait a while and then use "Show" to show the screen
Detachable start option
Show the screen
My setup:
Oracle VM Box 6.0 running on Win10,
VM is Ubuntu 18.04
If you are using vagrant to boot up your Virtual machine, then in most cases the error is due to improper shutdown of the VM. A fix that worked for me is to execute vagrant halt or similar commands multiple times until you have a clean boot.
In case anyone is in the same predicament, I will share what finally fixed my issue. I found a post during my hours and hours of searching that said you have to enable virtualization in BIOS settings. I checked my machine and virtualization was enabled, so I went on searching. At a loss for what to try next, I finally tried turning virtualization off, just to see. No change, but when I went to turn it back on, just as a flook I turned Turbo off, and what do you know - All of the suddent I can start my VM. So the solution, in case it saves someone time:
Uninstall Virtual Box (Latest Version)
Reboot your machine and enter BIOS
Make sure anything with the term 'Virtualization' is turned on
Make sure anything with the term 'Turbo' is turned off
Reboot your machine
Install Virtual Box
Hopefully this saves some poor soul what I had to go through to get this thing working.
METHOD A
If you are using WindHawk, exit it and re-try.
Method B
download previous version from https://www.virtualbox.org/wiki/Download_Old_Builds
install & extensions
Try to re-run your guest OS.
Try to do these steps:
1. Uninstall the VirtualBox program.
2. In your C:\users\\ might have two folders called ".VirtualBox" and "VirtualBox VMs": Delete them
3. Restart your PC
4. Install VirtualBox again
5. Add again your VM
6. It must working fine!
These steps worked for me!
Workaround 1:
Just increase the RAM size from virtual box settings
Right Click on OS image .
Settings->System->MotherBoard
Increase the base memory
Workaround 2:
Change the Paravirtualization Interface from default to none
Right Click on OS image .
Settings->System->Acceleration
Change acceleration from default to none.
The above one's was basically a workaround , which can work in some but not in all.
The best thing would be to reinstall virtual box with latest version which virtual box has tried to rectify the bug and use the same vdi files which was made by Virtual Box .
One of the most common causes that will cause this type of behaviour is a missing driver (VBoxDrv.inf). It’s possible that due to some permission issues, the installation of this crucial driver doesn’t complete during the initial installation. In this case, you can fix the problem by installing the VBoxDrv.inf manually.
1.Fix the directory problem Press Windows key + R to open up a Run dialog box. Inside the text box, type ‘regedit’ and press Enter to open up Registry Editor. When you’re prompted by the User Account Control (UAC), click Yes to grant admin access.
Once you’re inside the Registry Editor, use the left-hand section to navigate to the
following location: HKEY_LOCAL_MACHINE\system\currentcontrolset\services\vboxdrv
After you arrive at the correct location, move over to the right-hand section and
double-click on ImagePath the path associated should be \C:\Program
Files\Oracle\VirtualBox\drivers\vboxdrv\VBoxDrv.sys
if not replace with the above path and click ok.
Install the VBoxDRV.inf OPen location C:\Program Files\Oracle\VirtualBox\drivers\vboxdrv right-click on VBoxDrv.inf and choose Install from the context menu.
Then in cmd run command "sc start vboxdrv"
Restart system. This should work.
Is there any way in InstallShield to show the prerequisites which is being redistributed along with the setup.exe are already installed on the target system, like the image below, which shows what is pending on the target system. What if I want to show that this is already installed?
There's nothing in the UI that shows this. You can run setup.exe /debuglog and read through it to figure out what was skipped:
Q105473: INFO: Setup.exe Command Line Parameters
FWIW, I get in the habit of also implementing the check in the MSI ( AppSearch / LaunchConditions tables ). This way if the setup.exe is bypassed and the MSI directly invoked you'll still make sure to not get into a bad state of missing prereqs. If this is too much work for you, you can use the SETUPEXEDIR property to enforce that the MSI was launched by setup.exe.
I have a setup which has been created using InstallScript MSI project type. This problem is encountered by our client and he wants a quick solution.
Let's assume I have initiated the installation from a path like
C:\Setup_V_1.0.0931.1
Inside this folder I have Setup.exe through which I will install the product. After installation or after some days pass I will change the path to:
C:\New\Setup_V_1.0.0931.1
and this time I want to modify the setup. Actually we are supporting 3 features: Server, Client and Service.
This time I want only Client and not Server. So I will click on the Setup.exe or click on Uninstallation Icon in the Startup Menu which will lead to Maintenance Mode there you have an option to Modify, Repair or Remove. I choose Modify and select the feature, but as the installation progresses, this error message will pop up:
Setup could not find a file on the specified path or Disk. Please check
that the proper disk is inserted or specify a new path. Unable to
locate file c:\New\Setup_V_1.0.0931.1\setup.msi
Then, another popup will be shown saying:
Error: 1706. No Valid Source could be found for product. The Windows
Installer cannot continue.
The next error message is:
Error: 1603. Fatal error during installation. Consult Windows Installer
Help (Msi.chm) or MSDN for more information.
But if I change the path to its original location, it works fine.
How can I solve this?
I event checked in this registry path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\{Product-Key}
This key contains a lot of information inside InstallProperties. There is a key called InstallSource and its value is C:\Setup_V_1.0.3909.1\. Even after changing this value installshiled is still showing errors.
I found the same registry information for Uninstallation Information:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{Product-Key}
In your properties change ReinstallMode (or maybe Reinstall I forget which) from omus to vomus
the v means cache your install, so it will put your .msi file in c:\windows\installer so it can be used later.
When installing a MSI, Windows Installer saves the original MSI path in registry (the InstallSource entry you mentioned). When running the MSI in maintenance mode, Windows Installer will use this path to find the installation data (CAB files).
When you move the MSI, the path stored in registry is no longer valid, so Windows Installer cannot find the installation data.
A possible solution is to use "Add or Remove Programs" or "Programs and Features" in Control Panel to modify the installation. This way the cached MSI is used.