none
socket() fails with error 10022 when application is run from certain network shares on Vista and Windows 7 (works on XP)

    Question

  • Hi,

    We've run into a strange problem where our network application runs fine from most network shares, but fails on a particular one. 

    The socket() function returns an 10022 (WSAEINVAL) error when this occurs.  It runs fine locally and on most network shares.

    Here's a sample program that causes the error:

    #include "stdafx.h"
    #include <windows.h>
    #include <winsock.h>
    #include <stdio.h>

    int _tmain(int argc, _TCHAR* argv[])
    {

        WSADATA wsadata;
        //request socket version 2.2
        WORD vers = MAKEWORD (2, 2);
        int ret, sock;

        //initialize windows sockets
        ret = WSAStartup (vers, &wsadata);
        if (ret)
        {
            fprintf (stderr, "WSAStartup failed: rc: %d\n", ret);   
            fprintf (stderr, "err: %lu\n", WSAGetLastError());
            return 1;
        }
        else
        {
            printf("WSAStartup succeeded...\n");
        }


        printf("WSA Information:\n");
        printf("high ver: %d.%d ver: %d.%d\n",
            HIBYTE(wsadata.wHighVersion),
            LOBYTE(wsadata.wHighVersion),
            HIBYTE(wsadata.wVersion),
            LOBYTE(wsadata.wVersion));
        printf("desc: %s\n", wsadata.szDescription);
        printf("stat: %s\n", wsadata.szSystemStatus);
        printf("max sock: %d max udp size: %d\n", wsadata.iMaxSockets, wsadata.iMaxUdpDg);

        //create a simple socket
        sock = socket (AF_INET, SOCK_STREAM, 0);
        if (sock == INVALID_SOCKET)
        {
            int iErr = WSAGetLastError();
            LPVOID lpMsgBuf;
             FormatMessage(
                FORMAT_MESSAGE_ALLOCATE_BUFFER |
                FORMAT_MESSAGE_FROM_SYSTEM |
                FORMAT_MESSAGE_IGNORE_INSERTS,
                NULL,
                iErr,
                MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
                (LPTSTR) &lpMsgBuf,
                0, NULL );


            
            fprintf (stderr, "socket failed: err: %lu\n %s\n", iErr, lpMsgBuf);

            LocalFree(lpMsgBuf);
        }
        else
        {
            fprintf (stderr, "socket succeeded: %d\n", sock);
            closesocket (sock);
        }
        WSACleanup ();
        return 0;
    }

     

    When run locally or on most shares you get success:

    C:\Users\test\Desktop>SocketTest.exe

    WSAStartup succeeded...

    WSA Information:

    high ver: 2.2 ver: 2.2

    desc: WinSock 2.0

    stat: Running

    max sock: 0 max udp size: 0

    socket succeeded : 68

     

    When run from a certain network share:  (Q: is a mapped share, SocketTest.exe is located on the share)

    Q:\VISTA_trials>SocketTest.exe

    WSAStartup succeeded...

    WSA Information:

    high ver: 2.2 ver: 2.2

    desc: WinSock 2.0

    stat: Running

    max sock: 0 max udp size: 0

    socket failed : err: 10022

     An invalid argument was supplied.

     

    Since it works on most shares and locally, it makes me think it is some kind of security problem.  It fails the same way when run with Administrator permissions.  It reminds me of the .NET application running from a share permissions.  I didn't see anything suspicious with process monitor.  Unfortunately, I couldn't step into the socket() function to see exactly where it fails.  I'm going to install a checked build of Vista to see if that helps.  Any idea on how to proceed / fix this problem?  This looks like the same problem posted here: http://www.ureader.com/msg/14772558.aspx

     

    Thanks,

    Ben

    Wednesday, September 22, 2010 4:22 PM

Answers

  • Success!  We managed to figure out the problem.  It has to do with users not having read access at higher level directories.

    Here's an example:

    User is running Vista / Windows 7

    The shares are set up like this:

     

    \\server\share

    \\server\share\subfolder

    \\server\share\subfolder\sample.exe

     

    User has no permissions on \\server\share

    User has read permissions on \\server\share\subfolder

    User can map \\server\share\subfolder

     

    User tries to run executable that uses sockets \\server\share\subfolder\sample.exe

    socket() fails with error 10022

     

    Granting the user read access on \\server\share resolves the problem.  However, it is still a Windows bug.  It shouldn't matter where else the user has permissions, as long as they have correct permissions on the executable location.

     

    Ben

    • Marked as answer by Rukh13 Tuesday, November 9, 2010 7:27 PM
    Tuesday, November 9, 2010 7:25 PM

All replies

  • I'll clarify the problem a little bit more and provide some more information that I've obtained. 

    First, this problem is with all "network" applications run from the problem share.  It has to do with the location of the .exe, not the supporting libraries.  The problem was first discovered when user's Oracle based applications (on Vista) running off of the share could not connect to the database.  Other network applications like wget, filezilla client, and putty fail also.  I've simplified the problem to this test application.

    Another microsoft moderator pointed out that the call to socket should be:

    sock = socket (AF_INET, SOCK_STREAM, IPPROTO_TCP);

    After changing the call to this, the problem still occurs.  This is expected because the application runs fine on the local machine or on other shares.

    Anyways, I installed a checked build of Vista and started tracing the calls, and found out where it fails and where the invalid argument error occurs.

    Here's the "call stack"

    socket()

        WSPSocket()

             SockSocket()

    The function call that fails is NtCreateFile.  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.

    The share is using DFS, if that makes any difference.  What can I do to figure out this problem?  Thanks,

     

    Ben

     

     

     

     

     

    Friday, September 24, 2010 7:12 PM
  • Hi Ben,

    we have exactly the same problem over here in our lab. We have been stuck with this for nearly two days. No solution in sight :-(

    If you find out anything please keep us informed. We will also post a solution if we find one.

    Best regards

    Eckhart

    Friday, October 8, 2010 8:52 AM
  • Success!  We managed to figure out the problem.  It has to do with users not having read access at higher level directories.

    Here's an example:

    User is running Vista / Windows 7

    The shares are set up like this:

     

    \\server\share

    \\server\share\subfolder

    \\server\share\subfolder\sample.exe

     

    User has no permissions on \\server\share

    User has read permissions on \\server\share\subfolder

    User can map \\server\share\subfolder

     

    User tries to run executable that uses sockets \\server\share\subfolder\sample.exe

    socket() fails with error 10022

     

    Granting the user read access on \\server\share resolves the problem.  However, it is still a Windows bug.  It shouldn't matter where else the user has permissions, as long as they have correct permissions on the executable location.

     

    Ben

    • Marked as answer by Rukh13 Tuesday, November 9, 2010 7:27 PM
    Tuesday, November 9, 2010 7:25 PM
  • As this is a Microsoft site, does that mean there is someone from Microsoft listening who can let us know whether they are going to fix this problem or not.

    Is it a "Security feature"? Is it a known issue? Is it going to be fixed?

    Friday, February 18, 2011 12:53 PM
  • Has ANYONE got an answer for this:-

    I use this bulk email program on my DESKTOP which uses Windows 7 and Microsoft Office 2007. BUT this month EVERYTHING bombed out on my desktop and I still have not been able to send messages out on my DESKTOP.

    BUT stangely enough EVERYTHING works on my LAPTOP - why the difference ??????

    My supplier CANNOT solve the issue and sent me this anser .

    The above forums also cannot rectify the problem !

     

    Hi Andy.

     

    There were a couple of strange things going on with your PC that I noticed such as trying to access the log brought up a Word Document with some network card related information which I've never seen before, it should have opened the send log file instead.

     

    The other thing was that I couldn't add a user to give permissions to a folder or file.  I wanted to test giving the "everyone" user, full permissions to the C:\Program Files\GroupMail 5\ folder and also C:\Users\<YOUR USER PROFILE>\AppData\Local\Infacta

    However there was no option to add a user on your Windows system which was strange?  There's definitely something with your desktop PC but unfortunately don't know what.

    It was actually a support query on Microsoft Website that pointed me to a potential permissions issue and it's like the GroupMail Deliver Console is being blocked by something from sending.

    http://social.msdn.microsoft.com/Forums/en/wsk/thread/3076a9cd-57a0-418d-8de1-07adc3b486bb

     

    I'm give you a link below so you can download the latest release of GroupMail 5 Personal Edition as this is what you are licensed for.  You can keep that install file safe and use it again any time you need.

     

    http://dl.filekicker.com/pd/0/e235917ced/3/1a4b14ac/158987-0488/111006130104/gm5p_setup.exe 

     

     

    Best regards,

    Paul

     

    * Infacta - eMarketing Solutions

    * http://www.infacta.com


    • Edited by laskajack Wednesday, October 5, 2011 8:51 AM
    Wednesday, October 5, 2011 8:46 AM
  • Please see the following:

    Winsock-based operations fail in Windows 7 or in Windows Server 2008 R2 if the executable file is located on an NFS share
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;2649107

    Tuesday, January 22, 2013 5:18 PM
  • Wow a hot fix after 2 years and 4 months. I doubt it's a record.

    Makes me glad that I not using windows anymore.

    Tuesday, January 22, 2013 5:30 PM
  • FINALY I got the fix for this problem.

    After investigating several days with Microsoft, they complained that's not a bug, it's by design.

    This issue occurs because of a change in the behavior of Windows Filtering Platform (WFP) that was implemented in Windows 7 and in Windows Server 2008 R2

    That was not a proper answer for me, that's why we escalated it over HP support.
    They found a fix:

    You can turn of this new behavior by editing the registry.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\FltMgr
    add this entry
    Name: UseTildeShortcut(DWORD)
    Data: 1

    You have to add this entry on the client machine.

    • Proposed as answer by nibbler2 Thursday, February 6, 2014 8:34 PM
    Thursday, July 4, 2013 11:15 AM