tags:

views:

334

answers:

5

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?

+1  A: 

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.

1800 INFORMATION
Why would a call to DllMain require admin privileges? Crashing... I am getting a "The instruction as X referenced memory at Y. The memory could not be read" error.
Jason
Have you tried stepping into the call with a debugger? Maybe you have some kind of buffer overrun that is overwriting the return address on the stack with garbage
1800 INFORMATION
Isn't DLLMain the first thing to run? Where can I be screwing up my stack with this? Should I look somewhere else?
Jason
What is the call to _AtlModule.DllMain(dwReason, lpReserved); doing? Maybe that is corrupting the stack
1800 INFORMATION
I added the code for _AtlModule.DLLMain... but not sure I understand it. ;)
Jason
+1  A: 

Jason,

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

Rob Fahrni
Declared above DLLMain... HINSTANCE m_hInstance;
Jason
Jason, _AtlModule.DllMain() is injected into a DllMain.cpp file when you generate an ATL based .DLL project. Did this project not start life as an ATL project?
Rob Fahrni
I think it did (it is old, and inherited) but it was altered. DllMain.cpp is renamed, and thus I expect other code to be tweaked. The _AtlModule.DllMain function is above, and I think it is standard. I don't think it changed. Furthermore, this works when you are an admin, but not when you are restricted... that is the oddest thing to me. Are different libraries not available to restricted users?
Jason
+1  A: 

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.

jdigital
Thanks for the ideas... will try.
Jason
We are importing... but tried static library too. No difference.
Jason
Have you tried ProcMon yet? It can show you failures resulting from permissions problems etc.
jdigital
The code is crashing after _AtlModule.DllMain()... but before it returns... so yes, something must be happening earlier, causing the problem. I am having a hard time trying to figure out how to use ProcMon, I am new to it.
Jason
We found a Buffer Overflow, I put it in the body... now what? :)
Jason
That doesn't look like an error. First, that registry entry is most likely one that's manipulated by the system, not by your app. Second, some of the Microsoft APIs take a buffer and a buffer size and report an "overflow" if the buffer wouldn't have been large enough to hold the result (i.e., it's not a real overflow).
jdigital
You should set up ProcMon so that it filters out all applications except yours. If you don't want to waste time figuring out ProcMon, there are two older tools from SysInternals (FileMon and RegMon) that are easier to use and should give you almost as much information.
jdigital
+2  A: 

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.

eran
A: 

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

Everybody's answers helped. Thank you.

Jason