cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
DLee65
Pilgrim

Re: Suite error when executing InstallScript custom actions

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
Highlighted
DLee65
Pilgrim

Re: Suite error when executing InstallScript custom actions

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
Highlighted
Flexera joshstechnij
Flexera

Re: Suite error when executing InstallScript custom actions

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
Highlighted
DLee65
Pilgrim

Re: Suite error when executing InstallScript custom actions

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
Highlighted
Flexera joshstechnij
Flexera

Re: Suite error when executing InstallScript custom actions

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
Highlighted
DLee65
Pilgrim

Re: Suite error when executing InstallScript custom actions

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
Highlighted
DLee65
Pilgrim

Re: Suite error when executing InstallScript custom actions

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
Highlighted
Flexera joshstechnij
Flexera

Re: Suite error when executing InstallScript custom actions

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