Estoy trabajando en una aplicación que utiliza el Boost.Python para incrustar el intérprete de Python. Este se utiliza para ejecutar generado por el usuario «scripts» que interactúan con el programa principal.

Por desgracia, un usuario de informes de error de tiempo de ejecución R6034 cuando intenta ejecutar una secuencia de comandos. El programa principal se inicia bien, pero creo que el problema puede estar ocurriendo cuando python27.dll se carga.

Estoy usando Visual Studio 2005, Python 2.7 y Boost.Python 1.46.1. El problema se produce sólo en una máquina del usuario. Me he ocupado de manifiesto los problemas antes, y logrado resolver el problema de ellos, pero en este caso estoy en un poco de una pérdida.

Tiene a nadie a correr a un problema similar? Fueron capaces de resolverlo? Cómo?

13 Comentarios

  1. 96

    He encontrado la solución al problema. Esperemos que esto ayude a alguien-estos problemas pueden ser así frustrante para depurar.

    El problema fue causado por el software de terceros que se había añadido a sí mismo a la ruta de acceso y el instalado msvcr90.dll en su carpeta de programa. En este caso, el problema fue causado por Intel ciet Cliente.

    Así que… ¿Cómo encontrar el problema en situaciones similares?

    1. Descargar Process Explorer aquí.

    2. Iniciar la aplicación y reproducir el error en tiempo de ejecución R6034.

    3. Proceso De Inicio Del Explorer. En el menú «Ver» ir a «Panel Inferior Ver» y seleccione «Dll».

    4. En el panel superior, busque la aplicación y haga clic en él. El panel inferior debería mostrar una lista de archivos DLL cargados para su aplicación.

    5. Localizar «msvcr??.dll» en la lista. Debe haber varias. Busque uno que no está en la «winsxs» de la carpeta, y hacer una nota de ello.

    6. Ahora, compruebe la ruta de acceso justo antes de que se ejecute la aplicación. Si se incluye la carpeta que anotó en el paso 5, de lo que has encontrado al culpable.

    Cómo solucionar el problema? Usted tendrá que quitar el de ofender a la entrada de la ruta de acceso antes de ejecutar el programa. En mi caso, no necesito nada más en el camino, así que escribí un simple archivo por lotes que se parece a esto:

    path=
    myprogram.exe

    Que es. El archivo de proceso por lotes simplemente despeja el camino antes de que mi programa se ejecuta, por lo que el conflicto runtime DLL no se encuentra.

    Espero que esto ayude!

    • Usted señor, es un campeón! Para mí, yo estaba tratando de usar YouCompleteMe para gVim, y cmake era el delincuente que había añadido bin del directorio a la ruta de acceso que contiene msvcr90.dll. Gracias por el excelente instrucciones
    • Muy útil! Yo estaba teniendo problemas con el uso de «gdb.exe» con «mingw» en Windows, cuando se ejecuta Omnet++ simulación, donde el programa fue error de tiro R6034. Cuando yo excluir CMAKE incluyen desde el Windows CAMINO, que ahora funciona como un encanto. gracias!
    • cómo puede ser que el camino sea temporalmente limpiado en Visual Studio?
    • está bien si el «msvcr??.dll» es en el c:\windows\SysWOW64?
    • Yo estaría cauteloso de que uno. El winsxs carpeta puede contener muchas versiones diferentes de la DLL y el sistema sabe cómo encontrar uno que sea compatible con la aplicación. Si el DLL está en el SysWOW64 de carpetas, pues no creo que la versión será administrado–esto podría ser una versión antigua de la DLL que no es compatible con la aplicación.
    • Desde el programa principal se desarrolla en VS2005, es mejor para hacer frente a este problema con el manifiesto. Consulte aquí
    • Eclipse fue el uso de msvcr90.dll de la ciet Cliente, junto con la proporcionada por Windows. En lugar de quitar ciet Cliente desde el camino, me ha cambiado el nombre de su msvcr90.dll a msvcr90.dll_bak y el problema desapareció. Gracias Michael.
    • Hola, he utilizado el explorer y se encontró el archivo dll en la lista. Pero, no es la que aparece dentro de la ruta. Sin embargo, me abrió el camino como usted sugiere y ejecutar el archivo exe. Yo todavía estoy recibiendo el mismo error.
    • Genial, a mí me funcionó. Gracias
    • Para mí msvcr empezado dos veces por dos diferentes intérpretes de python es la causa del problema. El uso de process monitor, me hizo encontrar y eliminar la segunda instancia de appdata

  2. 4

    Una solución más general es:

    import os
    os.environ['path'] = ";".join(
        [path for path in os.environ['path'].split(";") 
         if "msvcr90.dll" not in map((lambda x:x.lower()), os.listdir(path))])

    (Yo tuve el mismo problema con VanDyke SecureCRT)

  3. 4

    Este post se profundiza en @Michael Cooper y @frmdstryr y le da una mejor alternativa que la de mi anterior respuesta.
    Usted puede poner el siguiente en frente de un secuencia de comandos de python para purgar la problemática de las entradas.

    import os, re
    path = os.environ['PATH'].split(';')
    
    def is_problem(folder):
        try:
            for item in os.listdir(folder):
                if re.match(r'msvcr\d\d\.dll', item):
                    return True
        except:
            pass
        return False
    
    path = [folder for folder in path if not is_problem(folder)]
    os.environ['PATH'] = ';'.join(path)

    Para la vim con YouCompleteMe caso, usted puede poner el siguiente en la parte superior de su vimrc:

    python << EOF
    import os, re
    path = os.environ['PATH'].split(';')
    
    def is_problem(folder):
        try:
            for item in os.listdir(folder):
                if re.match(r'msvcr\d\d\.dll', item):
                    return True
        except:
            pass
        return False
    
    path = [folder for folder in path if not is_problem(folder)]
    os.environ['PATH'] = ';'.join(path)
    EOF
  4. 2

    El uso de Michael respuesta anterior, yo era capaz de resolver esto sin un archivo bat mediante la adición de:

    import os
    
    # Remove CLS Client from system path
    if os.environ['PATH'].find("iCLS Client")>=0:
        os.environ['PATH'] = "".join([it for it in os.environ['PATH'].split(";") if not it.find("iCLS Client")>0])

    el principal archivo de python de la aplicación. Sólo se asegura de ruta de acceso del sistema no incluya las rutas que estaban causando el problema antes de las bibliotecas que carga la dll fueron importados.

    Gracias!

  5. 2

    (Esto podría ser mejor como un comentario de una respuesta completa, pero mi polvoriento ASÍ acct. todavía no dispone de la suficiente rep por eso.)

    Como la OP yo también estaba usando una de Python 2.7 y algunos otros nativos de las asambleas.

    Complicar esta muy bien fue el hecho de que mi solicitud era med-grande .Net solución se ejecuta en la parte superior de la versión de 64 Bits de IIS Express (VS2013).

    He intentado Dependency Walker (gran programa, pero también fuera de fecha para ayudar con esto), y el Monitor de Procesos (ProcMon-que probablemente hizo encontrar algunas pistas, pero a pesar de que yo estaba usando los filtros de los problemas que fueron enterrados en miles de la relación de operaciones, filtra mejor, podría haber ayudado a).

    Sin embargo, MUCHAS GRACIAS a Michael Cooper! Sus pasos y el Proceso Explorer (procexp) me consiguió rápidamente a una solución que había estado esquivando de mí todo el día.

    Puedo añadir un par de notas a Michael excelente post.

    • Me ignoran (es decir, sin cambios), y no sólo el \WinSxS\ carpeta… pero también el \System32\… carpeta.

    Encontré en última instancia msvcr90.dll se extraen a partir de:

    • C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x64

    Pasando a través de mi Camino me encontré con el de arriba y el otro, similar directorio que parecía contener las versiones de 32 bits. He quitado tanto de estos, reinicia y… TODAVÍA tenía el problema.

    Así, he seguido de Michael pasos una vez más, y, descubierto otro msvcr90.dll ahora se cargan desde:

    • C:\Program Files\Intel\ciet Cliente\

    Pasando a través de mi Camino de nuevo, me encontré con el anterior y de una (x86) versión de este directorio. Así que, he quitado los dos, aplicar los cambios, reinicie VS2013 y…

    No más R6034 Error!

    Yo no puedo ayudar pero siento frustrado con Intel para hacer esto. En realidad yo había encontrado en otros lugares en línea una sugerencia acerca de cómo quitar ciet Cliente de la Ruta. He intentado eso, pero el síntoma es el mismo, así que, pensé que no era el problema. Lamentablemente ciet Cliente y OpenCL SDK fueron tag-formación de equipos de mi iisexpress. Si fui lo suficientemente afortunado como para quitar cualquiera de los dos, el R6034 error se mantuvo. Yo tenía a los impuestos especiales, tanto de ellos en el fin de curar el problema.

    Gracias de nuevo a Michael Cooper y a todos los demás por su ayuda!

  6. 2

    Este post se profundiza en @Michael Cooper y @frmdstryr.
    Una vez identificada la problemática entradas de RUTA de acceso, usted puede poner el siguiente en frente de un
    secuencia de comandos de python, asumiendo aquí que iCLS Client y CMake son problemáticos.

    import os
    for forbidden_substring in ['iCLS Client', 'CMake']:
        os.environ['PATH'] = ';'.join([item for item in os.environ['PATH'].split(';')
                                       if not item.lower().find(forbidden_substring.lower()) >= 0])

    Sobre la vim con YouCompleteMe caso, usted puede poner el siguiente en la parte superior de su vimrc:

    python << EOF
    import os
    for forbidden_substring in ['iCLS Client', 'CMake']:
        os.environ['PATH'] = ';'.join([item for item in os.environ['PATH'].split(';')
                                       if not item.lower().find(forbidden_substring.lower()) >= 0])
    EOF

    Si ninguna de estas soluciones es aplicable para usted, usted puede tratar de eliminar el problema que causa
    entradas de RUTA de acceso de forma manual, pero desea asegurarse de que usted no romper nada en tu
    sistema que depende de estas entradas de RUTA de acceso. Así, por ejemplo, para CMake se podría tratar de quitar
    su CAMINO de entrada, y sólo poner un enlace (o similares) que apunta a la cmake.exe binario en algunos
    otro directorio que se encuentra en su CAMINO, para asegurarse de cmake es todavía ejecutables desde cualquier lugar.

    • Por favor, consulte a mi otra respuesta por qué es una solución mejor, en mi humilde opinión. Voy a dejar esta respuesta ser como alternativa.
  7. 1

    Gracias por la solución. Acabo de poco modificado en este ejemplo de código, la variable path en mi sistema contiene la cadena «CIET CLIENTE» en lugar de «ciet Cliente»

    import os
    # print os.environ['PATH']
    # Remove CLS Client from system path
    if os.environ['PATH'].find("iCLS Client") >= 0 or os.environ['PATH'].find("ICLS CLIENT") >= 0:
        os.environ['PATH'] = "".join([it for it in os.environ['PATH'].split(";") if not (it.find("iCLS Client")>0 or it.find("ICLS CLIENT")>0)])
  8. 0

    En mi caso, la reconstrucción de los enlaces a las bibliotecas y los principales proyectos similares «tiempo de ejecución de ejecución de las bibliotecas de» configuración de proyecto ayudó. La esperanza de que será útil para nadie.

  9. 0

    En mi caso, me di cuenta de que era el problema viene cuando, después de compilar la aplicación en un archivo exe, me gustaría cambiar el nombre de ese archivo. Así dejar el nombre original del archivo exe que no muestra el error.

  10. 0

    El debate sobre esta página implica hacer las cosas de manera muy avanzado por encima de mí. (Yo no código). Sin embargo, me encontré con Process Explorer como el diagnóstico recomendado. Me encontré con que otro programa de usos y necesidades de msvcr90.dll en la carpeta del programa. No entendía nada de lo demás que se habla aquí, como una conjetura he movido temporalmente la dll a un vecino de la carpeta de programa.

    Problema resuelto. Final del tiempo de ejecución mensaje de error.

    (He movido el archivo dll cuando yo había terminado con el programa de generar el mensaje de error.)

    Gracias a todos por vuestra ayuda e ideas.

  11. 0

    También tuve el mismo problema con la inserción de Python27.dll de un C-programa de uso de la Universal-CRT.

    Un <PYTHON_ROOT>\msvcr90.dll fue el delincuente. Y <PYTHON_ROOT> está fuera de curso en mi PATH. AFAICS la que sólo los usuarios de msvcr90.dll son los PyWin32 módulos
    <PYTHON_ROOT>\lib\site-packages\win32\win32*.pyd.

    La revisión se acaba de mover <PYTHON_ROOT>\msvcr90.dll a ese directorio.

    PS. PyWin32 todavía tiene esto como un problema 7 años más tarde!

  12. 0

    Comprobar cualquier biblioteca de usuario ruta de acceso especificada por el Proceso Explorer. No es necesario, deberá ser msvcr??.dll
    He resuelto el mismo problema, excepto puedo ejecutar Python 3. Presentar soluciones no ayudó porque ellos no indican inusual caminos de msvcr90.dll. Yo depurar el código paso a paso hasta dentro de diálogo de error aparece después de filas (llamadas cuando el código se ha de importar PyTables módulo):

    import ctypes
    ctypes.cdll.LoadLibrary('libbz2.dll')

    A continuación, el Proceso de Explorer ayuda a encontrar el camino a la vieja libbz2.dll causado el problema (pasos 3, 4 de @Michael Cooper algoritmo)

  13. -1

    La adición de esta respuesta por que se sigue buscando una solución. ESRI lanzado un parche para corregir este error. Sólo tienes que descargar el parche desde su página web (no es necesario iniciar sesión), se instala y se va a resolver el problema. He descargado el parche para 10.4.1 pero quizá hay parches para otras versiones también.

    • Esta respuesta podría haber sido más útil con un enlace a la información de referencia.

Dejar respuesta

Please enter your comment!
Please enter your name here