Boost.Pythonを使用してPythonインタープリターを埋め込むアプリケーションに取り組んでいます。これは、メインプログラムと対話するユーザー生成の「スクリプト」を実行するために使用されます。
残念ながら、あるユーザーがスクリプトを実行しようとすると、ランタイムエラーR6034が報告されています。メインプログラムは正常に起動しますが、python27.dllの読み込み時に問題が発生している可能性があります。
Visual Studio 2005、Python 2.7、およびBoost.Python1.46.1を使用しています。この問題は、1人のユーザーのマシンでのみ発生します。私は以前にマニフェストの問題に対処し、それらを解決することができましたが、この場合、私は少し途方に暮れています。
他の誰かが同様の問題に遭遇しましたか？あなたはそれを解決することができましたか？どのように？
私はその問題の解決策を見つけました。うまくいけば、これは他の誰かを助けるでしょう-これらの問題はデバッグするのにとてもイライラする可能性があります。
この問題は、パスに自分自身を追加し、プログラムフォルダにmsvcr90.dllをインストールしたサードパーティソフトウェアが原因で発生しました。この場合、問題の原因はIntelのiCLSクライアントです。
だから...同様の状況で問題を見つける方法は？
ここからProcessExplorerをダウンロードします。
アプリケーションを起動し、ランタイムエラーR6034を再現します。
ProcessExplorerを起動します。[表示]メニューで[下部ペインビュー]に移動し、[DLL]を選択します。
上部のペインで、アプリケーションを見つけてクリックします。下部のペインには、アプリケーション用にロードされたDLLのリストが表示されます。
リストから「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)
YouCompleteMeの場合のvimの場合、次を上部に置くことができます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と同様に、組み込みのPython2.7とその他のネイティブアセンブリも使用していました。
これをうまく複雑にしているのは、私のアプリケーションが64ビットIIS Express（VS2013）上で実行される中規模の.Netソリューションであったという事実です。
Dependency Walker（すばらしいプログラムですが、これを支援するには時代遅れです）とProcess Monitor（ProcMon-おそらくいくつかのヒントを見つけましたが、フィルターを使用していても、問題は何千もの無関係な操作に埋もれていました。より良いフィルターが役立ったかもしれません）。
しかし、マイケル・クーパーに感謝します！ あなたのステップとProcessExplorer（procexp）は、私を一日中避けてきた解決策にすぐに導きました。
Michaelのすばらしい投稿にいくつかメモを追加できます。
最終的に私はmsvcr90.dllがから引き込まれているのを見つけました：
パスを調べてみると、上記と、32ビットバージョンが含まれているように見える別の同様のディレクトリが見つかりました。私はこれらの両方を削除し、再起動しました...それでも問題がありました。
そこで、Michaelの手順をもう一度実行すると、別のmsvcr90.dllが次の場所からロードされていることがわかりました。
パスをもう一度調べてみると、上記とこのディレクトリの（x86）バージョンも見つかりました。そこで、両方を削除し、変更を適用し、VS2013を再起動して...
これ以上のR6034エラーはありません！
私はこれを行うためにインテルに不満を感じずにはいられません。パスからiCLSクライアントを削除するためのヒントをオンラインで実際に見つけました。やってみましたが、症状は同じだったので、問題ないと思いました。悲しいことに、iCLSクライアントとOpenCLSDKは私のiisexpressのタグチームを組んでいました。幸運にもどちらかを削除できた場合、R6034エラーが残りました。私は問題を解決するためにそれらの両方を切除しなければなりませんでした。
マイケル・クーパーと他のみんなの助けにもう一度感謝します！
上記のMichaelの回答を使用して、次を追加することにより、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をロードしたライブラリがインポートされる前に、システムパスに問題の原因となったパスが含まれていないことを確認するだけです。
ありがとう！
この投稿では、@MichealCooperと@frmdstryrについて詳しく説明しています。問題のあるPATHエントリを特定したら、
ここで問題があると仮定して、 Pythonスクリプトの前に次のように配置できます。iCLS ClientCMake
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])
YouCompleteMeケースのvimに関しては、次のように上部に配置できます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が引き続き実行可能であることを確認できます。どこからでも。
解決してくれてありがとう。システムのパス変数に「iCLSClient」ではなく「ICLSCLIENT」という文字列が含まれているため、このサンプルコードを少し変更しました。
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)])
私の場合、リンクされたライブラリと、同様の「ランタイム実行ライブラリ」プロジェクト設定を使用したメインプロジェクトの再構築が役立ちました。それが誰にとっても役立つことを願っています。
私の場合、アプリをexeファイルにコンパイルした後、そのファイルの名前を変更すると、問題が発生することに気付きました。したがって、exeファイルの元の名前を残しても、エラーは表示されません。
このページでの議論は、私よりはるかに進んだことをすることを含みます。（コーディングはしていません。）それでも、推奨される診断としてProcessExplorerを実行しました。別のプログラムがそのプログラムフォルダにあるmsvcr90.dllを使用し、必要としていることがわかりました。ここで議論されている他のことは何も理解していません。大げさな推測として、私は一時的にdllを隣接するプログラムフォルダに移動しました。
問題が解決しました。ランタイム終了エラーメッセージ。
（プログラムがエラーメッセージを生成し終えたら、dllを元に戻しました。）
あなたの助けとアイデアをありがとうございました。
Universal-CRTPython27.dllを使用したCプログラムからの埋め込みでも同じ問題が発生しました。
A<PYTHON_ROOT>\msvcr90.dllは犯罪者でした。そして<PYTHON_ROOT>、私のコース外PATHです。AFAICSの唯一のユーザーはmsvcr90.dllPyWin32モジュールです
<PYTHON_ROOT>\lib\site-packages\win32\win32*.pyd。
修正は<PYTHON_ROOT>\msvcr90.dll、そのディレクトリに移動するだけでした。
PS。PyWin32には、7年後も問題としてこれがあります。
ProcessExplorerでユーザー指定のパスを持つライブラリを確認します。Python 3を実行する以外は、同じ問題を解決する必要はありませんmsvcr??.dll
。現在の解決策は、の異常なパスを示していないため、役に立ちませんmsvcr90.dll。行の後にエラーダイアログが表示されるまで（コードがPyTablesモジュールをインポートしているときに呼び出されます）、コードを段階的にデバッグします。
import ctypes
ctypes.cdll.LoadLibrary('libbz2.dll')
次に、Process Explorerは、問題の原因となった古いパスを見つけるのに役立ちますlibbz2.dll（@Micheal Cooperアルゴリズムのステップ3、4）
まだ解決策を探している人のためにこの答えを追加します。ESRIは、このエラーのパッチをリリースしました。彼らのウェブサイトからパッチをダウンロードし（ログインは不要）、インストールするだけで問題は解決します。10.4.1のパッチをダウンロードしましたが、他のバージョンのパッチもあるかもしれません。