This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Need inputs
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 25, 2010
03:15 PM
Problem upgrading 64-bit installation: Error 2324
Hi,
We are having problems upgrading our 64-bit installations. As soon as the spash screen has appeared we get:
Error 2324.Could not open file: C:\WINDOWS\system32\{filename}.dll GetLastError: 2.
As has as I can see, it is identical to the InstallShield 12 problem described in
http://community.flexerasoftware.com/showthread.php?t=173007
Anyone who can shed some light?
We are having problems upgrading our 64-bit installations. As soon as the spash screen has appeared we get:
Error 2324.Could not open file: C:\WINDOWS\system32\{filename}.dll GetLastError: 2.
As has as I can see, it is identical to the InstallShield 12 problem described in
http://community.flexerasoftware.com/showthread.php?t=173007
Anyone who can shed some light?
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 26, 2010
04:22 PM
This can happen if the 32-bit version of msiexec.exe is used to launch the MSI package, and the package had installed files to the 64-bit System32 folder.
We added some checks in the IS 2010 setup.exe to determine if the MSI to be launched is 64-bit (Template Summary in the Summary Information Stream is marked Intel64 or x64). If this is the case, and the package is being launched on a 64-bit machine, then we will used the 64-bit version of msiexec.exe to launch the MSI package.
Is this behavior occurring on any 64-bit machine that you test the upgrade on, or only some? Can you log the setup.exe (setup.exe /debuglog) and attach the log to this thread?
We added some checks in the IS 2010 setup.exe to determine if the MSI to be launched is 64-bit (Template Summary in the Summary Information Stream is marked Intel64 or x64). If this is the case, and the package is being launched on a 64-bit machine, then we will used the 64-bit version of msiexec.exe to launch the MSI package.
Is this behavior occurring on any 64-bit machine that you test the upgrade on, or only some? Can you log the setup.exe (setup.exe /debuglog) and attach the log to this thread?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 08, 2010
03:46 AM
Hi,
Sorry for the immense delay. Had to release the product which will cause the described upgrade problem when it in turn will be upgraded later on.
The problem occurs before there is any user interaction.
I've tried to extract the log file. Can't say I saw anything useful in it, so I made an msi dito as well. Both attached.
Thanks for any info
Sorry for the immense delay. Had to release the product which will cause the described upgrade problem when it in turn will be upgraded later on.
The problem occurs before there is any user interaction.
I've tried to extract the log file. Can't say I saw anything useful in it, so I made an msi dito as well. Both attached.
Thanks for any info
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 12, 2010
03:37 AM
And we've seen this on all tests so far (though only a handful). On Windows XP Professional x64, Windows 7 Ultimate x64 and Windows Server 2008 R2.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 12, 2010
06:07 PM
This is the same issue described in this thread regarding InstallScript MSI projects.
As a possible workaround to this behavior, you may try using a custom action in the UI and execute sequence (sequenced before CostFinalize in both sequences, conditioned on "Installed") to set SystemFolder, System64Folder, ProgramFilesFolder, ProgramFiles64Folder, CommonFilesFolder, and CommonFiles64Folder to their expected paths. Note that since these are private properties, and these particular properties are unique, this workaround may not resolve the behavior you are seeing. In this case, the workarounds mentioned in the other thread are recommended.
As a possible workaround to this behavior, you may try using a custom action in the UI and execute sequence (sequenced before CostFinalize in both sequences, conditioned on "Installed") to set SystemFolder, System64Folder, ProgramFilesFolder, ProgramFiles64Folder, CommonFilesFolder, and CommonFiles64Folder to their expected paths. Note that since these are private properties, and these particular properties are unique, this workaround may not resolve the behavior you are seeing. In this case, the workarounds mentioned in the other thread are recommended.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 22, 2010
11:44 PM
I am using InstallShield 2008 Premier edition for my installer development activities.
My project is basic msi with setup.exe being generated.
A previous version of the product (version 1)was built using this version of InstallShield. This product targetted the 64 bit Itanium windows servers(IA 64). In version1 , i had added a component with its target directory being set to SYSTEM64 folder(\system32).
I had marked the file within the component as a key file. Now for the next version of the prodcut we plan to do a minor upgrade. Hence the version was upgraded(version 2).
However when i attemp to upgrade to the latest version, i get the following error:
Error 2324: Could not open file C:\windows\system32\ GetLastError :2
A error code of 2 indicates that the file could not be found. However the file does exist in the system32 directory. If i were to copy the file to C:\Windows\SysWow64 directory, the install goes through.
I did some research on the web and came across the following links:
http://community.flexerasoftware.com...d.php?t=193508
In the above link, one of InstallShield engineers states that this problem occurs if if the 32-bit version of msiexec.exe is used to launch the MSI package, and the package had installed files to the 64-bit System32 folder.In InstallShield 2008, it seems that setup.exe launches a 32 bit msiexec process to run the installation. This seems to have been fixed in IS 2010.
Questions:
1)As per Flexera software, setup.exe built using InstallShield 2008 launches a 32 bit msiexec process even on a 64 bit server. When the observe the same in task manager on an Itanium server, i see two new instances of 32 bit msiexec launched. They appear as msiexec*32. However if the same process Id as got from task manager is observed in Process explorer(Sysinternals), it is pointing to the 64 bit msiexec under C:\windows\system32.
How can this be? Please explain.
2)What is the best way to get around this issue?
I dont want to build my own custom wrapper. This is ruled out.
Kindly help as i am running against time to fix this
My project is basic msi with setup.exe being generated.
A previous version of the product (version 1)was built using this version of InstallShield. This product targetted the 64 bit Itanium windows servers(IA 64). In version1 , i had added a component with its target directory being set to SYSTEM64 folder(
I had marked the file within the component as a key file. Now for the next version of the prodcut we plan to do a minor upgrade. Hence the version was upgraded(version 2).
However when i attemp to upgrade to the latest version, i get the following error:
Error 2324: Could not open file C:\windows\system32\
A error code of 2 indicates that the file could not be found. However the file does exist in the system32 directory. If i were to copy the file to C:\Windows\SysWow64 directory, the install goes through.
I did some research on the web and came across the following links:
http://community.flexerasoftware.com...d.php?t=193508
In the above link, one of InstallShield engineers states that this problem occurs if if the 32-bit version of msiexec.exe is used to launch the MSI package, and the package had installed files to the 64-bit System32 folder.In InstallShield 2008, it seems that setup.exe launches a 32 bit msiexec process to run the installation. This seems to have been fixed in IS 2010.
Questions:
1)As per Flexera software, setup.exe built using InstallShield 2008 launches a 32 bit msiexec process even on a 64 bit server. When the observe the same in task manager on an Itanium server, i see two new instances of 32 bit msiexec launched. They appear as msiexec*32. However if the same process Id as got from task manager is observed in Process explorer(Sysinternals), it is pointing to the 64 bit msiexec under C:\windows\system32.
How can this be? Please explain.
2)What is the best way to get around this issue?
I dont want to build my own custom wrapper. This is ruled out.
Kindly help as i am running against time to fix this
