Ошибка выполнения R6034 во встроенном приложении Python
Я работаю над приложением, которое использует Boost.Python для встраивания интерпретатора Python. Это используется для запуска пользовательских "сценариев", которые взаимодействуют с основной программой.
К сожалению, один пользователь сообщает об ошибке времени выполнения R6034 при попытке запустить скрипт. Основная программа запускается нормально, но я думаю, что проблема может возникнуть при загрузке python27.dll.
Я использую Visual Studio 2005, Python 2.7 и Boost.Python 1.46.1. Проблема возникает только на компьютере одного пользователя. Я уже имел дело с манифестными проблемами и сумел их решить, но в этом случае я немного растерялся.
Кто-нибудь еще сталкивался с подобной проблемой? Вы смогли решить это? Как?
12 ответов
Я нашел решение проблемы. Надеюсь, это поможет кому-то еще - эти проблемы могут быть такими неприятными для отладки.
Проблема была вызвана сторонним программным обеспечением, которое добавило себя в путь и установило msvcr90.dll в свою программную папку. В этом случае проблема была вызвана клиентом In tel iCLS.
Итак... Как найти проблему в подобных ситуациях?
Загрузите Process Explorer здесь.
Запустите ваше приложение и воспроизведите ошибку времени выполнения R6034.
Запустите Process Explorer. В меню "Вид" перейдите в "Вид нижней панели" и выберите "DLLs".
В верхней панели найдите свое приложение и щелкните по нему. В нижней панели должен отображаться список DLLS, загруженных для вашего приложения.
Найдите "msvcr??. Dll" в списке. Там должно быть несколько. Найдите тот, который не находится в папке "winsxs", и запишите его.
Теперь проверьте путь перед запуском приложения. Если он включает папку, которую вы отметили в шаге 5, вы, вероятно, нашли виновника.
Как решить проблему? Вам придется удалить ошибочную запись с пути перед запуском вашей программы. В моем случае мне больше ничего не нужно в пути, поэтому я написал простой командный файл, который выглядит следующим образом:
path=
myprogram.exe
Вот и все. Пакетный файл просто очищает путь до запуска моей программы, так что конфликтующая DLL времени выполнения не найдена.
Надеюсь это поможет!
Этот пост посвящен @Micheal Cooper и @frmdstryr и дает лучшую альтернативу, чем мой предыдущий ответ. Вы можете поместить следующее перед скриптом Python для очистки проблемных записей.
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)
Для vim с делом YouCompleteMe вы можете поместить следующее в верхней части 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
Более общее решение:
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))])
(У меня была такая же проблема с VanDyke SecureCRT)
(Это может быть лучше в качестве комментария, чем полный ответ, но мой пыльный SO акт. Еще не хватает представителя для этого.)
Как и OP, я также использовал встроенный Python 2.7 и некоторые другие нативные сборки.
Сложно было усложнить тот факт, что мое приложение было очень большим.Net решением, работающим поверх 64-битного IIS Express (VS2013).
Я попробовал Dependency Walker (отличная программа, но слишком устарела, чтобы помочь с этим) и Process Monitor (ProcMon - который, вероятно, нашел некоторые подсказки, но, хотя я использовал фильтры, проблемы были похоронены в тысячах несвязанных операций, лучшие фильтры, возможно, помогли).
Тем не менее, ОГРОМНОЕ СПАСИБО Майклу Куперу! Ваши шаги и Process Explorer (procxp) быстро привели меня к решению, которое уклонялось от меня весь день.
Я могу добавить пару заметок к отличному посту Майкла.
- Я проигнорировал (то есть оставил без изменений) не только папку \WinSxS\..., но и папку \System32\....
В конечном итоге я обнаружил, что msvcr90.dll извлекается из:
- C: \ Program Files (x86) \ Intel \ OpenCL SDK \ 2.0 \ bin \ x64
Проходя мой путь, я обнаружил вышеупомянутый и другой аналогичный каталог, который, казалось, содержал 32-битные версии. Я удалил оба из них, перезапустил и... все еще была проблема.
Итак, я повторил шаги Михаэля и обнаружил, что теперь загружается еще один файл msvcr90.dll:
- C: \ Program Files \ Intel \ iCLS Client \
Пройдя по моему пути снова, я нашел вышеупомянутую и (x86) версию этого каталога. Итак, я удалил оба из них, применил изменения, перезапустил VS2013 и...
Нет больше R6034 Ошибка!
Я не могу не чувствовать себя разочарованным Intel за то, что сделал это. Я действительно нашел в другом месте онлайн совет об удалении Клиента iCLS из Пути. Я пытался это сделать, но симптомы были такими же, поэтому я подумал, что это не проблема. К сожалению, iCLS Client и OpenCL SDK объединяли мои теги в iisexpress. Если мне посчастливилось удалить любой из них, ошибка R6034 осталась. Мне пришлось удалить их обоих, чтобы решить проблему.
Еще раз спасибо Майклу Куперу и всем остальным за вашу помощь!
Используя ответ Михаэля выше, я смог решить эту проблему без файла bat, добавив:
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])
к основному файлу python приложения. Это просто гарантирует, что системный путь не включает пути, которые вызывали проблему, прежде чем библиотеки, которые загрузили DLL, были импортированы.
Спасибо!
Этот пост посвящен @Micheal Cooper и @frmdstryr. После того как вы определили проблемные записи PATH, вы можете поместить следующее перед скриптом Python, предполагая, что iCLS Client а также CMake проблемные.
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])
Что касается VIM с делом YouCompleteMe, вы можете поставить следующее в верхней части вашего 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
Если ни одно из этих решений не подходит для вас, вы можете попытаться устранить проблему, вызывающую записи из вашей переменной PATH, вручную, но вы хотите убедиться, что в вашей системе больше ничего не сломано, что зависит от этих записей PATH. Так, например, для CMake вы можете попытаться удалить его запись PATH и только поместить символическую ссылку (или подобное), указывающую на двоичный файл cmake.exe, в какой-то другой каталог, который находится в вашем PATH, чтобы убедиться, что cmake все еще работает откуда угодно.
Спасибо за решение. Я просто немного изменил этот пример кода, так как переменная пути в моей системе содержит строку "КЛИЕНТ ICLS" вместо "Клиент 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)])
У меня тоже была такая же проблема с встраиванием Python27.dll из C-программы с использованием Universal-CRT.
<PYTHON_ROOT>\msvcr90.dll был преступником А также <PYTHON_ROOT> вне курса в моем PATH, AFAICS единственные пользователи msvcr90.dll такое модули PyWin32 <PYTHON_ROOT>\lib\site-packages\win32\win32*.pyd,
Исправление было просто двигаться <PYTHON_ROOT>\msvcr90.dll в этот каталог.
PS У PyWin32 все еще есть проблема 7 лет спустя!
В моем случае я понял, что проблема возникнет, когда после компиляции приложения в исполняемый файл я переименую этот файл. Таким образом, оставив исходное имя exe-файла, вы не увидите ошибку.
В моем случае помогла перестройка связанных библиотек и основного проекта со схожей настройкой проекта "Runtime Execution Library". Надеюсь, что это будет полезно для всех.
Обсуждение на этой странице включает в себя все, что намного выше меня. (Я не кодирую.) Тем не менее, я запустил Process Explorer в качестве рекомендуемой диагностики. Я обнаружил, что другая программа использует и нуждается в msvcr90.dll в папке с программой. Не понимая, что еще обсуждается здесь, как дикая догадка, я временно переместил dll в соседнюю программную папку.
Задача решена. Сообщение об окончании времени выполнения.
(Я переместил dll обратно, когда я закончил с программой, генерирующей сообщение об ошибке.)
Спасибо всем за вашу помощь и идеи.
Проверьте любую библиотеку с указанным пользователем путем от Process Explorer. Это не обязательно должно быть msvcr??.dllЯ решил ту же проблему, за исключением запуска Python 3. Существующие решения не помогли, потому что они не указывают необычные пути msvcr90.dll, Я шаг за шагом отлаживаю код до тех пор, пока после строк не появится диалоговое окно с ошибкой (вызывается, когда мой код импортировал модуль PyTables):
import ctypes
ctypes.cdll.LoadLibrary('libbz2.dll')
Тогда Process Explorer помогает найти путь к старому libbz2.dll вызвал проблему (шаги 3, 4 алгоритма @Micheal Cooper)
Добавление этого ответа для тех, кто все еще ищет решение. ESRI выпустила патч для этой ошибки. Просто скачайте патч с их сайта (не требуется вход в систему), установите его, и это решит проблему. Я скачал патч для 10.4.1, но, возможно, есть патчи и для других версий.