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
- :
- Customers are getting .tmp access denied errors running Installshield 2013 installers
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
‎Jul 23, 2013
03:37 PM
Customers are getting .tmp access denied errors running Installshield 2013 installers
I just upgraded from 2012 Spring to 2013 Installshield Professional and after rebuilding 40 of my Windows installers that used to all work without any problems, a number of them are now generating "xxx.tmp" file error messages "Access is Denied" when running the newly rebuilt installers.
The xxx is random such as TitC7EE.tmp, Tit562.tmp, shiBA8C.tmp (these are from the error messages our customers are reporting). And we are seeing these errors occuring during testing the newly rebuild installers. Errors that never occured in any of our 300+ installers using previous versions of InstallShield.
I'm seriously concerned about the quality of the 2013 upgrade now, after I also just had to apply a patch to resolve another problem that the 2013 introduced that was a bug. Now that customers are reporting these errors we need an immediate resolution or will have to rollback to Installshield Spring 2012.
What is causing all of these .tmp file access denied errors when I run my installers under the 2013 build?
I'm running this on a Windows 7 - 64-bit OS, same one that I've been running Installshield on for years. So no system changes have been made, only the upgrade from InstallShield Spring 2012 to 2013.
The xxx is random such as TitC7EE.tmp, Tit562.tmp, shiBA8C.tmp (these are from the error messages our customers are reporting). And we are seeing these errors occuring during testing the newly rebuild installers. Errors that never occured in any of our 300+ installers using previous versions of InstallShield.
I'm seriously concerned about the quality of the 2013 upgrade now, after I also just had to apply a patch to resolve another problem that the 2013 introduced that was a bug. Now that customers are reporting these errors we need an immediate resolution or will have to rollback to Installshield Spring 2012.
What is causing all of these .tmp file access denied errors when I run my installers under the 2013 build?
I'm running this on a Windows 7 - 64-bit OS, same one that I've been running Installshield on for years. So no system changes have been made, only the upgrade from InstallShield Spring 2012 to 2013.
(6) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 24, 2013
08:05 AM
Do you have access to a system on which you can reproduce the problem? If so, I would suggest seeing what you can track down with Process Monitor and/or Process Explorer; for example, does something have the file locked? One common source of otherwise mysterious behavior is antivirus systems. They have the ability to deny access to or even remove files that should otherwise be fine. Thus even if you don't have direct access to a system, you might suggest trying the installation again with the antivirus software temporarily disabled.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 24, 2013
10:27 AM
These errors are on .tmp files that are not part of any files we have included in our installers. They appear to be temp files used by Installshield during the install process, and the problem is happening on multiple computers. Both our development computer and customers computers. So its not virus software related. When running the same product installers created using InstallShield 2012 Spring, these errors don't occur.
Its only since installing and rebuilding the installers in InstallShield 2013 vs 2012 Spring that the errors started occuring. The builds are all done from the same computer.
And the temp files are all located in folders that the installer has created on the system during the install process, so no other processes would have those files already locked or open.
Its only since installing and rebuilding the installers in InstallShield 2013 vs 2012 Spring that the errors started occuring. The builds are all done from the same computer.
And the temp files are all located in folders that the installer has created on the system during the install process, so no other processes would have those files already locked or open.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 24, 2013
05:58 PM
We also just tried rebuilding the installer that is failing on a clients computer in InstallShield 2012 Spring and the errors went away on the clients computer.
It appears that InstallShield 2013 is generating these .tmp files in the folders its creating and generating access denied errors.
We'll need a resolution pretty soon otherwise we'll have to rollback to using InstallShield 2012 Spring until the 2013 version is stable.
It appears that InstallShield 2013 is generating these .tmp files in the folders its creating and generating access denied errors.
We'll need a resolution pretty soon otherwise we'll have to rollback to using InstallShield 2012 Spring until the 2013 version is stable.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 25, 2013
08:05 AM
On the development machines where you can see this behavior, do you have any low-level programs running? Low-level can include anti-virus, backup, source control, or others -- essentially anything that might hook in at the filesystem level and examine new files such as the temp files InstallShield has to create. I can almost guarantee that InstallShield 2012 Spring generated the same kind of temp files; my hunch is that something is treating them differently, perhaps because it doesn't detect installations created with InstallShield 2013 the same way it detects those created with InstallShield 2012 Spring. But since I cannot reproduce this behavior with the sparse information provided in this thread, I cannot help further at this time.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 25, 2013
08:35 AM
Perhaps you can open TeamViewer session to see the bug live?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 03, 2014
08:55 AM
Did you ever get to the bottom of this? Does InstallShield 2013 work differently to previous versions on how it extracts files?
We have the same issue with F-Secure Antivirus - it sees some of the ".tmp" files and blocks them with Access Denied. What InstallShield appears to be doing when it extracts/installs files is first give them a temporary name ending in .tmp and then renames them to the real name - is that correct and if so has this behaviour changed?
We have the same issue with F-Secure Antivirus - it sees some of the ".tmp" files and blocks them with Access Denied. What InstallShield appears to be doing when it extracts/installs files is first give them a temporary name ending in .tmp and then renames them to the real name - is that correct and if so has this behaviour changed?
