Por qué iba a conseguir un GPF en DLLMain cuando se ejecuta como un usuario restringido?

Question

¿Por qué es el código falla cuando se ejecuta como un usuario restringido, pero no cuando se ejecuta como un administrador de la máquina?

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

El código está fallando en la vuelta ... y no sé qué.

Me estoy haciendo:

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

Además, _AtlModule.DLLMain se ve así:

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
}

Estamos importando el DLL ATL, y tratamos de vincular estáticamente así ... sin suerte.

---

Actualizar

El uso de ProcMon, aparece un desbordamiento de búfer aquí:

RegQueryValue HKU \ S-1-5-21-448539723-854245398-1957994488-1005 \ Software \ Microsoft \ Windows \ CurrentVersion \ Explorer \ Shell Folders \ Cache desbordamiento de búfer Longitud: 144

¿Qué significa esto?

Answer 1

Cuando se produce un error diciendo que no puede hacer referencia a una memoria en algún lugar ... 0x0000, que por lo general significa que su código está intentando hacer referencia a una variable miembro de algún objeto, pero el puntero de objeto en NULL. En este caso, la variable miembro es 0x34 bytes en el objeto. Además de adivinanzas, dado que sólo se produce un error cuando se ejecuta en un usuario restringido, diría alguna operación que se supone que devolver un puntero a un objeto falla debido a la falta de derechos. Si el puntero devuelto no está probado por ser nulo, el código seguirá funcionando hasta que alguien intenta leer una de sus variables miembro, en cuyo punto se obtiene el accidente.

lo que haría es depurar a fondo el código y buscar valores NULL sospechosas. Además, es posible que desee ejecutar su aplicación bajo AppVerifier con el LuaPriv prueba en ella. Si mi suposición es correcta, algunas llamadas a la API se reportaron fallas, que se manifiesta en su código como valores NULL devueltos. AppVerifier también debe proporcionar el seguimiento de la pila, por lo que será capaz de encontrar fácilmente la raíz del problema.

Answer 2

Jason,

Cuando estás declarando m_hInstance? ¿Es estática por encima de DllMain? Tratando de obtener algunos detalles más sobre el código.

Answer 3

En realidad, no dice lo que quiere decir con "ataques" por lo que es difícil de decir. El código está haciendo nada en particular que va a causar un accidente, por lo que probablemente la llamada al módulo de ATL DllMain está requiriendo privilegios de administrador y no a causa de ello.

Answer 4

Trate de ejecutar la utilidad ProcMon y ver si puede detectar una diferencia. Vas a tener que dar vuelta la filtración, de lo contrario es probable que haya una salida muy alta para vadear.

Una cosa para comprobar si está utilizando la DLL ATL (en lugar de la biblioteca estática):. Asegurarse de que está obteniendo la misma versión de la DLL en ambos casos

Answer 5

Parece que rastreamos RDCOMClient, que se utiliza para ejecutar el objeto COM dentro de R.

respuestas de todo el mundo ayudaron. Gracias.