Custom Action ISXmlAppSearch did not close 3 MSIHANDLEs - error code 1603

[Solomon_Ajaxx]

I have an installer that was recently converted from Installshield Premier Spring 2012 to Premier 2015. The installer utilizes several System Searches to find values in existing configuration files. One file in particular, has 3 different elements who's values are being searched for. During installation, this configuration file doesn't exist on the target machine, so when the first element is searched for, the result is that the file doesn't exist. Everything is ok there. However, when it gets to the second element of the same file, instead of saying once again that the file wasn't found, the whole install chokes and starts spitting out "Leaked MSIHandle" errors in the install log (As can be seen below):

InstallShield 14:05:28: Searching for the contents of the XML Element using the Element '/connect/Example_1'.
MSI (c) (94!F0) [14:05:28:800]: Creating MSIHANDLE (106) of type 790531 for thread 3824
MSI (c) (94!F0) [14:05:28:816]: Closing MSIHANDLE (105) of type 790540 for thread 3824
MSI (c) (94!F0) [14:05:28:816]: Closing MSIHANDLE (106) of type 790531 for thread 3824
MSI (c) (94!F0) [14:05:28:816]: Creating MSIHANDLE (107) of type 790531 for thread 3824
InstallShield 14:05:28: The location of the XML file, stored in the Property 'DATABASE4', is currently a NULL value. It appears that the AppSearch did not find the file.

InstallShield 14:05:28: Searching for the contents of the XML Element using the Element '/connect/Example_2'
MSI (c) (94:14) [14:05:28:847]: Leaked MSIHANDLE (108) of type 790531 for thread 3824
MSI (c) (94:14) [14:05:28:847]: Leaked MSIHANDLE (30) of type 790540 for thread 3824
MSI (c) (94:14) [14:05:28:847]: Leaked MSIHANDLE (26) of type 790541 for thread 3824
MSI (c) (94:14) [14:05:28:847]: Note: 1: 2769 2: ISXmlAppSearch 3: 3
Info 2769. Custom Action ISXmlAppSearch did not close 3 MSIHANDLEs.
CustomAction ISXmlAppSearch returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

And of course, because this fails, we never get to the third element of the same file. So, as an experiment, I removed the search for the second element from the installer. Rebuilt, and sure enough, no more leaked MSIHandles. Here is where things get really weird, I go back into the installer, add a brand new entry for the one element search I just removed (Example_2), build the project, and it fails at the very same place it did before.

Any ideas on why this may be happening?

Thanks.

[troycumbo]

I'm seeing the same behavior, after the same move from IS 2012 to IS2015. Before the installer simply moved to the next search if the XML file it intended to search didn't appear. Now the installation fails if the XML files configured for System Searches are not present. Once I removed all such searches, the installation proceeded correctly.

Why would this have changed? Is this an upgrade problem from the 2012 format?

[BertoL]

I recently had the same error at one of our customers:
InstallShield 11:45:33: Searching for the contents of the XML Element using the Element '/FEDEX/SHIPNET2000[@TYPE="KEY"]/ADMINSVC[@TYPE="KEY"]/SETTINGS[@TYPE="KEY"]/VERSION[@TYPE="VAL"]'.
MSI (c) (64:70) [11:45:33:235]: Leaked MSIHANDLE (597) of type 790531 for thread 7436
MSI (c) (64:70) [11:45:33:235]: Leaked MSIHANDLE (596) of type 790540 for thread 7436
MSI (c) (64:70) [11:45:33:235]: Leaked MSIHANDLE (592) of type 790541 for thread 7436
MSI (c) (64:70) [11:45:33:235]: Note: 1: 2769 2: ISXmlAppSearch 3: 3
Info 2769.Custom Action ISXmlAppSearch did not close 3 MSIHANDLEs.


I also search the internet but did not find a straightforward answer. After a closer look at my application I found out that the xml file where "ISXmlAppSearch" was trying to read from existed but was empty (while it should not have been empty). Putting the original xml file back resolved the problem.

In other words:
If you have added an entry in the InstallShield "Installation Designer" => "Behavior and Logic" => "System Search" to look for an "XML file value" and put this value into a property ... you might want to double check that this xml file is not empty.