daniel.lee.me1.5524909031803118E12 asked a question.
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.
What version is \mshtml.dll?
Rob
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'?
You may not uninstall mshtml.dll; it's used by a bunch of applications.
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.
.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
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.
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 "
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]
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.
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.