LabVIEW deja de funcionar al llamar un DLL con excepción 0xc0000005

Actualizado el Sep 30, 2019

Reportado en

Software

  • LabVIEW

Detalles del problema

  • LabVIEW se bloquea cuando llamo a mi DLL (por sus siglas en inglés), y aparece un mensaje de error que indica memory access violation has occurred (Código de excepción: 0xc0000005).
  • Cambié mi versión de LabVIEW de 32 bits a 64 bits y ahora mi aplicación falla aleatoriamente con el Código de excepción: 0xc0000005

Solución

Hay varias razones diferentes por las que LabVIEW podría fallar al llamar a una función de DLL para prevenir este tipo de fallas:

1. Asegúrese de que está utilizando las mismas convenciones de llamada que la DLL
Si la especificación de convención de llamada en el nodo de función de biblioteca de llamadas no coincide con la convención de llamada de la DLL, se producirá un bloqueo. La convención de llamada se especifica en la parte inferior derecha de la ventana del nodo Función de biblioteca de llamadas, como se ve a continuación.

2. Asegúrese de conectar todas las entradas y salidas de su Call Library Function Node
Si no conecta todas las entradas y salidas de un nodo de función de biblioteca de llamadas, la función DLL sobrescribirá la memoria no asignada y causará que LabVIEW se bloquee.

Nota: Si su segunda entrada es un puntero a su primera entrada, entonces su primera entrada no requiere una salida.

3. Asegúrese de que la función DLL no esté sobrescribiendo la memoria de LabVIEW
Si no se asigna suficiente memoria o si la función DLL escribe más de lo que se asignó, el DLL sobrescribirá el espacio de memoria reservado de LabVIEW y causará que LabVIEW se bloquee. Asegúrese de que la memoria esté asignada correctamente antes de pasar y leer matrices, cadenas o formas de onda desde archivos DLL.

4. Asegúrese de que LabVIEW esté pasando parámetros a la función en el formato que la función espera
Llamar a la función DLL desde LabVIEW con tipos de datos de parámetros incorrectos (por valor, referencia, identificador, etc.) puede hacer que la función apunte involuntariamente a una ubicación de memoria incorrecta que provoque datos defectuosos, o incluso un bloqueo de LabVIEW o Windows.

5. La función llamada en sí misma hace algo ilegal.
Si una función intenta realizar una operación ilegal, podría fallar LabVIEW. Si no es el autor de la función, póngase en contacto con el autor de la función.

Información adicional

  1. Cuando se utiliza la convención de llamada C (del inglés C calling convention), el llamante es responsable de limpiar la pila (del inglés stack). Cuando se utiliza la convención de llamada estándar, la función llamada es responsable de limpiar la pila. Si la persona que llama (LabVIEW) y la función DLL llamada no usan la misma convención de llamada, ambos quitarán las cosas de la pila o ninguno de ellos lo hará. Cualquiera de estas situaciones puede hacer que LabVIEW se bloquee cuando la función llamada regresa.
  2. Si no conecta las entradas, la función DLL sobrescribirá la memoria no asignada. Si no conecta las salidas, LabVIEW asume que la función DLL no necesita que la memoria asignada se pase por el lado de entrada y la usará para otra cosa.
  3. Muchas funciones de DLL toman la memoria asignada, pasadas por puntero o valor, escriben en esta memoria y la devuelven. Si la memoria no está asignada correctamente, puede causar un bloqueo. Por ejemplo, considere la siguiente función:

    double *Waveform (double *waveform, uInt32 size); 

    La forma correcta de asignar la memoria en este caso es inicializar la matriz con el número de elementos especificado por el parámetro de size, y no pasando una matriz vacía. La imagen de abajo muestra el método apropiado.
En 
Si construyó el DLL en LabVIEW y quiere mostrar el panel frontal del DLL VI, hay dos requisitos que debe seguir.
  1. El Call Library Function Node  debe configurarse de modo que la llamada a DLL pueda ejecutarse en cualquier subproceso. Esto se establece cambiando el botón de thread de Run in UI thread  a Run in any thread. 
Nota: Todas las llamadas a bibliotecas compartidas construidas en LabVIEW deben especificar Run in any thread. Si configura el Call Library Function Node utilizando bibliotecas compartidas creadas en LabVIEW y especifica Run in UI thread, LabVIEW podría bloquearse y requerir que reinicie. Para obtener más información, consulte el cuadro de diálogo Función de la biblioteca de llamadas .
  1. El VI que llama no debe ejecutarse en el hilo de la interfaz de usuario. Esto se puede verificar seleccionando File»VI Properties del menú desplegable, seleccionando Execution en la lista Category y asegurándose de que el Preferred Execution System sea standard, instrument I/O , data acquisitionother 1, o other 2.  La opción same as caller no debe elegirse porque el VI padre podría estar ejecutándose en el hilo de la interfaz de usuario.
Para obtener la documentación completa sobre cómo usar el código de LabVIEW con otros lenguajes de programación en LabVIEW 7.1 o anterior, consulte el Manual de Uso de Código Externo en LabVIEW . En LabVIEW 8.0 o posterior, consulte la sección Fundamentals>> en la tabla de contenido de la Ayuda de LabVIEW para obtener más información.

Nota: Es posible que, en modo de desarrollo, su VI aún se ejecute sin seguir estos pasos. Sin embargo, al crear una aplicación, asegúrese de configurar el VI que llama a Ejecutar en cualquier subproceso como se indica anteriormente.

Si LabVIEW falla hasta que se cierra
El problema más probable es que la función DLL que se está llamando ha dañado la memoria. Si pasa matrices o cadenas a la DLL, la función DLL no puede redimensionar dinámicamente la matriz. Escribir más allá del último elemento de la matriz o cadena podría dañar la memoria y esto podría no ser obvio hasta que se cierre LabVIEW.

Comprobación de errores: utilice la pestaña Error Checking para especificar el error checking level para el Call Library Function Node.

Esta pestaña incluye los siguientes componentes:
  • Error Checking Level: contiene las siguientes opciones:
    • Maximum: permite el nivel máximo de comprobación de errores para el nodo de función de biblioteca de llamadas. Si habilita el nivel máximo de comprobación de errores, el Call Library Function Node devuelve un error si la  Calling convention que selecciona en la pestaña Función no coincide con la convención de llamadas de la función a la que está llamando en la biblioteca compartida o DLL. El nivel máximo de comprobación de errores también devuelve una advertencia si la función a la que se llama en la biblioteca compartida o DLL escribe más allá del espacio asignado para la cadena o parámetro de matriz especificados. El nivel máximo de comprobación de errores permite que LabVIEW se recupere de las excepciones no controladas que se producen durante la ejecución de la biblioteca compartida llamada o DLL.
Nota: la selección del control Maximum en la pestaña Error Checking  reduce la velocidad de ejecución y aumenta el uso de la memoria del Call Library Function Node. Por lo tanto, debe seleccionar el control Maximum solo al depurar su configuración del Call Library Function Node.
  • Default: habilita el nivel predeterminado de comprobación de errores para el nodo de función de biblioteca de llamadas. El nivel predeterminado de verificación de errores permite que LabVIEW se recupere de las excepciones no controladas que se producen durante la ejecución de la biblioteca compartida llamada o DLL.
  • Disabled: desactiva la comprobación de errores para el nodo de función de la biblioteca de llamadas. La desactivación de la comprobación de errores para el nodo de función de la biblioteca de llamadas mejora la velocidad de ejecución del nodo de función de la biblioteca de llamadas. Sin embargo, ciertos errores pueden causar un cierre irregular de LabVIEW. Antes de deshabilitar la comprobación de errores, asegúrese de que la función a la que hace referencia el nodo de función de la biblioteca de llamadas no genere ninguna excepción no controlada.

¿FUE ESTE ARTÍCULO DE AYUDA?

No