Win 7 DllImport C# Error impar, ¿Acceso no válido a la ubicación de la memoria?

Question

Estoy usando DllImport para acceder a algunas funciones en un dll C++ desde mi aplicación C#.

Este código funciona bien en mi computadora portátil dev, que es Windows 7 de 64 bits, el dll en sí es de 32 bits, así que ejecuto el proceso de alojamiento del dll en 32 bits y funciona bien. Sin embargo, cuando trato de ejecutar exactamente el mismo proceso en mi máquina de destino, que es otra vez, Windows 7 64bit Ultimate aparece el error "Acceso no válido a la ubicación de la memoria". del proceso.

No estoy seguro de cuál es el problema, he visto muchos recursos en la red y ninguno de ellos me lo ha solucionado. No entiendo por qué funciona bien en mi cuadro dev, pero no en el objetivo?

El dll en sí está bien, los ejemplos que vienen con el dll funcionan bien en mi cuadro de destino (que son aplicaciones C# que hacen DllImport).

¿Alguien más ha tenido este problema? ¡Estuve peleando por dos días!

Excepción: {"Unable to load DLL 'CLEyeMulticam.dll': Invalid access to memory location. (Exception from HRESULT: 0x800703E6)"}

Answer 1

que he tenido este problema antes. Creo que su problema es que VS intente abrir el archivo pero no tenga permisos para leerlo. Debe asegurarse de que la cuenta que está utilizando tenga acceso a la DLL. Pruebe a deshabilitar el UAC para ver si funciona o use una cuenta de administrador. O intente dando Full Control en la DLL al Everyone.

EDITAR: ¿Podría ejecutar VS como administrador (clic derecho -> Ejecutar como administrador)? ¿Podrías poner la DLL en tu escritorio para probar? ¿Hay una diferencia de estructura de carpetas entre su computadora que funciona y la que está fallando? Además, ¿puede funcionar bien el DLL si lo ejecuta fuera de VS (intente ejecutarlo también como administrador)?

HTH

Answer 2

La carga DLL puede bloquearse debido a las dependencias sin resolver, por lo que abrir el archivo DLL en la máquina de destino con Dependency Walker y ver es que hay algún problema.

Answer 3

Noto una gran diferencia entre su máquina de desarrollo y su máquina de destino, el entorno de desarrollo. Asegúrese de tener todos los redistribuibles necesarios en la máquina de destino.

Editar: He visto problemas similares cuando algunos dlls se compilaron en diferentes versiones de .Net framework o si se hicieron con diferentes versiones de Visual Studio, ya que los redistribuibles para cada versión son diferentes y los últimos redistribuibles no son exactamente compatible con versiones anteriores.

Answer 4

He tenido problemas similares antes, intente lo siguiente.

• Compruebe la versión .NET CLR. ¿Hay algún SP/KB presente en su objetivo que no esté en su desarrollador?
• Intente cargar la versión de depuración de la DLL de C++. ¿Puedes cargarlo? Si falla, te sugiero que comiences tu aplicación bajo WinDBG en tu objetivo. Una vez que se aprueba la excepción, un simple! Analyze -v le dará mucha información.
• Como siguiente paso, Intentaré reproducir este problema en un entorno de prueba de unidad. ¿Las muestras de C# que mencionaste están compiladas para x64 VM? Si no, intente hacer eso e intente ejecutar el binario de muestra resultante en su objetivo. ¿El problema es reproducible?

Answer 5

He encontrado un problema con un 64bit.Aplicación NET ("Cualquier CPU") que intenta cargar una dependencia DLL nativa de 32 bits. No tengo el mensaje de error delante de mí, así que no puedo decirte si es el mismo problema. La solución para mi problema fue cambiar mi compilación a solo x86.

Si el tamaño del bit de la DLL está cambiando en cada cuadro, quizás haya diferencias en el tamaño de la estructura, por lo que su firma PInvoke se vuelve incorrecta. Esto podría causar fácilmente un desbordamiento del búfer y causar daños en la pila en el código nativo.

Answer 6

Me encontré con un problema similar cuando me mudé a win7. Puede que tenga que ajustar el equipo (64 bits) para funcionar como de 32 bits uno por defecto, utilizando el siguiente comando:

C: \ WINDOWS \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Ldr64.exe setwow

Ref: http://social.msdn.microsoft.com/Forums/en/phoenix/thread/9a43e9a1-a744-4a1a-bb34-3604254c126b

Answer 7

Si usted está recibiendo el error en su aplicación de C#, este mensaje suele indicar el código nativo hizo algo desagradable a la memoria que la ILM puede ver - comprobar el código en/llamada por su DllMain rutina - eso se llama antes de que su llamada realmente se transmita - si se está portando mal, verá este resultado

Answer 8

@Merlyn Morgan-Graham Nos enfrentamos a un problema similar. Donde construimos la aplicación .Net con la compilación "Any CPU" y probamos con 32 bits C++ Dll. Cuando ejecutamos la aplicación .Net en sistema operativo de 64 bits. Funciona como ejecutable de 64 bits y, por lo tanto, tiene un problema similar. Después de instalar X86 Loading, las llamadas a C++ Dlls funcionaron absolutamente bien. Una cosa más importante es si está usando C++ DLL en su código .Net. Habrá una buena cantidad de clasificación, por lo que es importante mantener el tipo de compilación (es decir, X86, cualquier CPU o X64).

Por favor, compruebe el siguiente enlace también: Windows Vista: Unable to load DLL 'x.dll': Invalid access to memory location. (DllNotFoundException)

Answer 9

La solución obvia, pero probablemente cojos sería construir lado C# explícitamente de 32 bits. Compruebe cómo se crea el host fuera de proc - programáticamente o rellenando las claves de registro o ... podría ser que en otra caja se configure para realizar un proceso de alojamiento de 64 bits o para intentar una invocación in-proc, lo que significa cargar. . Es una configuración de registro, no olvide que para casos mixtos de 23/64 bits hay dos ramas en las que profundizar.

Answer 10

que tenían el mismo problema aquí Native loading works good. Loading from .net gives error Unable to load DLL 'my.dll': Invalid access to memory location

El problema estaba en función DEP. Cuando encendí DEP solo para programas esenciales, no dio ningún efecto. Pero cuando apagué por completo DEP y reinicié mi servidor, el error desapareció. Una cosa más que he hecho: instalé las últimas actualizaciones para .net 4.0

Lo único notable: no vi ningún error sobre DEP, simplemente cerrando con un error de "memoria".