OpenSSL compatible con FIPS tiene una limitación: debe cargar libeay32.dll en una dirección fija y, si se carga en cualquier otra dirección, falla la verificación de inicialización, por lo que no se puede usar en modo FIPS.
Así que elegimos la dirección de acuerdo con la recomendación de Microsoft y en algunas máquinas esa dirección de vez en cuando está ocupada por otras bibliotecas, como MSVCR120_CLR0400.dll o mscorlib.ni.dll o clr.dll , entiende el punto.
¿Hay alguna manera de verificar si se toma alguna dirección fija + longitud y pedirle al sistema operativo que libere esa parte de la memoria para mí, como reorganizar esos dll en otras partes de la memoria o algo así?
Actualizar:
Recopilé información de 20 dispositivos con ListDLL y hay un patrón de qué se carga dónde, pero está lejos de estar bien definido. Así que realicé algunos cálculos, encontré la brecha más grande, donde no se cargó nada en esos 20 registros que tenía, cambié la dirección base de libeay32 a algún lugar en esa brecha (la brecha era ~ 6 veces más grande que dll, así que elegí ~ en medio) y aún después de un par de intentos, la aplicación logró cargar algo en ese espacio antes de libeay32 (para ser específicos, clrjit.dll, tiene una dirección base de 0x10000000, que creo que es la predeterminada), aunque en la aplicación intento cargar libeay32 tan pronto como sea posible.
¿Por qué no combinas las pistas dadas?
/INCLUDE con un símbolo de libeay.dll cuando vincule su programa para forzar una dependencia estática en esa biblioteca.libeay32.dll con /FIXED para que no se pueda reubicar.Por lo tanto, se carga al cargar el ejecutable, antes de que se ejecute cualquier código administrado, no en algún momento posterior de forma dinámica, por lo que todos esos archivos DLL reubicables aún no están allí y no pueden interponerse en el camino.