While installing my msi i get the follwing error
Error 1935. An error occurred during the installation of assembly component {98CB24AD-52FB-DB5F-A01F-C8B3B9A1E18E}. HRESULT: 0x800736B3. assembly interface: IAssemblyCacheItem, function: Commit, assembly name: Microsoft.VC80.CRT,type="win32",version="8.0.50727.42",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86"
I do carry Microsoft_VC80_CRT_x86.msm in my MSI. But the problem is that i do not see this issue in all machines. This is faced only on a 2012 Windows Virtual machine.
Can anyone please tell me why this error would normally come?
I think you have a corrupted windows O/S. Otherwise it is correct to test on VM's configured with a variety of virgin operating systems that you want to support. Additionally I highly advise to never use this merge module. Instead using a bootstrapper/chainer (WiX Burn, InstallShield Setup Prereqs or Suite Installation ) to install the stand alone versions of the redist from Microsoft. This helps draw a line in the sand between a Microsoft problem and a problem with your installer. It also makes upgrade servicing easier.
I got the same error message on windows 7 (32bit).
This was caused by a failure in windows update for my case.
After that, I cannot install any other program on the computer. I searched from internet and found suggestions made by Microsoft engineers: repair the system from Original Installation disc with "update to latest" choice unchecked.
However, I found another simple solution which also works for my case.
1． Click START>> and type “regedit” to run register editor;
2． Find the following directory in register: HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control;
3． search by F3 for the key RegistrySizeLimit and double click the DWORD;
4． Change the key value into ffffffff(Hex) or decimal 4294967295, then click OK;
5． restart the computer;
6． run cmd.exe with Administrator's privilege, and type SFC /SCANNOW followed by Enter in command line; this scanning may take several minutes until the status is 100% and finishes;
Then the problem can be fixed!!
I got this error in my Win7x64 VM after I installed .NET Framework 4.5 required by my MSI. I had a fresh OS install with no Windows updates, plus VS2005 SP1. I ran this Microsoft FixIt: http://support.microsoft.com/kb/976982/en-us, but it did not help until I restarted the VM. Once I restarted the VM, the error disappeared. I think all I needed was a restart, but I provide the above details in case it was the FixIt that actually fixed it.
On a windows 2016 server, I solved the problem by resetting DCOM security to default
launch dcomcnfg
then set Default Authentication Level to Connect
and Default Impersonation Level to Identify
Related
If not mistaken,the error occured after I misclick a notification of a antivirus software that request for a permission.My computer is using Windows 10.May I know how to solve this problem?
Older answers on this software installation:
Node.js - Cannot Install it is showing an error because of .msi
Node.js install fails on Windows 10 1803
Blocking: This sort of problem can definitely be caused by an anti-virus software blocking access to the MSI in question. Disable the anti-virus temporarily and try again. If unable to do so, perhaps try to install on a virtual machine? (for testing or real use).
Windows Installer: Just to get it out of the way: I see some recommendations to re-register the Windows Installer components, but I prefer to eliminate other causes first (a broken Windows Installer usually indicates more serious system-wide problems - such as malware infection, or full disk or something else very fundamental).
Virustotal.com: Before temporarily disabling your anti-virus (the procedure for this is obviously different for each vendor), you should verify the actual binary or MSI using the virus checker interactively and also upload the file to https://www.virustotal.com/ to make sure the MSI isn't actually infected - if it is your anti-virus is doing its job.
Re-Download: It is also a good idea to re-download the MSI from the vendor site in case it has gotten corrupted during download. This happens very frequently. I have seen days wasted with corrupted installation media the unexpected cause. Virus test this new download too using https://www.virustotal.com/ (you want to check both old and new binary for malware - the file available for download can be infected).
Other Causes: There are a number of other causes that are common for failing installers. I have several older answers on this, but maybe this is the easier one to browse: Common causes of failed installations (setup.exe or mysetup.msi fail to install). Here is a quick extract (please do visit the link):
The most common issues seem to be: security software interference, malware infected machine, corrupted download, missing runtimes, out of disk space, blocking mechanisms on the machine from corporate policies, etc...
Other Links:
WiX, deployment and setup links
I cannot reinstall node.js on windows 10
I think your problem is not from the node.js but from the Windows installer itself.
I solved mine by following the instruction here (from the Microsoft forum).
Method 1:
Perform System File Check (SFC), and then check if this fixes the issue.
Follow the steps:
a. Press “Windows Key + Q” to open Charms Bar.
b. Type “cmd” without quotes in the search box.
c. On the left pane, right-click on the “cmd” option and select “Run as Administrator”.
d. Type ‘sfc /scannow’ without quotes and hit enter.
Method 2:
I would also suggest you to run the System update readiness command. It detects incorrect manifests, cabinets or registry data, it may replace the incorrect data with corrected version available. Follow the steps.
4. Press Windows key + X.
5. Click command prompt (run as administrator).
6. In the Administrator: Command Prompt window, type the following commands. Press Enter key after each command:
DISM.exe /Online /Cleanup-image /Scanhealth
DISM.exe /Online /Cleanup-image /Restorehealth
In my case, the first method solved the problem.
I've downloaded oracle 12c on my personal laptop. Check system compatibility (alls good). However, towards the end Im getting an error stating "Oracle Services for microsoft transaction server" denied".
Please assist,
Googling the error message leads to this as the first result:
http://www.dba-oracle.com/t_ins_20802_oracle_services_for_microsoft_transaction_server_failed.htm
Which basically says to ignore the message and run the Database Configuration Assistant manually to finish configuring the database.
When an installation fails, you should check the installation log for more details.
In my case, the log file said "hostname too long", so I shortened the host name and was able to do a successful install.
I faced the same issue recently and it was regarding [INS-20802] Oracle Database Configuration Assistant failed error. I think the solution for it will of help in your issue too.
I tried several of the following methods for resolving the issue :-
Disabling Windows UAC
Disabling firewall
Disabling antivirus - mine was a fresh VM, so disabled Windows Defender
Adding localhost IP i.e., 127.0.0.1 to the hosts file etc.
but none of them helped.
At last I found this, which suggested installing Microsoft Visual C++ 2010 Redistributable Package (x86) and this solved the problem in a matter of seconds! I just had to click 'Retry' on the installation dialog.
Do you have local "Admininstrator" rights on the account that your are installing Oracle into?
The Oracle Universal Installer is trying to create the MTS service and access is being denied. This is why I usually don't take the default install, and use the "custom" install and select the components I want. OUI will then work out the dependencies and install the correct components.
With this type of failure, you should have had an option to "ignore/skip" the error and the installer should continue and install the database objects - you shouldn't need to re-install the database objects as the the MTS service component should install after the data objects are created and they are not reliant on each other. Unfortunately the installer status will still show "failed" because of that one component failing.
I'm trying to use this Visual Studio extension for 2013, which recreates the built-in installer functionality from Visual Studio 2008/2010: http://blogs.msdn.com/b/visualstudio/archive/2014/04/17/visual-studio-installer-projects-extension.aspx?CommentPosted=true&PageIndex=2#comments
It works, allowing me to edit the project as before. It has the install and uninstall commands when right-clicking the install project, too. It installs fine.
When I try to uninstall, though, I get the following error and then the uninstall rolls back:
Could not open key: HKEY_LOCAL_MACHINE32\SOFTWARE\Wow6432Node\Microsoft\
EAPSIMMethods\18\FastReauthContext. Verify that you have sufficient
access to that key, or contact your support personnel.
I am not doing anything with that registry key, and there don't seem to be any relevant results on google-- at least not in the normal top 5 pages. Does anyone know what causes this or how I can fix it?
While I am not able to uninstall, I am able to increment the version of the package and allow it to remove the previous install and install the new version (all at once) successfully.
I am using Windows 8.1 Pro 64 bit, the projects are compiled for <AnyCPU>, and the installer is configured for x86.
EDIT I am running Visual Studio as Admin. When uninstalling from the Control Panel, I am also clicking the 'allow' button in the UAC dialog window that pops up.
I know how to give myself access to a registry key (permissions). I want to know why this key is trying to be removed. I support this app on several machines and I don't want to have worry about remembering an uninstall hack in the future.
EDIT This only seems to be an issue for a 32x installer on a 64x OS or a Windows 8 issue. I was able to use the same 32x installer to successfully uninstall the app on a 32x Windows 7 machine.
This must be an environmental problem, that key doesn't have anything to do with installers. EAP-SIM is an authentication protocol for wireless networks. The FastReauthContext key almost surely was meant to avoid having to provide a username+password each time your machine reconnects to the network. Which makes the registry key content very sensitive of course, it can only be read by a service that runs with the System account.
So, something goofy going on with your networking setup. Verify that you can successfully reconnect to such a network. If you used a VPN before then make sure it is active again. Something like this. Update your question with anything that might be relevant to networking when you first installed the app.
I have had similar problem and what I found out this is caused by MSI attempting to delete whole "Software\Microsoft" section in the registry. Lucky you that it encounters this error and rolls everything back.
So the solution is the following:
Since you have installed your program whenever you try to uninstall it the system will run msi from cache that is usually located C:\Windows\Installer.
Find your package in the cache. Here is an article that may help you http://csi-windows.com/blog/all/27-csi-news-general/334-identifying-cached-msi-packages-in-cwindowsinstaller-without-opening-them
Open the package in Orca. You must do this as administrator.
Go to Registry table and find record with "Software\Microsoft" as a key. Most likely the Name column will contain either "-" or "*" value. This means that during uninstall MSI will try to delete whole "Software\Microsoft".
Either change the Name value to empty or "+" or try to change key to something like "Microsoft". The second option will cause that installer will not find the key to delete during uninstall, but it will skip this error and let you uninstall your program.
You installed an untested installer on your dev machine? Speaking from experience, don't do that! Snapshotted VM's are cheap and will save you from this sort of pain.
Visual Studio Deployment Projects (or VSI as it's now called ) is known for creating very poor quality installs. The combination of those two put you where you are today.
I would need to look at the full uninstall log and your MSI using ORCA to understand exactly what is going on. MSI Zap and a manual cleanup of resources is probably required at this point.
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
In Visual Basic 6, when I attempt to access Project > References, it throws an error:
Error accessing system registry
I am:
Logged in as the local computer administrator
running Windows XP Professional and
I can execute regedt32.exe and access all the registry keys just fine.
VB6 was installed as the local administrator.
Any idea why this happens?
I'm running crystal reports 8.5 and it supposed to already have fixed that issue but apparently I still have the issue with 8.5 installed. I have also made the attempt of reinstalling crystal reports with no luck on the issue.
Depending on the Windows OS you have (I have Windows 7 Enterprise), you might want to try giving administrator rights to the REGTLIB.EXE (located in C:\Windws). Right click on the REGTLIB.EXE file. Select Properties from the pop-up menu. Then select the Compatiblity tab. On the Compatiblity tab, check/select the Run this program as Administrator checkbox. Click OK to save your changes. It might take take care of the problem for you. It worked for me. Good luck.
For me this worked:
goto C:\Program Files\Microsoft Visual Studio\VB98
change the property of VB6.EXE by right click->Compatibility In privilege level section, check the option Run this program as Administrator
If you're running Office 2010 (Beta) Word (apparently) writes a restricted registry key. VB throws the error when scanning the registry. The key I have is:
HKCR\TypeLib\{00020905-0000-0000-C000-000000000046}\8.5
For Regmon - Filter for Process Name -> "vb6.exe" and Result -> ACCESS DENIED. Helps find it very quickly.
Fixed it with PSToosl (PSEXEC) to run registry editor. The command line is,
psexec -i -d -s c:\windows\regedit.exe
psexec needs to be run with elevated-permissions.
Edit by Jim: I'm on a Windows 7 (x64) box. Elevated permissions require the PSTools solution. XP can get away with a little less.
You could try Process Monitor to see which registry keys are accessed.
I got this on a machine that I was using for VB6 development. I had been building a lot of COM DLLs from VB6 (without binary compatibility) and the cruft that had built up in the registry eventually got too much.
Have a look at what size the registry is and what limit you have set. I doubled the registry size and then went looking for a good registry hoover.
Here is a solution from Microsoft. It references the Crystal Reports problem, but the solution just uses regedit32 to walk the HKEY_CLASSES_ROOT\TypeLib and HKEY_CLASSES_ROOT\CLSID registry branches for dimmed keys and correcting the security on those keys. There are also instructions to fix the security if regedit32 is unable to access the key. Article ID: 269383
In Windows 7 go to start menu then right click "Microsoft Visual Basic 6" then select properties and click Compatibility from the dialog box that appears then tick "Run this program as an administrator".
Have you tried this? Basically, it seems that it is a crystal reports issue. Hope that helps.
Perhaps worth a try going to the "User Account Control Settings".
Regards,
When I installed VB6 on Win7-64 (using instructions easily found by a search engine), it worked fine. UAC was off -- i.e. set to "never notify."
After a few weeks I turned UAC on -- i.e. set it to its default. VB6 then couldn't compile because of the "Error accessing the system registry" problem. Unfortunately, turning it off again didn't help. Apparently the damage done by turning it on was irreversible. I can't explain why this should be, but that's my experience.
Giving REGTLIB.EXE administrative privileges while leaving UAC off sounded like a great idea, but that didn't work for me either.
Finally, using Process Monitor and PsTools as described in other posts here worked. However, I had to give Full Control to large parts of my registry to Everyone. This didn't apply just to isolated keys. It seems that the compiler needs to add keys to major nodes, so I had to open up these entire nodes.
Aside from the fact that working through these steps took hours, I'm now much more exposed than I was before I tried to increase security via UAC, However, I need VB6 and don't see another solution short of a new computer.
Lesson: Don't use UAC with VB6. Except if you've arrived here it's too late for that.
It's VB6 installation issue. Try to re-intall VB6 on your system. Otherwise open "visual studio 6.0" with "Run as Administrator". Then open/browse your project .vbp file via - New Project -> Existing tab.
I have fixed the problem. But none of the suggestion above worked. What I did is giving everyone full control over the SYSTEM key in the registry. This creats a security break. I am running 64bit Windows 7 with vb6 serice pack 6B.
I'm running Windows 10 Pro (10.0.16299 Build 16299) 64 bit. I was having this error when trying to compile a VB6 DLL.
I saw several answers in this post about running in compatibility mode as administrator. I thought I would first try just running in compatibility mode for Windows XP (sp2). I was able to compile my DLL after checking that box. I didn't need to run as administrator.