cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
DLee65
Level 13

Suite error when executing InstallScript custom actions

I have a suite application that is failing to install. It errors out when I get to the first InstallScript custom action.
7-29-2014[03:52:13 PM]: Launching InstallScript action in function 'IsOsSupported'
7-29-2014[03:52:13 PM]: Engine: request for proxy handler, 0, 0
7-29-2014[03:52:24 PM]: Action returned value 0x0000006d
7-29-2014[03:52:24 PM]: Action 'IsOSSupported' returned status 0x80070643
7-29-2014[03:52:24 PM]: UI DLL: Shutting down
7-29-2014[03:52:24 PM]: Original exit status: 0x80070643, final exit status: 0x00000643

This has been successfully installed on other systems.
.net is installed and win 7
Windows is logged in as Admin
Running the installer as Admin and unblocked
Ran Windows Updates and rebooted the Win 7 Home Premium PC

EDIT: Note that the user sees a windows message indicating that the ISRT.dll file failed to load. It appears to be a .NET framework type of error but this is Windows 7 home edition.
Labels (1)
0 Kudos
(17) Replies
RobFlum
Level 3

Is .NET installed?
What version is \mshtml.dll?
Rob
0 Kudos
DLee65
Level 13

The installer includes .NET 3.5 sp1 and .NET 4.0. These installation bits have registry checks to see if the component is installed. (OOPS, was not thinking correctly, the code never hits this path because of the error. :))

Client Services has checked if .NET is installed as well. Also I would expect that Windows 7 home edition comes with .NET 3.5 SP1 already pre-loaded.
I am not certain what version of mshtml is installed, but I suspect it is at least whatever comes with Windows 7 home edition.
Is it possible for this file to be 'uninstalled'?
0 Kudos
RobFlum
Level 3

No, I mean does the target machine have .NET installed. This error is often associated with a bad .NET installation on the target. If you can, repair the .NET installation(s) that are on the target.
You may not uninstall mshtml.dll; it's used by a bunch of applications.
0 Kudos
DLee65
Level 13

Thank you for the reply Rob.

I am just curious, if .NET framework is a prerequisite how does our installation work on a system that does not have .NET Framework installed. Do all modern operating systems have some basic .NET Framework installed? I am thinking in particular of Server 2008 R2 where the .NET Framework 3.5 is disabled by default. We test on this operating system without any problems.

Do you know if ISRT.dll is dependent on .NET Framework, if so that makes the InstallScript custom actions a bad choice for Suite installations.
0 Kudos
RobFlum
Level 3

.NET is not a prerequisite for installations in general. You say that your installer includes 2 versions of .NET. I would guess that when your installer attempts to install one of them, it recognizes that the target's .NET is corrupt and raises the error. My first crack at this issue would be to uninstall and re-install the .NET version that provoked the error.
.NET comes with some versions of Windows, not all. Some versions of .NET don't come with any Windows versions. You have to check whether .NET is present.
I don't know if ISRT.dll is dependent on .NET.

good luck, Rob
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

The dialog you are seeing indicates that a crash is occurring somewhere in ISRT.dll which is loaded in a helper process used to run InstallScript actions in suite installers. The error displayed to the user isn't specifically regarding anything with relation to .NET, it is indicating that a crash (access violation - 0xc0000005) occurred somewhere in the module 'ISRT.dll'. The error that is logged in the suite debug log seems to back this up with the action return value of 0x6d (ERROR_BROKEN_PIPE - The pipe has been ended.), indicating that communication with the helper process failed. It's difficult to tell exactly what would be crashing in ISRT.dll since we don't have a repro for this behavior currently.

Can you provide any information on the following:
- What does your script action do? Does it call out to any DLLs, call any InstallScript functions, etc.?
- Are you able to run a suite installer with an InstallScript action that calls an empty script action on one of these machines (if this still fails this would imply there is an issue in the initialization code in ISRT.dll)?
- Is there anything else on these machines such as antivirus/antimalware utilities that can be disabled prior to launching the suite installer? Does disabling any such software change the InstallScript action behavior?
- Can you attach any information provided from that crash dialog? Specifically, if any data lists the faulting address, the base/load address of ISRT.dll, or anything else related, that might be helpful in attempting to determine what code in ISRT is crashing.
0 Kudos
DLee65
Level 13

Josh, ty for the reply.

The InstallScript custom action called is the function:

export prototype IsOsSupported(OBJECT); 						//HANDLE to ISSUITE project


The function is:

/*
@brief checks for service packs required by SQL Server

@return true if the service pack requirments are met, false otherwise

@author: Daniel Lee
@date: 01/24/2014
@version: 1.0
@Update: Initial implementation
*/
function IsOsSupported(oExtension)
NUMBER nOSType, nSP, nBuffSize;
STRING strServicePack, svClientSupported, svMainSupported;
STRING svOSName, svOSVERworkstation, svOSVERserver ;
NUMBER nvOSVER, nvMajorVer, nvMinorVer;
CHAR cOSType;
OSVERSIONINFOEX sOSInfo;
OSVERSIONINFOEX POINTER pOSInfo; //Pointer to OSInfo
BOOL bResult;
begin
ISDeterminePlatform();
if (DEBUG==1) then
//Set OS for debugging
strServicePack="1";
SetOSValues("VISTA","WIN2K8","601","602");
SuiteSetProperty("SERVICEPACK",strServicePack);
else

pOSInfo = &sOSInfo;

pOSInfo->nOSVersionInfoSize=nBuffSize;
bResult = GetVersionEx(&pOSInfo);

cOSType = pOSInfo->nProductType;
nOSType = SYSINFO.nOSProductType;
nSP = SYSINFO.WINNT.nServicePack;
nvMajorVer = SYSINFO.nWinMajor * 100;
nvMinorVer = SYSINFO.nWinMinor;
NumToStr(strServicePack, nSP);
if (nvMajorVer<= 500 && nvMinorVer < 1) then
//Test for Windows 2000 and earlier operating systems
SuiteSetProperty("OSVALID", "FALSE");


elseif (nvMajorVer == 500) then
//Windows XP and Server supported.

SetOSValues("WINXP","WIN2K3","501","502");
SuiteSetProperty("SERVICEPACK", strServicePack);
SuiteSetProperty("OSVALIDMAIN", "FALSE");
if (nSP >= 3) then
SuiteSetProperty("OSVALIDCLIENT", "TRUE");
else
SuiteSetProperty("OSVALIDCLIENT", "FALSE");
endif;

elseif (nvMajorVer == 600 && nvMinorVer == 0) then
//WinVista
//Determine if Vista or Server
SetOSValues("VISTA","WIN2K8","601","602");
SuiteSetProperty("SERVICEPACK",strServicePack);
SuiteSetProperty("OSVALIDCLIENT","TRUE");
if (SYSINFO.WINNT.nServicePack >= 2) then
SuiteSetProperty("OSVALIDMAIN","TRUE");
else
SuiteSetProperty("OSVALIDMAIN","FALSE");

endif;
elseif(nvMajorVer == 600 && nvMinorVer == 1) then
//Win7
SetOSValues("WIN7","WIN2K8R2","610","611");
SuiteSetProperty("SERVICEPACK",strServicePack);
SuiteSetProperty("OSVALIDCLIENT","TRUE");
if (SYSINFO.WINNT.nServicePack >= 1) then
SuiteSetProperty("OSVALIDMAIN","TRUE");
else
SuiteSetProperty("OSVALIDMAIN","FALSE");

endif;

elseif(nvMajorVer == 600 && nvMinorVer == 2) then
//Win8 and newer do not require service packs all are supported
SetOSValues("WIN8","WIN2K12","620","621");
SuiteSetProperty("SERVICEPACK",strServicePack);
SuiteSetProperty("OSVALIDMAIN","TRUE");
SuiteSetProperty("OSVALIDCLIENT","TRUE");

elseif(nvMajorVer == 600 && nvMinorVer == 3) then
//Win8.1 & SQL Server 2012 R2
SetOSValues("WIN81","WIN2K12R2","630","631");
SuiteSetProperty("SERVICEPACK",strServicePack);
SuiteSetProperty("OSVALIDMAIN","TRUE");
SuiteSetProperty("OSVALIDCLIENT","TRUE");
endif;

endif;

end;


This does work correctly in most cases, and as stated before we are unable to reproduce the problem in house.
Yes, support has gone through and disabled AV, and other similar types of software.
We have tried restarting the machine (this works sometimes), switching users, creating a new user account, etc.
The customers involved may have multiple machines in their practice where the install is successful, and usually it is only one machine with the problem.
I do not have the full text of the error. I will check with support to see if they can get that information for me.

Here is what support has done:
1. Windows is logged in as a user account that has admin rights
2. Logged out of the user account and logged in directly as the Admin account
3. Disabled IOLO System Shield virus protection
4. Disabled the Windows Firewall
5. Running the installer as Admin and unblocked
6. Ran Windows Updates and rebooted the Win 7 Home Premium PC
7. Ran a CMD to re-registered all DLLs in the Win System 32 Folder
(FOR %a IN (c:\windows\system32*.dll,c:\windows\system32*.ocx) DO c:\windows\system32\regsvr32.exe /s %a)
8. Ran a CMD to re-registered all DLLs in the Win Syswow64 Folder
(FOR %a IN (c:\windows\syswow64*.dll,c:\windows\syswow64*.ocx) DO c:\windows\syswow64\regsvr32.exe /s %a)
9. Ran Registeritall.bat from the Amazing Charts directory
10. Ran Disk Cleanup
11. Ran Windows Updates again and rebooted again
0 Kudos
DLee65
Level 13

joshstechnij wrote:

Can you provide any information on the following:
- What does your script action do? Does it call out to any DLLs, call any InstallScript functions, etc.?
- Are you able to run a suite installer with an InstallScript action that calls an empty script action on one of these machines (if this still fails this would imply there is an issue in the initialization code in ISRT.dll)?
- Is there anything else on these machines such as antivirus/antimalware utilities that can be disabled prior to launching the suite installer? Does disabling any such software change the InstallScript action behavior?
- Can you attach any information provided from that crash dialog? Specifically, if any data lists the faulting address, the base/load address of ISRT.dll, or anything else related, that might be helpful in attempting to determine what code in ISRT is crashing.


Josh, here is the info from support. They obtained this from the event viewer of one of the machines that had the error. Interestingly enough the install works today. Yes, that is correct, today it chooses to work correctly. It is the same identical installation package, and everything too.

[CODE]Faulting application name: AmazingChartsV7.1.1 Build 135.exe, version: 7.1.1501.0, time stamp: 0x51a6d609
Faulting module name: ISRT.dll, version: 20.0.0.376, time stamp: 0x51a6cc6d
Exception code: 0xc0000005
Fault offset: 0x0002268d
Faulting process id: 0x1044
Faulting application start time: 0x01cfa841c2a1eb74
Faulting application path: C:\AmazingChartsV7.1.1 Build 135.exe
Faulting module path: C:\Users\chandu\AppData\Local\Temp\{1EC9FBD2-FF6C-401E-9302-E1F9AAE5C35F}\ISRT.dll
Report Id: 019492da-1435-11e4-b80e-c81f66157462

___________________________________



- System

- Provider

[ Name] Application Error

- EventID 1000

[ Qualifiers] 0

Level 2

Task 100

Keywords 0x80000000000000

- TimeCreated

[ SystemTime] 2014-07-25T19:51:03.000000000Z

EventRecordID 10820

Channel Application

Computer chanduPC

Security


- EventData

AmazingChartsV7.1.1 Build 135.exe
7.1.1501.0
51a6d609
ISRT.dll
20.0.0.376
51a6cc6d
c0000005
0002268d
1044
01cfa841c2a1eb74
C:\AmazingChartsV7.1.1 Build 135.exe
C:\Users\chandu\AppData\Local\Temp\{1EC9FBD2-FF6C-401E-9302-E1F9AAE5C35F}\ISRT.dll
019492da-1435-11e4-b80e-c81f66157462
[/CODE]
0 Kudos
DLee65
Level 13

I am finally able to reproduce this problem consistently. It only occurs for test systems on a domain and when I log into a system as a domain user but the domain user has not been added to the local users group by name.

To fix the problem click the start orb
[LIST=1]
  • Type in 'users' in the search box and click 'Edit local users and groups'
  • In the left panel click Groups
  • In the middle panel double click Users
  • Click Add button
  • Type in the \ name and click Check Names. A fully qualified domain name should fill the box. Click OK
  • Log out and back in again as the domain user and test the install. This time it will run without errors.



    NOTE:
    [LIST=a]
  • "\Domain Users" is added to the local Users group. The user I log in with has been added to the Domain Users group and so by extension should be part of the local users group. However, until I add the user by name the setup will fail.
  • Logging in as the domain admin allows the setup to run successfully without the domain admin being added by name to the users or administrators groups. So as I would expect, domain admin trumps all.
  • When installing as a domain user I still have to provide credentials to execute the setup since it requires elevated permissions. This is expected.
  • In all cases the default UAC settings for Windows 7 was enabled.



    I have re-opened my Flexera Case with this information. Hopefully someone from there can also reproduce the issue and find a solution other than my work around. This should have worked logging in as a domain user.

    EDIT: We have had another customer encounter this issue on:
    Toshiba Satellite L655
    P6200@2.13GHz 2x
    W7 Home Premium SP1 x64

    Since this is Home Premium the active directory solution above does not apply. The info above may be helpful for InstallShield to reproduce the issue however. The customer has two Toshiba Satellite L655 systems and on both of them the problem occurs.
  • 0 Kudos
    DLee65
    Level 13

    Well, I retract my "Solved" resolution. This case gets stranger as time goes on.
    Today we had a practice get the error using a new Windows 7 x64 Home system. Client Services tried to install version 8.0.2 of our product and it fails.
    However, if they go back to version 7.1.3 of our product, then it will install successfully on that same target system.

    The Suite code is identical from version 7.1.3 to 8.0.2 other than the change for version number. The InstallScript code called has not changed since I originally created it.

    Also, I tried to go back and recreate the scenario from above and could not do so. When I first thought I had a resolution I repeated the problem many times, even with new virtual machines. Also many of our customers are connected via workgroups and not a domain controller.

    So I do not know if this is an issue with the package not being able to extract ISRT.dll because of the way the bits line up on a particular build? Why would version 7.1.3 install for the customer but not 8.0.2. Further, why is is always just one machine on the network that has an issue? No matter what we do we cannot get the application to install normally.

    For now, since all prerequisites are now installed successfully, I am going to extract the primary package and install that from a command line.

    For the future, I just might give up on InstallScript custom actions and create a C custom action for the suite package. So far I have seen six different customers report this same issue. In all reported cases to date, only one of the multiple systems per site seem to be affected. This is beginning to move from an anomaly to a very bad irritant especially since a different build of the software will work on the same system. It just does not make logical sense to me and it is difficult for us to explain to a customer that this issue will require their operating system to be installed again to fix the issue, especially when an earlier version works.

    EDIT: I just learned from Client Services that the practice affected yesterday had two new computers that were affected by this issue. So the operating system install should have been very basic and new. This is the first time that I have seen more than one computer affected.
    0 Kudos
    DLee65
    Level 13

    I am seeing a strange uptick in the number of systems affected.
    We have three practices that have encountered the same problem. In all of these cases it is usually just one system out of a bunch of computers that get upgraded.
    For at least one of these practices in the last three days, reformatting and installing the OS again fixes it. I have not got results from the other two.

    This is more than just annoying now. It is a problem.
    In most all cases, installing the previous version still works.
    For instance let's say a practice has 7.1 installed and they are upgrading to 8.2.2. The upgrade to 8.2.2 will fail every time, even if we uninstall the previous version manually. However, if we run the install for 7.1 again, the install completes correctly.

    For one of the practices I extracted the primary package and tried to install it. It also fails because I include some InstallScript custom actions.

    What is going on with the ISRT.dll file? Is there some sort of dependency that it requires that is missing from one version to the next? I realize that this is the InstallShield Runtime file. I wish the ISRT error would give more information about why it fails.

    I cannot reproduce this behavior in our environment.

    Many of the systems affected are Windows 7 Home Premium. The one from this morning is x64. In many cases the customer has AVG installed, CCleaner, and MalwareBytes

    It is so frustrating because it cost so much of our time in Client Services, in my time, and there isn't anything I can tell the customer other than reformat and install the operating system again.
    0 Kudos
    joshstechnij
    Level 10 Flexeran
    Level 10 Flexeran

    Hi Dan,

    ISRT.dll doesn't have much in the way of dependencies beyond what is provided in box with Windows XP SP2 and newer versions of Windows. All other dependencies are dynamically linked at runtime or are internal InstallScript engine COM interface dependencies (which can be an issue if COM is broken or COM permissions are not set to sane values which can cause basic things like QueryInterface to fail). Most of these dependencies are UI related (either internal or external to the engine) as ISRT handles a large chunk of UI functionality in InstallScript. It is also used to implement functionality not directly possible in script code (for example: CoGetObject, DotNetCoCreateObject) or things that are just easier to implement in C++. It also serves as an entry point to functionality implemented in the core InstallScript engine (file transfer or registry access, for example).

    With the initial release of the InstallScript engine/runtime for InstallScript actions in suites (IS 2013) there were some reports of crashes in ISRT.dll that were caused by invalid attempts to access InstallScript UI (which doesn't exist for these actions). These occurred mainly due to missed code that interacted in a non-obvious manner with the UI. The reported issues were resolved for IS 2014 or 2014 SP1 (depending on when they were reported).

    - Have you been able to try building any of suite installations with IS 2014 SP1 or newer?
    - Have you been able to try running a test suite project that includes a 'do nothing' InstallScript action?

    If you have been able to do any of these above things, what were the results?

    One thing that we might be able to try is running these setups with a debug build of ISRT.dll. Unfortunately this sometimes results in behavior that won't reproduce with the debug build. In any case, it might still be beneficial to see if that yields any additional information that might help if isolating the problematic behavior. If you are able to test this on a machine that can reproduce the issue, send me a private message and we can try that route.
    0 Kudos
    DLee65
    Level 13

    joshstechnij wrote:
    Hi Dan,

    ISRT.dll doesn't have much in the way of dependencies beyond what is provided in box with Windows XP SP2 and newer versions of Windows. All other dependencies are dynamically linked at runtime or are internal InstallScript engine COM interface dependencies (which can be an issue if COM is broken or COM permissions are not set to sane values which can cause basic things like QueryInterface to fail). Most of these dependencies are UI related (either internal or external to the engine) as ISRT handles a large chunk of UI functionality in InstallScript. It is also used to implement functionality not directly possible in script code (for example: CoGetObject, DotNetCoCreateObject) or things that are just easier to implement in C++. It also serves as an entry point to functionality implemented in the core InstallScript engine (file transfer or registry access, for example).

    With the initial release of the InstallScript engine/runtime for InstallScript actions in suites (IS 2013) there were some reports of crashes in ISRT.dll that were caused by invalid attempts to access InstallScript UI (which doesn't exist for these actions). These occurred mainly due to missed code that interacted in a non-obvious manner with the UI. The reported issues were resolved for IS 2014 or 2014 SP1 (depending on when they were reported).

    - Have you been able to try building any of suite installations with IS 2014 SP1 or newer?
    - Have you been able to try running a test suite project that includes a 'do nothing' InstallScript action?

    If you have been able to do any of these above things, what were the results?

    One thing that we might be able to try is running these setups with a debug build of ISRT.dll. Unfortunately this sometimes results in behavior that won't reproduce with the debug build. In any case, it might still be beneficial to see if that yields any additional information that might help if isolating the problematic behavior. If you are able to test this on a machine that can reproduce the issue, send me a private message and we can try that route.


    Josh,
    Thank you for the reply. As you may suspect reproducing this problem is nearly impossible. I thought I had a reproducible scenario last year, but the very next day I tried it again and the install worked in that same scenario! The installer never changed.
    I have not tried a newer version of InstallShield yet. Currently I am trying to gain enough evidence to convince management we need to fix the problem. Knowing that you have reworked the ISRT.dll may help convince them, but on the other hand they may not want to invest in the many hours of testing involved to upgrade.

    What I find very frustrating is that on some of these systems we can uninstall the previous released version and reinstall it without any error. But if we try the newer build it will cause errors. These scenarios are somewhat embarrassing for us as a company as the only solution to date is to recommend a format and reinstall of windows.

    Maybe it is COM or something related but it does not explain the scenarios where the previous version installs successfully but the newer version does not.

    Today another customer got the error on a Windows Server 2008 R2 system. It was fixed simply by logging in as the system administrator rather than a user with admin rights. This is not true of other systems. For instance in some cases we create a new user with admin rights. Even with a new user the error will continue.

    I don't think this is the UI issue either. I was very careful to follow your requirements to remove those items from the settings for compile. If it were the UI issue I would suspect we would have caught the problem before release as we spent hundreds of hours on testing the install before release.

    Another thought, is it possible there could be something wrong with the build machine that causes these problems. New releases are seldom done on the same build machines in our work environment. I am now wondering if there was something I need to do on the SAB system.
    0 Kudos
    joshstechnij
    Level 10 Flexeran
    Level 10 Flexeran

    Dan,

    To clarify my previous mention of UI related code in ISRT.dll: this isn't code that you have any control over when building your setup.inx. For example, there was a bug fixed that was present in InstallScript suite actions in IS 2013 that resulted from using CopyFile or XCopyFile in script. Internally, CopyFile and XCopyFile call into functions in ISRT.dll. The file copy wrappers in ISRT.dll were still attempting to (incorrectly) use the InstallScript progress object. Since that object is not available in InstallScript suite actions, the code caused a crash. The only way to resolve this behavior was to issue a code based fix for ISRT.dll.

    After further investigating the crash data you had posted a while back, something in ISRT.dll was crashing at offset 0x2268d. Unfortunately we don't have release symbols for ISRT.dll for versions of InstallShield prior to IS 2014 so I can't determine the exact code that is failing (it's hard to read pure assembly without any symbol information). However, since all calls into ISRT.dll are made through exported functions, looking through the disassembly of ISRT.dll for 2013 shows that the failing instruction is attempting to dereference a pointer. Based on the code and disassembly of that function, it would appear that the initialization of the InstallScript action is crashing in the ISRT.dll code that initializes some internal text substitution values. Specifically, it would appear that the null pointer dereference is actually to the global text substitution interface pointer.

    Attempting to determine what could cause this interface pointer to be null led to finding code that I had fixed for IS 2013 SP1 in ISRT.dll and ISSetup.dll that initializes path variables such as FOLDER_USER_PROGRAMS, FOLDER_USER_DESKTOP, FOLDER_USER_STARTUP, etc. This code, when released in 2013, could fail to initialize these user specific variables if the paths they are set to for a user in the registry does not exist on the file system (it's actually a Windows shell API that fails but this failure bubbles up to our code). Normally this isn't an issue. However, in IS 2013 due to other completely unrelated changes, this code can cause text substitution to fail during initialization, which results in the global and local text substitution interfaces being unavailable (null). In this suite action case, this is a problem because they assume the text substitution can't fail.

    The other thing that is might be factoring in here is the version of ISRT.dll listed in the crash info you had posted: 20.0.0.376. This is the version that shipped with IS 2013. The fix for the text substitution failures, included in IS 2013 SP1, has an ISRT.dll version of 20.0.0.496. As such it looks like you are building with the RTM version of 2013.

    Based on this information and some things you have previously discovered related to users on the machine, please take a look at this post I had made a couple of years ago after IS 2013 was released:
    Custom Actions fail with Error 3 on Wnidows Core OS

    Please see if you can determine if any of the user specific paths (and the common ones after that) mentioned in that post are missing in the user profiles where your suite installers are failing. If these paths are not present for some users but are for others, this may be the reason your installers are crashing in some scenarios.
    0 Kudos
    DLee65
    Level 13

    Josh,

    Thank you for the reply. I can double check on these systems where creating the new user fixes the problem.

    I am downloading Standalone Build 2013 SP1 and updating our build machines. I suspect that this is the biggest cause of the problem. I wonder if I had an earlier build machine that had SP1 but newer build machines used the RTM version.
    0 Kudos
    DLee65
    Level 13

    Josh,

    I am in the process of upgrading the Suite / Advanced UI package today.
    I have removed the support files as described in Upgrading Suite/Advanced UI Projects that Used InstallScript Actions to InstallShield 2014

    In my .rul file I had included some functions that were designed to limit the problems surrounding the UI issues. For instance I have a function for SdShowMsg which just returns ISERR_GEN_FAILURE.
    Another was added for OnLaunchAppAndWaitCallback().

    Are these items required for IS2015?
    If you have a moment, would you mind just giving a quick scan of the .rul file?

    Thank you.
    0 Kudos
    joshstechnij
    Level 10 Flexeran
    Level 10 Flexeran

    You can keep the script the same if you want and the behavior won't change (due to how InstallScript allows for overriding existing functionality that is in script).

    If you did want to clean up the script a little bit, the following can be removed:
    - Calling ISDeterminePlatform is no longer required to initialize SYSINFO, the engine now does this (LaunchAppAndWaitInitStartupInfo and ServiceInitParams are also now correctly called by the engine)
    - SdShowMsg can be removed since the use of the function internally is now conditioned out for suite actions
    - OnLaunchAppAndWaitCallback can also be removed as a default implementation is now provided

    These changes were made for IS 2014 so moving to 2015 shouldn't introduce any issues if this code was removed from your script. No other script facing changes have been made so you shouldn't see any other issues. All other changes have mostly been bug fixes internal to the InstallScript engine to fix some of the crashes mentioned before.
    0 Kudos