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.
Related
I am using SQL Server 2014 and I have created an SSIS package in SSMS using the Import Data Wizard.
The package imports a table from the database of a linked server and creates a copy on the main database. The SSMS wizard executed all the steps correctly and during one of the steps, I saved the settings as an SSIS package in the File System.
I then created a SQL Server Agent job to execute the package on a daily basis. The job failed to execute with the following error message:
(Import Data into PickUp Table).,00:00:01,0,0,,,,0
06/20/2018 17:18:00,PickUp Table,Error,2,XXXX\XXXXXX,PickUp Table,Import Data into PickUp Table,,Executed as user: XXXXXX\sql_bisvcs. Microsoft (R) SQL Server Execute Package Utility Version 12.0.5000.0 for 64-bit Copyright (C) Microsoft Corporation. All rights reserved.
Started: 5:18:01 PM
Error: 2018-06-20 17:18:01.16
Code: 0xC0010018
Source: PickUp
Description: Error loading value "
End
Error
Could not load package "C:\Users\Administrator\Documents\Visual Studio 2013\projects\PickUp\PickUp.dtsx" because of error 0xC0010014. Description: The package failed to load due to error 0xC0010014 "One or more error occurred. There should be more specific errors preceding this one that explains the details of the errors. This message is used as a return value from functions that encounter errors.".
This occurs when CPackage::LoadFromXML fails.
Source: PickUp
Started: 5:18:01 PM Finished: 5:18:01 PM Elapsed: 0.157 seconds.
The package could not be loaded. The step failed.
I tried to open the package in SSDT, but it failed giving me the same error messages as mentioned above.
What might be causing this error?
You can have a look at the value of Run64BitRuntime debug parameter and try different value True or False.
Depending of your environment, some DLL of third party software can be in conflict.
Also, if your SQL Server instance is on an other server than the computer on wich you want to run the job, you may not be able to execute the package with features you have not installed on this machine.
SSDT, Connector to each remote database / file etc..
Have a look at your SSDT version, if the package is generated via SSMS, it can have a version wich is not recognize by your local machine.
I have an MSI application with 2 versions v1 and v2 created using InstallShield 2011.
The application executes a SQL script (AddRoleMember.sql)
error 27505: Could not open SQL script file
AddRoleMember.sql executes successfully through v1 but throws an error in v2 for the same user with similar rights and permissions.
AddRoleMember.sql succeeds to execute in v2 only when v2 MSI is executed with Run as Admin command.
The SQL script is same for the both the installers.
There are no changes in v2 from v1 execpt ProductCode and ProductVersion.
Findings from troubleshooting:
Logs from v1 (success):
{
InstallShield 12:14:01: Setting Costing Info Location ISSearchReplaceRollback : C:\Users\APPCSE~1\AppData\Local\Temp\~18F9.tmp
MSI (s) (E8!AC) [12:14:01:445]: PROPERTY CHANGE: Adding ISSearchReplaceRollback property. Its value is'C:\Users\APPCSE~1\AppData\Local\Temp\~18F9.tmp'.
Action ended 12:14:01: ISSearchReplaceCosting. Return value 1.
MSI (s) (E8:F8) [12:14:01:445]: Doing action:ISSQLServerCosting
Action 12:14:01: ISSQLServerCosting.
Action start 12:14:01: ISSQLServerCosting.
MSI (s) (E8:04) [12:14:01:445]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI195B.tmp, Entrypoint: ISSQLServerCosting
1: Beginning SQL Server Costing Process...
1: Reading the SQL script data from ISSQLConnection table...
1: Finished SQL Server Costing Process...
1: Setting Costing Info Location ISSQLServerInstall : C:\Users\APPCSE~1\AppData\Local\Temp\~1948.tmp
MSI (s) (E8!A8) [12:14:01:508]: PROPERTY CHANGE: Adding ISSQLServerInstall property. Its value is 'C:\Users\APPCSE~1\AppData\Local\Temp\~1948.tmp'.
}
Logs from v2 (failed):
{
InstallShield 17:45:50: Setting Costing Info Location ISSearchReplaceRollback : C:\Users\APPCSE~1\AppData\Local\Temp\~96CD.tmp
MSI (s) (34!AC) [17:45:50:900]: PROPERTY CHANGE: Adding ISSearchReplaceRollback property. Its value is 'C:\Users\APPCSE~1\AppData\Local\Temp\~96CD.tmp'.
Action ended 17:45:50: ISSearchReplaceCosting. Return value 1.
MSI (s) (34:54) [17:45:50:900]: Doing action: ISSQLServerCosting
Action 17:45:50: ISSQLServerCosting.
Action start 17:45:50: ISSQLServerCosting.
MSI (s) (34:FC) [17:45:50:916]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI9736.tmp, Entrypoint: ISSQLServerCosting
1: Beginning SQL Server Costing Process...
1: Reading the SQL script data from ISSQLConnection table...
1: Finished SQL Server Costing Process...
1: Setting Costing Info Location ISSQLServerInstall : C:\Windows\TEMP\~97C8.tmp
MSI (s) (34!B4) [17:45:51:180]: PROPERTY CHANGE: Adding ISSQLServerInstall property. Its value is 'C:\Windows\TEMP\~97C8.tmp'.
}
It can be seen from the logs that after the execution of "ISSQLServerCosting" action, the path of Temp location changes in the case of failed installation. The path changes from user specific location to the machine location. Due to this, SQL script succeeds to execute only when executed as Run as Admin. In v1, the path fro Temp location remains user specific before and after the execution of "ISSQLServerCosting" action.
Question: Can anyone please suggest what might be the reason of this change in path in one of the installation? This is the major cause of failure of SQL script in my MSI project.
In the first log the temp is the user temp directory, and in the second it's the system temp directory. Since that action appears to be a custom action, and assuming that nothing else has changed, the first install may have been per-user and the second a per-system.
It's not clear what elevation may or may not have occurred: an MSI configured for elevation will show that elevation dialog after the UI sequence. I'd guess that the first was per-user and didn't need elevation and the second was per system and does need elevation (to access the system temp location).
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.
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 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