PDA

View Full Version : 5044 and 1014 errors on second build



Tony Patterson
06-01-2004, 10:25 PM
Hi,

I am getting these errors and they are quite fustrating. I create a new installer project adding a single exe and then build the project. If I then build it again straight away i get a 5044 error complaining about the realease.bak folder. On another attempt I get both the above errors.

I have followed the instructions in the kb articles dealing with these, but IS X is turning one of the folders into something strange.. like a folder but not a folder. If I check the properties it hads no security tab and no created or modified date. It cannot be deleted by any means even rmdir through dos. I now have 5 or 6 of these folders.

Any ideas?

Cheers
Tony

davidh
06-02-2004, 11:43 AM
I have seen cases where the build locks a folder (or perhaps it is another application, virus scanner, etc) and you have to close the InstallShield IDE, or in the worst case, reboot, so the folder is unlocked. However, I have never been able to reproduce this or narrow this down enough to try to track down and fix this bug. In my experience, I very rarely see this issue.

Can you try building with a different file? Can you try building to a different folder? Do you still get the 5044 error in each case? If this is specific to your file, maybe we can get a copy of the file at InstallShield so we can try to reproduce and fix this issue.

Tony Patterson
06-02-2004, 04:33 PM
Thanks for your reply David,

I initially thought it was because I was building the release on a network drive, but when I switched to a local release folder I get the same issues.

The file is just a simple vb exe with a button on it, I was trying to test patching. I can either send you the file or the whole project whatever is good for you.

Cheers
Tony

davidh
06-02-2004, 04:57 PM
I'm not very confident that I will be able to reproduce, but I will definitely give it a try. If the file is under 4 MB, please zip the exe file and send it to davidh@installshield.com. Also, please rename the file (eg: rename test.zip to test.ren).

davidh
06-17-2004, 04:33 PM
Thank-you for your feedback. I was not able to reproduce this issue, but I brought up the issue with product management. This issue has been assigned work order# 1-Q5DW8 and will be under consideration to be fixed in a future release of InstallShield.

In the majority of cases this issue should be resolved by following the kb article for the 5044 error. Otherwise you could try using the Releases view or the Release wizard to build to a different folder.

rogc742
08-05-2004, 02:59 PM
I'm getting similar errors when I try to rebuild a project. The problem is that the package files in the ~.BAK directory are in some funky state. You can't delete them, rename them, etc. I'm logged on as an administrator and can't do anything with them. Tried using AT to delete them and it could get to them. Have also rebooted the box and still no go. Nothing else is open to lock the files. I'd really like to see a fix or workaround for this problem.
Thanks,
Rog

rogc742
08-05-2004, 03:46 PM
I found that the path to the product files must have exceeded the MAX_PATH value. See Microsoft article 320081 for solutions to this. The solution was to share a folder down in the tree and rename some of the directories with long names.
Roger

lolotimo
08-06-2004, 03:09 PM
I went through the same problem, but in my case what happened is that I did the build the first time, and then tried the installation setup program and it failed, then I tried to rebuild it again, and got the error.
I checked my Processes and found out the previous failed setup process is still running, killed it and everything went fine.

This might be the case with you.

Good luck.

rogc742
08-07-2004, 01:12 PM
lolotimo,

No, I've experienced the problem you mention as well and found the same resolution. If all else failed, a reboot would clear the problem. I think if you check Task Manager you'll find a iDriver.exe is running which locks the directory. Closing the inprogress install or as a last resort, killing iDriver seems to clear that. Also, if you're editing a file in the directory external to the IS IDE, you'll also see the problem.

This new problem occurred because in addition to storing the IS project under C:\documents and settings..., IS took our full company name and the full product name as part of the directory path. Till all was done, I had a verrrrry long path. Cropping it, corrected the problem.

Roger

bflaherty
04-27-2005, 03:04 PM
This is horrible. The KB article was no help to solve this 5044 error. Does anyone at installshield have a clue as to why this is happening? Or what I can do to not see this error? So far the only solution that i see is to not use installshield.

This product is useless if I can't get an answer.

B

MikeMouncey
04-27-2005, 04:32 PM
ISDEV : fatal error -1013: File C:\Program Files\InstallShield\DevStudio 9\Support\_IsIcoRes.Exe is being used by another program.

I run automated builds and when I try to run iscmdbld.exe -p with two builds going at the same time one build fails with the above error. I am extremely frustrated with this. Is IsIcoRes.exe not copied to a temp build folder during a build. I cant understand why it is locked. This is a big problem for those of use doing AutoBuilds. Can someone at InstallShield please give us a work around or a patch. If this cant be done, Unfortunetly we may have to look at another install package. I have 3 large licenses and renew every year faithfully. I would hate to have to research a new product to meet our needs.

Thanks,

Michael Mouncey
403-295-5248
mike.mouncey@gdcanada.com

yuhaian
11-21-2005, 03:18 PM
"two builds going at the same time" may caused problem on this situation. Try to seprate them.

Kent Marsh
12-07-2005, 03:42 PM
Delete the PROJECT_ASSISTANT folder and then run the build again.
All of the files in that folder are recreated when the build is run.

woter324
12-20-2005, 08:42 AM
Don't know what the knowledge base says, so appologies if I'm repeating it but the main reason is that the msiexec.exe process is still running. If you immediatly perform a build after ending another one, the msiexec.exe process hasn't had time to finish.

You can kill the msiexec.exe process under task manager.

If you turn on logging under Build-->Settings-->MSI Log, then watch the output file with a text program that automatically updates the file when changes are made (e.g. textpad) you will be able to see what happens when you finish or cancel the installer.

It often takes quite a while for the installer to finish. ~< 1 minute

Occasionaly IS gets its knickers in a twist and thinks the build folder is open when it actually isn't. Normally restarting IS sorts this, but sometimes, you will need to perform a resart of the machine or log off and on.

Hopefully Macrovision will one day sort this, also allowing the build folder to be open during a build. It is a pain and is the most frequent error I get.

Hope this helps

Woter

scorp1us
12-22-2005, 01:28 PM
Here's the deal folks. This is a design issue with install shield (IMHO). The build process tries to delete/move the folders and subfolders. This isn't ideal if they already exist. The proper behavior for install shield should be: delete the individual files and only new directories created if needed.

The problem comes from how Windows works coupled with this errant behavior. If there is any local explorer.exe instance viewing any of the folders that need to be moved/deleted, the operation will fail (even if it is just sitting there). Also, any other software running within the directory will cause the build to fail.

If the build process were to remove files it would only error if files are actually in use. If it really needs to delete/rename a directory, it could make a new folder and leave the old one, and report that the old one needs to be manually deleted.

MSDev studio just replaces files, and makes dirs as needed which is why you don't see this when compiling a program. I can understand macromedia trying to do a clean build every time, so that extraneous files are not included, but the way it currently works does not work well when you are rebuilding.

brunzefb
02-28-2006, 02:15 PM
Hi,

I was just plagued with this -5044 error, and solved it by resetting the TEMP environment variable for the local user to C:\temp. (System Control Panel applet). Hope this helps someone out there.

Friedrich

CesareoContrera
03-15-2006, 07:10 PM
Was any of you using ClearCase Dynamic views when this error occured?
I only get this error the second time I build or when using merged modules in a clearcase dynamic view environment.

Tom Sanders
03-29-2006, 10:10 AM
In my case it was the Index service which was conflicting with Installshield. Stopping the service fixed the problem for me...

I noticed that cisvc.exe had a file lock on the .bak folder... this is the index service. I currently have it completly disabled and since then i have been error free :)

joshiew
10-06-2006, 04:37 PM
I have read through the news list and did what others suggested, but no hope.

I found this happens particularly on Windows 2003 Server. I have built the same project using InstallShield 12 on Windows 2000 server and had no problem, but when I move the project to Windows 2003 server, the problem starts to show up.

It seems like InstallShield is locking the folder. After I closed the InstallShield IDE, I can delete or rename the Release folder, but not when the IDE is active.

Any inside information?

Thanks,

Joshie

Aflaat
01-17-2007, 10:24 AM
I'm hitting the same issue, only on 2003. Windows XP was fine. It is not fixed in Installshield 11 either.

The only process locking the file is isdev.exe, so it is an IS error.

Saranya Sekar
07-25-2007, 01:59 AM
In my case it was the Index service which was conflicting with Installshield. Stopping the service fixed the problem for me...

I noticed that cisvc.exe had a file lock on the .bak folder... this is the index service. I currently have it completly disabled and since then i have been error free :)

hi i had the same problem and killing cisvc.exe solved it...:) thank u