Why would I get a GPF in DLLMain when run as a restricted user?

Question

Why is this code crashing when run as a restricted user, but not when run as an admin of the machine?

extern "C" BOOL WINAPI DllMain(HINSTANCE hInstance, 
                               DWORD dwReason, 
                               LPVOID lpReserved)
{
 hInstance;
 m_hInstance=hInstance;
 return _AtlModule.DllMain(dwReason, lpReserved); 
}

The code is crashing on the return... and I don't know why.

I am getting:

The instruction at "0x7c90100b" referenced memory at "0x00000034". 
The memory could not be "read".

Furthermore, _AtlModule.DLLMain looks like this:

inline BOOL WINAPI CAtlDllModuleT<T>::DllMain(DWORD dwReason, LPVOID lpReserved) throw()
{
#if !defined(_ATL_NATIVE_INITIALIZATION)
    dwReason; lpReserved;
#pragma warning(push)
#pragma warning(disable:4483)
    using namespace __identifier("<AtlImplementationDetails>");
#pragma warning(pop)
    if (dwReason == DLL_PROCESS_ATTACH)
    {
        ATLASSERT(DllModuleInitialized == false);
    }
    return TRUE;
#else
    return _DllMain(dwReason, lpReserved);
#endif
}

We are importing the ATL DLL, and tried linking statically as well... no luck.

---

UPDATE

Using ProcMon, I get a buffer overflow here:

RegQueryValue HKU\S-1-5-21-448539723-854245398-1957994488-1005\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cache BUFFER OVERFLOW Length: 144

What does this mean?

Answer 1

When you get an error saying you can't reference a memory at some 0x0000... location, it usually means your code is trying to reference a member variable of some object, but the object pointer points to NULL. In this case, the member variable is 0x34 bytes into the object. Further guessing, given that it only fails when running under a restricted user, I'd say some operation that is supposed to return a pointer to an object fails due to insufficient rights. If the returned pointer is not tested for being null, the code will continue running until someone tries to read one of its member variables, at which point you get the crash.

what I would do is thoroughly debug the code and look for suspicious NULLs. Also, you might want to run your app under AppVerifier with the LuaPriv test on. If my guess is correct, some API calls failures would be reported, manifested in your code as returned NULLs. AppVerifier should also provide you the stack trace, so you'll be able to easily find the root of the problem.

Answer 2

Jason,

Where are you declaring m_hInstance? Is it static at above DllMain? Just trying to get some more details about the code.

Answer 3

You don't really say what you mean by "crashing" so it is difficult to tell. The code is doing nothing in particular that will cause a crash, so probably the call to the ATL module DllMain is requiring admin privileges and failing because of that.

Answer 4

Try running the ProcMon utility and see if you can spot a difference. You'll have to turn filtering on, otherwise there will likely be too much output to wade through.

One thing to check if you're using the ATL DLL (instead of the static library): make sure that you're getting the same version of the DLL in both cases.

Answer 5

Looks like we traced RDCOMClient, which is used to run the COM object inside of R.

Everybody's answers helped. Thank you.