Hello, We have an issue with file permissions. If we have a path like N:\applications\myapp\app.exe where N: is some network drive and the user cannot list N:\applications (becuase we want to keep the list of applications private), but can execute app.exe, the application can start, but if if attempts to make a network connection it fails. This used to work fine in Windows XP, but is failing with Windows 7, and precluding our migration. Why? What policy could we use?

This is exactly the same problem we are having

Hi, Thanks for posting in Microsoft TechNet Forum. What is the result when you granted the user read access on \\ N:\applications? Have you resolved this issue? Alex Zhao TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

If we grant read access to the directory, then applications work. But this solution is not acceptable for us. The information that we manage is quite confidential. Users should know nothing about the names of available applications, except those that they are authorized to use.

Hello ti2009, Thank you for your update. I am currently looking into this issue and will give you an update as soon as possible. Thank you for your understanding and support. Alex Zhao TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Thanks, we look forward having a solution to this problem.

Is there any progress about this issue? Is it a bug? A confirmed feature?

Are there any news?

Hello, The application here is running in the context of the user as far as I can understand from the prefious information. I do not know why it was working in XP. There are security differences between XP and Windows 7 that may be preventing the application from accessing data on a network location that it cannot read. There may be something coded within the application that is incompatible with the security features of Windows 7. At this point I would recommend opening a support case with Microsoft. If you are a premier customer I would do this through your TAM. If not I use the following link - http://support.microsoft.com/?Open&src=hot&docid=2003082012355706&nsf=nav.nsf&view=docid&seg=hho&lg=en&ct=us?Open&src=hot&docid=2003082012355706&nsf=nav.nsf&view=docid&seg=hho&lg=en&ct=us

This issue can be reproduced with any application that opens a network connection, like netcat. Just place netcat in a network folder with execute permission, but without read permission. Netcat executes, it can show help, but if it attempts to connect, that connection fails. In a previous post, I added a link to a simple example, with a lot of troubleshooting information. It appears that when an application opens a socket, the file \Device\Afd\Endpoint is accessed: The file it is trying to open is "\Device\Afd\Endpoint" It returns an error code of 0xC000225 (Status Not Found). The IoStatusBlock.Information value is 0x1 (FILE_OPENED) after the call. So where does our mysterious error 10022 come from? When NtCreateFile fails, there's another call to NtStatusToSocketError with 0xC000225 as the argument. This function is the one that returns 10022 (WSAEINVAL - Invalid Argument), and in the debugger window there's an error string 0x508-MSWSOCK> NtStatusToSocketError: unable to map 0xC0000225, returning So, it seems to me that our process when run from this share doesn't have the correct permissions to open/create \Device\Afd\Endpoint" when running from the problem network share. I'm running as Administrator with UAC disabled, so there shouldn't be any issues there.

Hello, Are there any news about this issue?

Any news? We are still waiting?

Hello, we need a solution to this issue. It is not normal to have a behaviour not explained by the documentation, clearly a bug, as explained above, and getting a complete silence as answer. This behaviour is not serious at all. One cannot pretent that this is a company that we can depend on, a company that does not even bother say if this is a bug.

We are still waiting for a solution.

We are still waiting for a solution

maybe some silly recommendations : - try with a "working directory" not in N:\...but something else ? - try to change search dll path behavior , may be it is related to the new "CWDIllegalInDllSearch" : http://support.microsoft.com/kb/2264107/en-us Hope this help jean-marc habyjean-marc Haby

Sorry Jean-Marc , but this does not work. I am trying with a working directory %USERPROFILE%. Any application that starts a network connection starts, but fails just before a network operation. I have copied nc.exe (netcat) to a share that cannot read as normal user, and when executing it c:\> N:\applications\myapp\nc.exe www.google.com 80 Can't get socket: INVAL nc.exe only uses system shared libraries.