I am trying to run an installer using the MSI command line option so that I can run it in debug mode and see the logs.
The logs that I am getting are quite large (near to 1 MB) and they are full of the following messages:
MSI (s) (F8:5C) [16:26:27:385]: Note: 1: 2360
I want to know if this is something to worry about? I have looked up the error code 2360 at Windows Installer Error Messages page on msdn and all it says that
Progress tick.
Is there something that I need to change in my installer?
I have recently added a CustomAction that makes use of System.Xml namespace. Could this be a cause?
I'm working with msi's for the first time and I see what you're talking about.
The reason you're getting "Note 1: 2360" is because the computer is writing. Writes take a long time which is why there's so many. Look at the 4 lines before the 2360. It'll be something like
Executing op: FileCopy(SourceName=somename,...)
File: <filepath>filename; To be installed; won't patch; No existing file
Source for file 'bunch of letters and numbers' is compressed
Note: 1: 2318 2: <filepath>filename
Note: 1: 2360
Note: 1: 2360
etc...
etc...
It tries to do a FileCopy of the existing file. Finds it doesn't exist. Identifies the source file. Throws error code 2318 of the new file because it doesn't exist yet (2318 means file does not exist). Then it starts writing and tells you its doing something by printing out "Note: 1: 2360".
If you ran the installer again I'm sure you'd find zero "Note: 1: 2360" anywhere in the log.
I have found some information in the comments to article posted here
> Most times these "Note:" entires are just for information but sometimes they are precursors to other errors.
posted by
Robert Flaming
Windows Installer Program Manager 1
I hope the messages that I am getting are in fact just for information.
It should not be because of Xml namespace. Please run this command in command prompt and provide the error details
msiexec /i "Path to msi" /l*v log.log
Once you get error, you can use WiLogUtl to read the log file. The tool is available with Windows SDK. Also the report will help you get exact error location
Related
I have a WIX installer that acts as a content installer for users. It's supposed to install these files in a specific directory. Unfortunately when I run it I get the following error: "The system cannot open the device or specified file." This then gives me error code 2755 after canceling the install (retry does not work).
I've looked through other questions with similar issues, and it does not appear to be an encryption problem on temp, the install folder, or the MSI installer itself - these all appear fine. This also isn't a problem with the C:\Windows\Installer folder being read-only.
I've never had a problem with a WIX installer before. What other things can I try to get this working?
For me the problem solved when the installer run as administrator.
I was seeing all of the following errors when installing my 3.5 GB .msi generated by WiX:
DEBUG: Error 2709: The specified Component name ('cmpF7216C180B7A7119CC61FDB3BD209D5D') not found in Component Table.
DEBUG: Error 2755: Server returned unexpected error 110 attempting to install package D:\...\setup.msi.
The system cannot open the device or specified file
Turning off EmbedCab made them all go away:
<Wix>...
<Product>...
<MediaTemplate EmbedCab="no" />
I unfortunately now have 30 cab files to deal with, but at least the install succeeds.
I have created a Web Server setup in WiX (3.8), It gets installed correctly, but when i Repair it, I get an error 'Fatal error during Installation' and the process is rolled back. below is what i see in logs
MSI (s) (F8:C4) [12:39:26:183]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (F8:F8) [12:39:26:188]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI7B14.tmp, Entrypoint: WriteIIS7ConfigChanges
WriteIIS7ConfigChanges: Error 0x80070002: Site not found for create application
WriteIIS7ConfigChanges: Error 0x80070002: Failed to configure IIS application.
WriteIIS7ConfigChanges: Error 0x80070002: WriteIIS7ConfigChanges Failed.
CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 12:39:26: InstallFinalize. Return value 3.
Am i missing out something. Any help is appreciated, Thanks in Advance :)
If it's a repair and the site name is missing, chances are that it was entered in a UI dialog in the original install. In a repair there is no UI to re-enter the site name and properties aren't automatically saved. It may be trying to configure a site with no name. The best way to deal with this type of thing in general is to use the WiX remember property pattern on the site name so that it is preserved and is available for a repair. I can't tell if that would be a good thing in this particular case because I don't know if writing the config changes again on top of the existing config changes will work or be handled correctly by the code. A verbose log of the original install should tell you what property names are being used for site names etc.
If you think it's unlikely that the IIS config changes will break and that they won't need repair, you could consider adding "Not Installed" to the condition on the CA so that a repair won't call it.
we have to install our product with InstallShield on several systems. During installation we have to execute some SQL scripts, this works properly in nearly every case.
Except a Japanese Windows XP we have (x86 with SP3).
(It doesn't fail on every machine, just on some).
First it happen that, even the installation was running and end without an error output, the application was not running because of missing database and SQL instance settings.
In the MSI I first found no problem.
I found registry entries which has expand the log file a little more, and because of that I was able to see an error on one place.
The installer is not possible to extract the SQL scripts out of the installer temp files.
This is how a working installation looks:
MSI (s) (D0:CC) [06:32:27:394]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI2B17.tmp, Entrypoint: ISSQLServerCosting
1: Beginning SQL Server Costing Process...
1: Reading the SQL script data from ISSQLConnection table...
1: ISSQLRequirement table does not exist...
1: ISSQLRequirement table does not exist...
1: Finished SQL Server Costing Process...
1: Setting Costing Info Location ISSQLServerInstall : C:\Users\UserName\AppData\Local\Temp\~2B44.tmp
MSI (s) (D0!9C) [06:32:27:465]: PROPERTY CHANGE: Adding ISSQLServerInstall property. Its value is 'C:\Users\UserName\AppData\Local\Temp\~2B44.tmp'.
...
(There are some more "Setting Costing Info Location" lines with "PROPERTY CHANGE: Adding".)
But on the not working Japanese XP it looks like:
MSI (s) (8C:E0) [14:51:37:031]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI30.tmp, Entrypoint: ISSQLServerCosting
1: Beginning SQL Server Costing Process...
1: Reading the SQL script data from ISSQLConnection table...
1: ISSQLRequirement table does not exist...
1: An unhandled exception occurred in ExtractScriptFile()
1: An unhandled exception occurred in ExtractScriptFile()
1: An unhandled exception occurred in ExtractScriptFile()
1: An unhandled exception occurred in ExtractScriptFile()
1: ISSQLRequirement table does not exist...
1: An unhandled exception occurred in ExtractScriptFile()
1: Finished SQL Server Costing Process...
1: Setting Costing Info Location ISSQLServerInstall :
1: Setting Costing Info Location ISSQLServerUninstall :
There we see unhandled exceptions and no result for the actions.
In a MS help page I saw for "unhandled exceptions" that this may caused by errors in the netapi32.dll, so I tried to replace it with another version. This has not changed anything, further was during installation the newer version replaced by the original one anyhow.
There are the same amount of temp files during installation (in %temp%) which will be created on working systems as well.
On a virtual machine with the Japanese Windows XP it works normally, I find no difference.
All works find and without errors, just the missing SQL scripts happen on that system. The installation itself does not end with an error.
I'm out of ideas :-/ Please help
I figured out, it works if I change the "TEMP" and "TMP" paths to anything else.
I don't know why the original temp paths has problems, temp files can be written and deleted, only extracting of the SQL files (or check in which temp script files are located) failes.
I compared with a working machine and the system user has no different rights or something.
I'm having some strange issues with WiX on my local machine. The problem is intermittent, but after a few rebuilds of the solution, the WiX project starts throwing ICE validation errors.
If I go into my AppData\Local\Temp folder and delete all the temporary folders that contain the MSI, the solution compiles again. A short while later, the problem starts happening again. Having to keep clearing down the temp folders isn't a sustainable or satisfactory solution.
Has anyone else encountered this issue? The validation error codes seem to always be a combination of ICE30, ICE38, ICE64 and ICE91
Update:
As requested, here are the entries from the most recent failure:
error LGHT0204: ICE38: ICE Internal Error 1002. API Returned:
1615. error LGHT0204: ICE38: Error 2235: /OU.AppFramework.Includes.msi, _Profile, UPDATE Directory SET
_Profile=0 error LGHT0204: ICE64: ICE Internal Error 1001. API
Returned: 1615. error LGHT0204: ICE64: Error 2242:
OU.AppFramework.Includes.msi, _Profile, ALTER TABLE Directory ADD
_Profile SHORT TEMPORARY HOLD error LGHT0204: ICE91: ICE
Internal Error 1001. API Returned: 1615. error LGHT0204: ICE91:
Error 2242: OU.AppFramework.Includes.msi, _Profile, ALTER TABLE
Directory ADD _Profile SHORT TEMPORARY HOLD
Interestingly, this failure occurred before I left the office last night, and the solution compiled OK when I came in this morning. As it seems to centre on the temp directory where the MSI is build by WiX, could it be the build process locking the file?
Update 2:
And now we're back to over 600 errors, mostly repetition of this error:
error LGHT0204: ICE30: ICE Internal Error 100. API Returned: 1615.
error LGHT0204: ICE30: Error 2235: AppFramework.Includes.msi,
_ICE30SFN, SELECT Directory_Parent, Directory, DefaultDir, _ICE30SFN, _ICE30LFN FROM Directory WHERE
Directory.Directory=? AND Directory_Parent<>?
Update 3:
The problem still exists even after trying the suggestion by #limpan. There are a couple of warning given by light that are caused by the MSI output folder being locked when light tries to access the MSI:
Warning 549 The directory '\AppData\Local\Temp\2opu3hxf' is in use and cannot be deleted. light.exe
Try adding <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> to your WiX project file.
We've had the same issue for a while, and tried various workarounds including deleting the temporary files and setting the msbuild environment variable. These all appeared to work for a while, but eventually (sometimes after a few days) the problem would come back again.
I noticed that on my machine devenv.exe was the process that was locking the files that light.exe was trying to delete. I also stumbled across an unrelated thread which mentioned this project setting to make the WiX tools run out of process. I thought it could be worth a try and it appears to have cured the problem for us (so far...)
I had this issue as well and solved it in my environment.
Short answer:
Add the environment variable MSBUILDDISABLENODEREUSE=1 and restart Visual Studio
Long answer:
There was a warning during build that I first didn't see since I was too focused on the error:
Failed to delete temporary directory: C:\Users[username]\AppData\Local\Temp\5[uniqueFolderName] light.exe
I tried to remove the folder manually, but it was in use by another process.
It turns out that a lot of MSBuild.exe processes are started during build and then not closed again.
You can read more about the reason for that and what you can do to change that behavior in Stack Overflow question msbuild.exe staying open, locking files.
This thread: it and the solution in this thread:
I hope this answer can help someone else.
For ICE30: ICE Internal Error 100. API Returned: 1615, please try this and see if it works:
Close all instances of Visual Studio (may be just the one that matters but just in case)
Go to C:\Documents and Settings\\****user id****\\Local Settings\Temp\.
Clear all the folders that look like this .. 's12qgaks'. Basically it contains the MSI files
Open the solution and recompile.
Good luck!
I too had faced same the issue. In project properties, go to Tool Settings and click Suppress ICE validation.
For me MSBUILDDISABLENODEREUSE=1 (or /nr:false on command line) did not solve the problem.
But <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> did its job done.
I had the same issue. It turned out to be my Anti Virus software (OfficeScan) It had the intermediate files created by Light.exe locked and the validation process failed. Excluding the temp folder from virus scan or turning off ICE validation is not an acceptable solution.
If anyone has a better solution. I would like to know.
I'm using WiX 3.5. Recently, the following WiX error started occurring frequently on the build server:
light.exe (,): error LGHT0301: Failed to open the database. During validation, this most commonly happens when attempting to open a database using an unsupported code page or a file that is not a valid Windows Installer database. Please use a different code page in Module/#Codepage, Package/#SummaryCodepage, Product/#Codepage, or WixLocalization/#Codepage; or make sure you provide the path to a valid Windows Installer database.
Which "database" does the error refer to? (None of the WiX source files have changed in a long time, so I doubt it's a code page problem.)
Other people have reported that this error may be caused by Trend Micro Office Scan, which is indeed installed on the build server. I asked the system administrator to exclude the build directories from the scan, but this error still occurs. How can I determine whether the virus scanner is the culprit? (The error doesn't always occur, so if I disable the virus scanner and the next build succeeds, I still don't know whether the error has gone away permanently.)
The "Disable the ICE validation" worked for me - just a setting through Visual Studio 2012 in the .Setup.
After studying the WiX source code and running Process Monitor, I found that excluding the build directories from the virus scan is insufficient.
Explanation: When light.exe runs, it creates the target MSI file in a temporary directory. (This file is the database that the LGHT0301 error message refers to.) After light.exe closes the MSI file, ntrtscan.exe opens the MSI file for read access and read-only sharing. Later, in the database validation step, light.exe tries to reopen the MSI file for read/write access, and a sharing violation occurs.
Solution: Exclude the temporary directory from the real-time virus scan. On Windows Server 2008, for example, this directory is C:\Users\«username»\AppData\Local\Temp.
This is a common problem with build processes and antivirus. The scanner will detect the new MSI package and try to scan it. Meanwhile the build process also tries to validate it by running the Internal Consistency Evaluators (ICE) suite and you get a failure because the database has a mutex on it.
You should just remove the virus scan from your build output folders. Alternatively decouple the validation from the Light command so that the antivirus scan relinquishes the MSI handle before you run the ICE validation.
I had the same problem which was actually really related to codepages and language settings of my system.
Adding English input language in Windows' regional settings solved the problem on my German Windows installation.
The real cause was Trend Micro real time scanning!
(The following is only for historical reference)
I followed #Michael Liu answer and solved the problem
I had the same problem.
I am not referring to Codepage (or SummaryCodepage) in any of those tags, or in fact anywhere in the WXS. Putting Codepage="1252" didn't change anything.
Finally, I tried adding
encoding="utf-8"
to the XML tag which previously only had a version='1.0' attribute. This fixed the problem, as described in "Failed to open the database" error. - SOLVED
It was also the antivirus program for me.
An easy way to check if the problem is related to the anti-virus program is to disable the ICE validation in the WiX project setting (using version 3.7). This worked for me, and is a permanent setting now, since in our company you can't change the setting of the antivirus software.
This is the most common error I found while using WiX. The easiest solution for this is go to Properties of your project → Tool Settings → (Check) Suppress ICE Validation.