Erreur d'exécution R6034 dans une application Python intégrée
Je travaille sur une application qui utilise Boost.Python pour intégrer l'interpréteur Python. Ceci est utilisé pour exécuter des "scripts" générés par l'utilisateur qui interagissent avec le programme principal.
Malheureusement, un utilisateur signale l'erreur d'exécution R6034 lorsqu'il tente d'exécuter un script. Le programme principal démarre correctement, mais je pense que le problème peut se produire lorsque python27.dll est chargé.
J'utilise Visual Studio 2005, Python 2.7 et Boost.Python 1.46.1. Le problème ne se produit que sur la machine d'un utilisateur. J'ai déjà traité des problèmes de manifestes et j'ai réussi à les résoudre, mais dans ce cas, je suis un peu perdue.
Quelqu'un d'autre a-t-il rencontré un problème similaire? Avez-vous pu le résoudre? Comment?
J'ai trouvé la solution au problème. J'espère que cela aidera quelqu'un d'autre - ces problèmes peuvent être so frustrants au débogage.
Le problème était dû à un logiciel tiers qui s'était ajouté au chemin et avait installé msvcr90.dll dans son dossier de programme. Dans ce cas, le problème était dû au client iCLS d'Intel.
Alors ... Comment trouver le problème dans des situations similaires?
Téléchargez Process Explorer ici .
Démarrez votre application et reproduisez l'erreur d'exécution R6034.
Démarrez Process Explorer. Dans le menu "Affichage", accédez à "Vue du volet inférieur" et choisissez "DLL".
Dans le volet supérieur, localisez votre application et cliquez dessus. Le volet inférieur doit afficher une liste des fichiers DLL chargés pour votre application.
Recherchez "msvcr ??. Dll" dans la liste. Il devrait y en avoir plusieurs. Recherchez celui qui ne se trouve pas dans le dossier "winsxs" et notez-le.
Maintenant, vérifiez le chemin juste avant que votre application s'exécute. S'il comprend le dossier que vous avez noté à l'étape 5, vous avez probablement trouvé le coupable.
Comment resoudre le probleme? Vous devrez supprimer l'entrée incriminée du chemin avant d'exécuter votre programme. Dans mon cas, je n'ai besoin de rien d'autre dans le chemin, alors j'ai écrit un simple fichier de commandes qui ressemble à ceci:
path=
myprogram.exe
C'est tout. Le fichier de commandes efface simplement le chemin avant l'exécution de mon programme, de sorte que l'exécution en conflit DLL ne soit pas trouvée.
J'espère que cela t'aides!
Une solution plus générale est:
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))])
(J'ai eu le même problème avec VanDyke SecureCRT)
Cet article développe @Micheal Cooper et @frmdstryr et donne une meilleure alternative que ma réponse précédente . Vous pouvez mettre ce qui suit devant un script python pour purger les entrées problématiques.
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)
Pour le vim avec YouCompleteMe case, vous pouvez mettre le texte suivant en haut de votre 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
(Cela pourrait être mieux comme commentaire que comme réponse complète, mais mon compte poussiéreux SO n’a pas encore assez de représentants pour cela.)
Comme l’OP, j’utilisais également un Python 2.7 intégré et d’autres assemblys natifs.
Cela compliquait bien le fait que mon application était une solution .Net de taille moyenne fonctionnant au-dessus de IIS Express 64 bits (VS2013).
J'ai essayé Dependency Walker (excellent programme, mais trop obsolète pour aider), et Process Monitor (ProcMon - qui a probablement trouvé des indices, mais même si j'utilisais des filtres, les problèmes étaient enfouis dans des milliers d'opérations indépendantes de meilleurs filtres ont peut-être aidé).
Cependant, MERCI BEAUCOUP à Michael Cooper! Vos démarches et Process Explorer (procexp) m'ont rapidement conduit à une solution qui m'évitait toute la journée.
Je peux ajouter quelques notes à l'excellent post de Michael.
- J'ai ignoré (c'est-à-dire laissé inchangé) non seulement le dossier\WinSxS\... mais également le dossier\System32\....
En fin de compte, j’ai trouvé msvcr90.dll extrait de:
- C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x64
En parcourant mon chemin, j'ai trouvé ce qui précède ainsi qu'un autre répertoire similaire, qui semblait contenir des versions 32 bits. J'ai enlevé les deux, redémarré et ... TOUJOURS avait le problème.
Donc, j'ai suivi les étapes de Michael une fois de plus, et, découvert une autre msvcr90.dll était maintenant chargée de:
- C:\Program Files\Client Intel\iCLS \
En parcourant à nouveau mon chemin, j'ai trouvé ce qui précède ainsi qu'une version (x86) de ce répertoire. J'ai donc supprimé les deux, appliqué les modifications, redémarré VS2013 et ...
Pas plus d'erreur R6034!
Je ne peux pas m'empêcher de me sentir frustré par Intel pour avoir fait cela. En fait, j'avais trouvé ailleurs en ligne une astuce sur la suppression du client iCLS du chemin d'accès. J'ai essayé cela, mais le symptôme était le même, alors j'ai pensé que ce n'était pas le problème. Malheureusement, iCLS Client et OpenCL SDK ont associé mon tag iisexpress. Si j'ai eu la chance d'enlever l'un ou l'autre, l'erreur R6034 est restée. J'ai dû exciser les deux afin de remédier au problème.
Merci encore à Michael Cooper et à tous les autres pour votre aide!
En utilisant la réponse de Michael ci-dessus, j'ai pu résoudre ce problème sans fichier chauve-souris en ajoutant:
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])
dans le fichier python principal de l'application. Il s'assure simplement que le chemin du système n'inclut pas les chemins à l'origine du problème avant l'importation des bibliothèques qui ont chargé les dll.
Merci!
Cet article développe @Micheal Cooper et @frmdstryr . Une fois que vous avez identifié les entrées PATH problématiques, vous pouvez mettre les éléments suivants devant un script python , en supposant que iCLS Client et CMake sont problématiques.
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])
Concernant le vim avec YouCompleteMe cas, vous pouvez mettre le texte suivant en haut de votre 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 aucune de ces solutions ne vous convient, vous pouvez essayer de supprimer manuellement le problème provoquant les entrées De votre chemin PATH, mais vous voulez vous assurer de ne rien casser d'autre sur votre système Qui en dépend. Entrées PATH. Ainsi, par exemple, pour CMake, vous pouvez essayer de supprimer Son entrée PATH et de ne placer qu'un lien symbolique (ou similaire) pointant vers le fichier binaire cmake.exe dans un autre répertoire Qui se trouve dans votre PATH. assurez-vous que cmake est toujours utilisable n'importe où.
Merci pour la solution. Je viens de modifier un peu cet exemple de code car la variable de chemin dans mon système contient la chaîne "CLIENT ICLS" au lieu de "client iCLS"
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)])
Ajout de cette réponse pour qui cherche encore une solution. ESRI a publié un correctif pour cette erreur. Il suffit de télécharger le correctif sur leur site Web (aucun identifiant requis), de l'installer et cela résoudra le problème. J'ai téléchargé le correctif pour 10.4.1 mais il existe peut-être aussi des correctifs pour d'autres versions.
Dans mon cas, la reconstruction de bibliothèques liées et le projet principal avec un paramètre de projet similaire "Bibliothèques d'exécution Runtime" ont été utiles. J'espère que cela sera utile pour tout le monde.
Dans mon cas, j'ai réalisé que le problème se posait lorsque, après avoir compilé l'application dans un fichier exe, je renommerais ce fichier. Donc, laisser le nom original du fichier exe ne montre pas l'erreur.
J'ai également eu le même problème avec l'incorporation de Python27.dll à partir d'un programme C utilisant le Universal-CRT.
Un <PYTHON_ROOT>\msvcr90.dll était le délinquant. Et <PYTHON_ROOT> est hors-cours dans ma PATH. AFAICS sont les seuls utilisateurs de msvcr90.dll sont les PyWin32 modules <PYTHON_ROOT>\lib\site-packages\win32\win32*.pyd.
Le correctif consistait simplement à déplacer <PYTHON_ROOT>\msvcr90.dll dans ce répertoire.
PS. PyWin32 a toujours ce problème sous forme de numéro 7 ans plus tard!
La discussion sur cette page implique de faire des choses bien plus avancées que moi. (Je ne code pas.) Néanmoins, j'ai lancé Process Explorer en tant que diagnostic recommandé. J'ai trouvé qu'un autre programme utilise et a besoin de msvcr90.dll dans son dossier de programme. Ne comprenant rien à ce qui est discuté ici, je suppose que j’ai temporairement déplacé la DLL vers un dossier de programme voisin.
Problème résolu. Message d'erreur de fin de l'exécution.
(J'ai déplacé la dll à la fin du programme générant le message d'erreur.)
Merci à tous pour votre aide et vos idées.
Vérifiez toutes les bibliothèques ayant le chemin spécifié par l'utilisateur par Process Explorer. Il n'est pas nécessaire qu'il soit msvcr??.dll J'ai résolu le même problème, sauf que je lance Python 3. Les solutions actuelles ne sont pas utiles car elles n'indiquent pas les chemins inhabituels de msvcr90.dll. Je débogue le code pas à pas dans la boîte de dialogue d'erreur après les lignes (appelées lors de l'importation de mon code PyTables module):
import ctypes
ctypes.cdll.LoadLibrary('libbz2.dll')
Ensuite, Process Explorer aide à trouver le chemin d'accès à l'ancien libbz2.dll à l'origine du problème (étapes 3 et 4 de l'algorithme @Micheal Cooper).