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

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
Pilgrim

Update Windows error 80070643

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

Re: Suite error when executing InstallScript custom actions

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
Pilgrim

Re: Suite error when executing InstallScript custom actions

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
Pilgrim

Re: Suite error when executing InstallScript custom actions

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
Pilgrim

Re: Suite error when executing InstallScript custom actions

.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
Pilgrim

Re: Suite error when executing InstallScript custom actions

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
Pilgrim

Re: Suite error when executing InstallScript custom actions

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
Pilgrim

Re: Suite error when executing InstallScript custom actions

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
Pilgrim

SOLVED?! User rights issue

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