permission denied for some users

[hannahse]

I have a Fortranapplication that I maintain and it has a fairly wide user base in my company. I have a 64bit exe I compiled on XP64 and on W7 using the 9.1 compiler. The application is normally run from a cygwin prompt that accesses the exe on a server.

Problems started arising a few weeks ago when I made a very minor change to the code and put a new exe on the server. Although some users have no trouble, others get a "permission denied" error which persists even if they copy the exe to their local drive and manually change permissions. I then found out that the previous version, that had worked for everyone, exhibited the same seemingly random problem after I recompiled it.

Using the same source code and same compilation scripts on a "lab" computer produced an exe that everyone can use. The lab machine had the same compiler.

I can't use the lab machine for routine work so I need to figure out how to make exe produced on either my W7 or my XP64 produce exe files usable by everyone - or figure out what is the difference in users' machines that let some execute but not others.

My gut tells me this is somehow related to Intel runtime dll but don't know how to verify. The dll files tend to be in multiple directories with multiple versions.

Any ideas on how to trackdown the cause of these issues? All users have xp64.

I did try combining the manifest file into the exe using the mt.exe but that did not help.

[Steven_L_Intel1]

What is the exact and complete text of the error? Does Dependency Walker show any issues?

[hannahse]

./rtest: line 1: v:/path/app_wxp64.9.3.exe: Permission denied

where
rtest is the name of a one line script pointing to the exe file
path was a more detailed path

I'm not familiar with the dependency walker.

I had one of the "problem" users double-click the exe file from windows explorer. This is a little used but acceptable method of running the exe. The windows error was "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."

I don't have an install process except to copy the exe to the server.

[Steven_L_Intel1]

Please download Dependency Walker, unpack it to a folder, run it and open your EXE with it. Select File > Save and save a .dwi file. Attach that to a reply here.

[hannahse]

Unbelievable. I have been struggling with this for weeks now and trying to get internal help. The day I come to this forum, I finally get it. Problem solved. The problem is in the manifest files produced. My machine's version referenced two different versions of VC80.crt while the lab version only referenced one and that one was common to both.

So, if I use the manifest file with only one reference along with the exe file produced on either machine, I get an app that works for everyone (so far).

Of course, there seems to be a problem with our distribution system not assuring that we all have the same dll but that's a whole nother ball game.

Thank's for the quick responses.

[Steven_L_Intel1]

That's what we're here for!

If you don't have just the right "shared assembly" on the target system, the effects can be bizarre at times. I'm not entirely sure what you mean by the manifest having two versions - I have not seen that - but I would have recommended installing the appropriate Visual C++ Redistributables installer on the target system - this provides (usually!) all the various versions you may need.

[hannahse]

Thanks. I will pass the installer info along to those who can influence that process. Below is an excerpt of the manifest file to show the 2 different versions referenced. The rest of the file is just XML.

xml deleted



xml deleted



xml deleted

[mecej4]

Perhaps this finding reinforces the adage that the cure (manifests) can be worse than the disease (DLL hell).

Unfortunately, while the placebo (jiggling the version number in the manifest file) worked here, it is no panacea and caution is advised.