Подтвердить что ты не робот

Ошибка выполнения R6034 во встроенном приложении Python

Я работаю над приложением, которое использует Boost.Python для встраивания интерпретатора Python. Это используется для запуска пользовательских "скриптов", которые взаимодействуют с основной программой.

К сожалению, один пользователь сообщает об ошибке R6034 во время выполнения, когда он пытается запустить script. Основная программа запускается нормально, но я думаю, что проблема может возникнуть при загрузке python27.dll.

Я использую Visual Studio 2005, Python 2.7 и Boost.Python 1.46.1. Проблема возникает только на одной машине пользователя. Раньше я сталкивался с проблемами манифестации и сумел их разрешить, но в этом случае я немного потерял.

Кто-нибудь еще сталкивается с подобной проблемой? Могли ли вы это решить? Как?

4b9b3361

ОТВЕТЫ

Ответ 1

Я нашел решение проблемы. Надеюсь, это поможет кому-то другому - эти проблемы могут быть настолько неприятными для отладки.

Проблема была вызвана сторонним программным обеспечением, которое добавило себя в путь и установило msvcr90.dll в своей папке программы. В этом случае проблема была вызвана клиентом Intel iCLS.

Итак... Как найти проблему в подобных ситуациях?

  • Загрузить Process Explorer здесь.

  • Запустите приложение и воспроизведите ошибку времени выполнения R6034.

  • Запустите Process Explorer. В меню "Вид" перейдите в "Вид нижней панели" и выберите "DLL".

  • В верхней панели найдите приложение и нажмите на него. Нижняя панель должна отображать список DLLS, загруженных для вашего приложения.

  • Найдите "msvcr??. dll" в списке. Их должно быть несколько. Найдите тот, который не находится в папке "winsxs", и обратите внимание на это.

  • Теперь проверьте путь непосредственно перед запуском приложения. Если он содержит папку, указанную на шаге 5, вы, вероятно, нашли виновника.

Как устранить проблему? Перед запуском программы вам придется удалить оскорбительную запись из пути. В моем случае мне не нужно ничего в пути, поэтому я написал простой командный файл, который выглядит так:

path=
myprogram.exe

Что это. Командный файл просто очищает путь до запуска моей программы, поэтому конфликтующая DLL времени выполнения не найдена.

Надеюсь, это поможет!

Ответ 2

Более общее решение:

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)

Ответ 3

Этот пост подробно описывает @Micheal Cooper и @frmdstryr и дает лучшую альтернативу, чем мой более ранний ответ. Для очистки проблемных записей вы можете поставить перед python script следующее:

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

Ответ 4

Используя ответ Майкла выше, я смог разрешить это без файла 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, были импортированы.

Спасибо!

Ответ 5

(Это может быть лучше, чем комментарий, чем полный ответ, но мой пыльный SO acct. еще не имеет достаточной репутации для этого.)

Как и OP, я также использовал встроенный Python 2.7 и некоторые другие собственные сборки.

Усложнением этого было то, что мое приложение было большим решением .Net, работающим поверх 64-битного IIS Express (VS2013).

Я попробовал Dependency Walker (отличная программа, но слишком устаревший, чтобы помочь с этим) и Process Monitor (ProcMon), который, вероятно, нашел некоторые подсказки, но хотя я использовал фильтры, проблемы были похоронены в тысячах возможно, не помогли).

Тем не менее, МНОГО СПАСИБО Майклу Куперу! Ваши шаги и Process Explorer (procexp) заставили меня быстро найти решение, которое уклонялось от меня весь день.

Я могу добавить пару примечаний к Майклу.

  • Я проигнорировал (т.е. оставил без изменений) не только папку \WinSxS \..., но также папку \System32 \....

В итоге я обнаружил, что msvcr90.dll извлекается из:

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

Пройдя через мой путь, я нашел выше и другой, похожий каталог, который, казалось, содержал 32-битные версии. Я удалил оба из них, перезапустил и... У STILL возникла проблема.

Итак, я снова выполнил шаги Майкла и обнаружил, что еще одна msvcr90.dll теперь загружается из:

  • C:\Program Files\Intel\iCLS Client\

Повторяя мой путь, я нашел выше и (x86) версию этого каталога. Итак, я удалил оба из них, применил изменения, перезапустил VS2013 и...

Больше нет ошибки R6034!

Я не могу не разочароваться в Intel за это. Я действительно нашел в другом месте онлайн отзыв об удалении клиента iCLS с Пути. Я пробовал это, но симптом был таким же, поэтому я думал, что это не проблема. К сожалению, iCLS Client и OpenCL SDK были связаны с тегами с моим iisexpress. Если мне посчастливилось удалить один из них, ошибка R6034 осталась. Мне пришлось вырезать их обоих, чтобы вылечить проблему.

Еще раз спасибо Майклу Куперу и всем остальным за вашу помощь!

Ответ 6

Этот пост подробно описывает @Micheal Cooper и @frmdstryr. После того как вы определили проблемные записи PATH, вы можете поставить следующее перед python script, предполагая, что 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 все еще запущен из любого места.

Ответ 7

Спасибо за решение. Я просто немного изменил этот образец кода, поскольку переменная пути в моей системе содержит строку "ICLS CLIENT" вместо "iCLS Client" 

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

В моем случае помогло пересоздание связанных библиотек и основного проекта с аналогичными настройками проекта "Исполняемые исполняемые файлы". Надеюсь, что это будет полезно для всех.

Ответ 9

В моем случае я понял, что проблема возникает, когда после компиляции приложения в exe файл я бы переименовал этот файл. Поэтому, оставляя исходное имя файла exe, не отображается ошибка.

Ответ 10

Обсуждение на этой странице связано с тем, что мы продвигаемся далеко вперед. (Я не кодирую.) Тем не менее, я запускал Process Explorer в качестве рекомендуемой диагностики. Я обнаружил, что другая программа использует и требует msvcr90.dll в ней папку программы. Не понимая ничего, что обсуждалось здесь, как дикое предположение, я временно переместил dll в соседнюю папку программы.

Проблема решена. Конец сообщения об ошибке выполнения.

(Я переместил dll обратно, когда закончил с программой, генерирующей сообщение об ошибке.)

Спасибо всем за вашу помощь и идеи.

Ответ 11

У меня также была такая же проблема с встраиванием 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 лет спустя!

Ответ 12

Проверьте любую библиотеку с указанным пользователем путем от Process Explorer. Это не обязательно должно быть msvcr??.dll Я решил ту же проблему, кроме запуска Python 3. Нынешние решения не помогли, потому что они не указывают необычные пути msvcr90.dll. Я шаг за шагом отлаживаю код до тех пор, пока после строк не появится диалоговое окно с ошибкой (вызывается, когда мой код импортировал модуль PyTables):

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

Затем Process Explorer помогает найти путь к старой libbz2.dll вызвавшей проблему (шаги 3, 4 алгоритма @Micheal Cooper)

Ответ 13

Добавление этого ответа для тех, кто все еще ищет решение. ESRI выпустила исправление для этой ошибки. Просто скачайте патч со своего сайта (без входа в систему), установите его, и он решит проблему. Я загрузил патч для 10.4.1, но есть и исправления для других версий.