Will not be able to (successfully) dynamically link to RASAPI32.DLL without Admin privileges RRS feed

  • Question

  • Hi all,

    While investigating application compatibility issues for a legacy app running under Windows 7, primarily using Standard User Analyzer, I've noticed that dynamically linking to RASAPI32.DLL is going to require an elevated app, since there are admin-only objects created by the DLL.

    We rarely use dial-up in the app, but I do need to find a non-admin-level alternative method of opening a dial-up connection if possible.

    Does anyone know if there is a programmatic, standard-user-capable way of launching a dial-up connection under Windows 7?

    Many thanks for any advice,

    Thursday, November 12, 2009 1:27 PM

All replies

  • Hi Graham,

    Thanks for the post.

    Any task involving registry operations will require the admin rights. Since Registry, C:\Program Files, C:\Windows all comes under WRP (Windows Resource Protection) category, any operation involving these will require administrator rights to work; else they will keep on showing UAC prompt. So, you get the admin rights and work on it.

    Hope this helps.


    • Proposed as answer by Sharma Anuj Friday, November 20, 2009 5:17 AM
    • Unproposed as answer by Graham Thompson Tuesday, December 1, 2009 2:05 PM
    Friday, November 20, 2009 5:17 AM
  • Hi Anuj,

    Thanks for your reply.

    I appreciate what you're saying about WRP, and I've worked on application compatibility for some time now and have a good understanding of which objects, namespaces etc. I have access to as a Standard User - my problem is that simply linking to the RASAPI32.DLL (using LoadLibrary with a named DLL), and thus causing it to load, will fail as a Standard User since that DLL creates admin-restricted resources when it is loaded. I only need to initiate a dial-up connection, not change any settings, so I was hoping to find an 'approved' method for initiating such a connection, in code, as a Standard User.

    Surely Standard Users can initiate dial-up connections without having to elevate the process?

    Thanks again for your assistance,

    • Edited by Graham Thompson Monday, November 23, 2009 5:23 PM Clarification
    Monday, November 23, 2009 5:21 PM
  • Hi,

    Please let us know the program name. Where you receive the RASAPI32.DLL error.

    You can try running the program in compatible mode. If it still does not work, you may need to create a administrator account or contact the system administrator:

    Run program under compatibility mode & Administrator level
    1. Right click on the program icon and click Properties.
    2. Click on the Compatibility tab.
    3. Select “Run this program in compatibility mode for.”
    4. Choose Windows Vista (Service Pack 2) from the drop down list.
    5. Select “Run this program as an administrator” option under the Privilege Level topic.
    6. Click Apply, click OK.
    Try to run it again.

    Vivian Xing - MSFT
    • Marked as answer by Vivian Xing Tuesday, November 24, 2009 7:51 AM
    • Unmarked as answer by Graham Thompson Tuesday, December 1, 2009 2:04 PM
    Tuesday, November 24, 2009 7:49 AM
  • Hi Vivian,

    Thanks for your reply.

    The error is actually reported by Standard User Analyzer (5.5.6762.1798) running my legacy app (unelevated). I'm using SUA to detect and address any application compatibility issues prior to supporting installation on a Windows 7 platform, and the only 'error' indications SUA shows up are on behalf of RASAPI32.DLL. I believe my legacy app does not require administrator privileges, and this is the only compatibility 'issue' I have remaining.

    The first error is thrown during a call to LoadLibrary for RASAPI32.DLL - SUA reports 'The application was denied access to an object', and the detail is 'CreateMutexA: Mutex (RasPbFile) is denied '' access with error 0x5.', and the stack trace is as follows:

    vfluapriv2!NS_LuaPriv::LogApiFail+100 (d:\act55\source\windows\appcompat\isi\uacanalyzer\avrf\avrf30\providers\luapriv\misc.cpp @ 482)
    vfluapriv2!NS_LuaPriv::VfHookCreateMutexA+77 (d:\act55\source\windows\appcompat\isi\uacanalyzer\avrf\avrf30\providers\luapriv\luapriv.cpp @ 1082)
    RASAPI32!InitializePbk+67 ( @ 0)
    RASAPI32!DllMain+99 ( @ 0)
    RASAPI32!_CRT_INIT+26d ( @ 0)
    verifier!DllUnregisterServer+185e0 ( @ 0)
    vrfcore!+6b7f89b4 ( @ 0)
    ntdll!LdrpCallInitRoutine+14 ( @ 0)
    ntdll!LdrpRunInitializeRoutines+26f ( @ 0)
    ntdll!LdrpLoadDll+4d1 ( @ 0)
    ntdll!LdrLoadDll+92 ( @ 0)
    KERNELBASE!LoadLibraryExW+15a ( @ 0)
    KERNELBASE!LoadLibraryExA+26 ( @ 0)
    kernel32!LoadLibraryA+bb ( @ 0)

    The other 'errors' are thrown during calls to RasEnumEntries, and SUA reports 'The application performed a hard administrator check.' Specifically, RASAPI32.DLL is calling CheckTokenMembership against the entities 'NT AUTHORITY\SYSTEM', 'BUILTIN\Administrators' and 'BUILTIN\Network Configuration Operators'. An example stack trace is as follows:

    vfluapriv2!NS_LuaPriv::AnalyzeTokenMembership+51 (d:\act55\source\windows\appcompat\isi\uacanalyzer\avrf\avrf30\providers\luapriv\sids.cpp @ 564)
    vfluapriv2!NS_LuaPriv::VfHookCheckTokenMembership+50 (d:\act55\source\windows\appcompat\isi\uacanalyzer\avrf\avrf30\providers\luapriv\luapriv.cpp @ 1333)
    RASAPI32!FIsUserAdmin+49 ( @ 0)
    RASAPI32!FIsUserAdminOrNCO+5 ( @ 0)
    RASAPI32!ReadLegacyProfiles+2c ( @ 0)
    RASAPI32!ReadPhonebookFileEx+4c ( @ 0)
    RASAPI32!ReadPhonebookFile+1b ( @ 0)
    RASAPI32!DwEnumEntriesFromPhonebook+75 ( @ 0)
    RASAPI32!DwEnumEntriesForPbkMode+106 ( @ 0)
    RASAPI32!RasEnumEntriesW+b1 ( @ 0)
    RASAPI32!RasEnumEntriesA+169 ( @ 0)

    If I run the legacy app elevated, I experience many more error reports from SUA, all in response to actions taken by RASAPI32.DLL (mainly within OpenProcessToken).

    So - am I forced to choose to either (a) remove dial-up support so that standard users can run my app, or (b) insist on admin-level users only so that I can retain dial-up support?

    Thanks again for your help and advice,

    Tuesday, November 24, 2009 10:20 AM