問題タブ [msvcrt]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
dll - LoadLibrary() が、マニフェストとプライベート アセンブリを含む DLL の読み込みに失敗する
複数の DLL を使用する Windows アプリケーション (EXE) に取り組んでいます。開発は VCExpress 2005 (VC 8.0) で、C のみを使用しています。
LoadLibrary
これらの DLL の一部は、EXE によって読み取られる構成ファイルに従って 動的にロードされるプラグイン/アドオン/拡張機能です。
重要: アプリケーションは移植可能 (インストールせずに USB フラッシュ ドライブなどから実行できるという意味で) である必要があり、プラグイン DLL はアプリケーション EXE と同じフォルダーにない場合があります (従来の理由)。
MSVC6 では、これは簡単です。EXE と DLL をコンパイル、リンク、配布します。
MSVC8 では、C ランタイム ライブラリ (MSVCRT) が OS と共に配布されなくなったため、インストールされていることに依存することはできません。移植性の要件を満たすには、プライベート アセンブリを使用する必要があります。すべての EXE と DLL には、マニフェストが埋め込まれています。
私の問題:経由で読み込まれたプラグイン DLLLoadLibrary()
は、EXE のフォルダーにあるプライベート アセンブリを見つけられないため、Microsoft.VC80.CRT
アセンブリが winSxS にインストールされていない限り、それらを読み込もうとすると失敗します。
キャッチ: マニフェストがプラグイン DLL から削除されると、すべてが機能します。
私の質問:
問題のケースでは、Windows はアセンブリ検索シーケンスまたはダイナミック リンク ライブラリ検索順序のいずれにも従っていないようです。具体的には、アプリケーション (EXE) のロード元ではなく、DLL のロード元のパスでプライベート アセンブリを検索します。
アセンブリを DLL に隣接させ、現在のディレクトリを変更して (作業ディレクトリのケースに関連するものを除外するために) これを確認し、期待どおりの動作を得ようとしました。LoadLibrary
SxS で使用する場合、これが通常の動作であることを他の誰かが確認できますか?マニフェストがないと、DLLは、EXE のフォルダーで
msvcr80.dll
(アセンブリ マニフェストではなく) 検出される非 SxS ロード順序にフォールバックすると想定するのは正しいですか?Microsoft.VC80.CRT.manifest
(1) と (2) について私が正しければ、マニフェストを DLL から除外するだけで何を失うのでしょうか? 言い換えると、マニフェストを除外するだけで問題を解決できないのはなぜですか?
visual-c++ - ランタイムライブラリの不一致とVC++-ああ、悲惨です!
さまざまなライブラリがランタイムライブラリのどのバージョンを使用するかについて合意していないため、VC ++リンカーが不平を言ったり、口を閉ざしたりすることで、私は大人の人生のすべてに苦しんでいるようです。私はその悲惨な主題をマスターする気分には決してなりません。だから私はそれがうまくいくまでそれをいじろうとします。エラーメッセージは決して役に立ちません。この件に関するMicrosoftのドキュメントもそうではありません-少なくとも私にとってはそうではありません。
時々それは関数を見つけられません-名前マングリングが期待されたものではないので?時々それは混ぜ合わせることを拒否します。また、「LINK:警告LNK4098:defaultlib'LIBCMTD'は他のライブラリの使用と競合します。/NODEFAULTLIB:libraryを使用してください」と だけ表示されることもあります。/NODEFAULTLIBの使用は機能しませんが、警告は無害のようです。とにかく「DEFAULTLIB」とは一体何ですか?リンカーはどのように決定しますか?どのランタイムライブラリを使用するかをリンカに指定する方法を見たことがありません。関数呼び出しを作成するライブラリをコンパイラに指示する方法だけです。
オブジェクトファイルを検査して、それらが依存しているDLLを確認できる「依存関係ウォーカー」プログラムがあります。構築しようとしているプロジェクトで1つ実行しただけですが、これは非常に混乱しています。競合するランタイムバージョンが必要なシステム.libsと.dllがあります。たとえば、COMCTL32.DLLはMSVCRT.DLLを必要としていますが、MSVCRTD.DLLとリンクしています。入力しているときでも、COMCTL32D.DLLがあるかどうかを検索しています。
だから私が求めているのは、それらを整理する方法のチュートリアルだと思います。あなたは何をしますか、そしてどのようにそれをしますか?
これが私が知っていると思うことです。これのいずれかが間違っている場合は私を訂正してください。
パラメータは、デバッグ/リリース、マルチスレッド/シングルスレッド、および静的/DLLです。8つの可能な組み合わせのうち6つだけがカバーされています。デバッグでもリリースでも、シングルスレッドのDLLはありません。
設定は、リンクされるランタイムライブラリ(およびそれにリンクするための呼び出し規約)にのみ影響します。たとえば、DLLをビルドする場合は、DLLベースのランタイムを使用する必要はありません。また、プログラムのデバッグバージョンをビルドするときにランタイムのデバッグバージョンを使用する必要もありません。過去のシステムコールをステップ実行します。
ボーナスの質問:誰かまたはどの会社もそのような混乱をどのように作り出すことができますか?
c++ - VisualC++プログラムの問題-デバッグCRTが見つかりません
Visual C ++プロジェクトを引き継いでいて、実行に問題がある友人がいます。これはグラフィックアプリケーションであり、QtGUIライブラリを使用します。私がこれに言及する理由は、以下のエラーのためです。
彼はVisualStudio2010を使用してプログラムをビルドおよびリンクできますが、実行すると、次のメッセージがイベントビューアに表示されます。
「D:\ Test \ Qt \ 4.2.2 \ bin\QtGuid4.dll」のアクティベーションコンテキストの生成に失敗しました。依存アセンブリMicrosoft.VC80.DebugCRT、processorArchitecture = "x86"、publicKeyToken = "1fc8b3b9a1e18e3b"、type = "win32"、version="8.0.50608.0"が見つかりませんでした。詳細な診断にはsxstrace.exeを使用してください。
メッセージの要求どおりに実行してsxstrace.exeを実行すると、次のように表示されます。
アクティベーションコンテキストの生成を開始します。入力パラメーター:フラグ= 0 ProcessorArchitecture = Wow32 CultureFallBacks = en-US; en ManifestPath = D:\ Test \ Qt \ 4.2.2 \ bin \ QtGuid4.dll AssemblyDirectory = D:\ Test \ Qt \ 4.2.2 \ bin \
---------------情報:マニフェストファイルD:\ Test \ Qt \ 4.2.2 \ bin\QtGuid4.dllを解析しています。情報:マニフェスト定義IDは(null)です。情報:参照:Microsoft.VC80.DebugCRT、processorArchitecture = "x86" type = "win32"、version = "8.0.50608.0"情報:参照Microsoft.VC80.DebugCRT、processorArchitecture = "x86" "win32"、version="を解決しています8.0.50608.0"。情報:ProcessorArchitectureWOW64の参照を解決しています。情報:カルチャニュートラルの参照を解決しています。情報:バインディングポリシーを適用しています。情報:パブリッシャーポリシーが見つかりません。情報:バインディングポリシーリダイレクトが見つかりません。情報:アセンブリのプロービングを開始します。情報:WinSxSでアセンブリが見つかりませんでした。情報:C:\ Windows \ assembly \ GAC_32 \ Microsoft.VC80.DebugCRT \ 8.0.50608.0__1fc8b3b9a1e18e3b\Microsoftでマニフェストをプローブしようとしました。VC80.DebugCRT.DLL。情報:文化ニュートラルのマニフェストが見つかりませんでした。情報:アセンブリのプロービングを終了します。情報:ProcessorArchitecturex86の参照を解決しています。情報:カルチャニュートラルの参照を解決しています。情報:バインディングポリシーを適用しています。情報:パブリッシャーポリシーが見つかりません。情報:バインディングポリシーリダイレクトが見つかりません。情報:アセンブリのプロービングを開始します。情報:WinSxSでアセンブリが見つかりませんでした。情報:C:\ Windows \ assembly \ GAC_32 \ Microsoft.VC80.DebugCRT \ 8.0.50608.0__1fc8b3b9a1e18e3b\Microsoft.VC80.DebugCRT.DLLでマニフェストをプローブしようとしました。情報:D:\ Test \ Qt \ 4.2.2 \ bin\Microsoft.VC80.DebugCRT.DLLでマニフェストをプローブしようとしました。情報:D:\ Test \ Qt \ 4.2.2 \ bin\Microsoft.VC80.DebugCRT.MANIFESTでマニフェストをプローブしようとしました。情報:D:\ Test \ Qt \ 4.2.2 \ bin \ Microsoft.VC80.DebugCRT\Microsoftでマニフェストをプローブしようとしました。VC80.DebugCRT.DLL。情報:D:\ Test \ Qt \ 4.2.2 \ bin \ Microsoft.VC80.DebugCRT\Microsoft.VC80.DebugCRT.MANIFESTでマニフェストをプローブしようとしました。情報:文化ニュートラルのマニフェストが見つかりませんでした。情報:アセンブリのプロービングを終了します。エラー:参照Microsoft.VC80.DebugCRT、processorArchitecture = "x86"、publicKeyToken = "1fc8b3b9a1e18e3b"、type = "win32"、version="8.0.50608.0"を解決できません。
そのメッセージの長さについては申し訳ありませんが、私はそれがいくつかの思い出をジョギングするかもしれないと思いました。これは、彼がVisual C ++ 2005(VC80の出所だと思います)Cランタイムライブラリをインストールしていない場合ですか?もしそうなら、彼はVC ++再配布パッケージをダウンロードしてインストールできますか?それとも、これはまったく別の問題ですか?
c - 複数の CRT 問題を解決する
似たような質問がいくつかあることは知っていますが、私の要件と本当に同じ要件があるとは思いません。
当社の DLL は Visual Studio 2005 でコンパイルされており、インストールの制約により、特定のバージョンの CRT とリンクする必要があります。これは絶対です。最新バージョンで再コンパイルすることは解決策ではありません。
最近、Boost ライブラリを更新しました。ただし、Boost をビルドすると、自動的に最新の CRT が使用されました。ここで、Boost をプログラムにリンクすると、CRT の最新 (間違った) バージョンと CRT の古い (正しい) バージョンの両方に依存関係が作成されます。最新バージョンへの依存関係をなくす必要があります。
この問題の最善の解決策は何ですか? 現時点で考えられる最善の方法は、古いバージョンを使用して Boost を再構築することですが、ソースを変更せずに簡単に再構築する方法がわかりません。
Visual Studio で特定のバージョンの CRT をグローバルに (プロジェクトごとではなく) 使用するように強制する方法があれば、それは素晴らしいことです。または、CRT の最新バージョンを単純に削除する方法ですが、OS の一部と見なされているため、それは不可能だと確信しています。
c++ - MSCVRT ライブラリがリンク時に競合を生成するのはなぜですか?
Visual C++ 2008 でプロジェクトを作成しています。これは、自分のプロジェクトですぐに使用する静的 C++ クラス ライブラリ用の MFC ベースのアプリの例です。デバッグ構成を構築しているときに、次のようになります。
警告 LNK4098: defaultlib 'MSVCRT' は他のライブラリの使用と競合します。/NODEFAULTLIB:ライブラリを使用
推奨オプションを使用した後 (デバッグ構成のプロジェクト リンカー設定の [特定のライブラリを無視する] フィールドに「msvcrt」を追加)、プログラムはリンクして正常に実行されます。ただし、この競合が発生した理由、重要なライブラリを無視する必要がある理由、後で問題が発生することが予想される場合は、無視を追加するか、追加しない場合はどうなるかを知りたいです (とにかくプログラムがビルドされます)。
同時に、リリース構成は次のように警告します。
警告 LNK4075: '/OPT:ICF' 仕様により '/EDITANDCONTINUE' を無視します
警告 LNK4098: デフォルト ライブラリ 'MSVCRTD' は他のライブラリの使用と競合します。/NODEFAULTLIB:ライブラリを使用
「D」サフィックスは、これが vc++ ランタイムのデバッグ バージョンであることを意味していると思いますが、なぜこれが今回使用されるのかわかりません。とにかく、「msvcrtd」を無視フィールドに追加すると、次の形式のリンク エラーが多数発生します。
エラー LNK2001: 未解決の外部シンボル __imp___CrtDbgReportW
どんな洞察も大歓迎です。
windows - Windows Server 2008を搭載した既製のサーバーにはVC90CRTが含まれていますか?
WindowsServer2003についても同じ質問です。
VC 2008 sp1ランタイムをインストールするように人々に指示する必要がありますか?
答えは、サーバーがx64ビルドとx86ビルドのどちらを実行しているかによって異なりますか?
VCランタイムはMicrosoftUpdateまたはWindowsUpdateでプッシュされますか?
windows - CRT、まだ再配布する必要がありますか?
Windows ネイティブ アプリケーションを配布するとき、まだ vcredist.exe を気にする必要がありますか? これらのいずれかが Win-7 にバンドルされていますか?
そうでない場合、これらが Windows Update などを介して人々に出荷されない技術的な理由はありますか? (わかりました、それは議論の余地があるように聞こえるかもしれませんが、これらのライブラリがWindowsマシンにデフォルトでインストール/更新されない理由を本当に疑問に思っています)
windows - PATH 環境は、msvcr90 から msvcr80 への使用から実行中の実行可能ファイルにどのように影響しますか?
MSVCR80.dll
生成された実行可能ファイルと同じディレクトリに のさまざまなバージョンを( 経由でcmake
) 配置しようとしましたが、一致するものはありませんでした。
この種の問題に対する一般的な解決策はありますか?
アップデート
一部の回答では、VS Redist をインストールすることを推奨していますが、それがインストール済みの Visual Studio 9 に影響するかどうかはわかりません。誰か確認できますか?
実行可能ファイルのマニフェスト ファイル
マニフェスト ファイルには、 を使用する必要があると書かれているようですが、MSVCR90
常に欠落が報告されるのはなぜMSVCR80.dll
ですか?
見つかった
それに数時間を費やした後、最終的に、次の設定が原因であることがわかりましたPATH
。
それを削除した後、すべて正常に動作します.しかし、なぜその設定は実行中の実行可能ファイルにmsvcr90からmsvcr80の使用に影響するのでしょうか???
c# - .Net 4: PInvokeStackImbalance 例外
私は.Net 3.5プロジェクトのstrlen
関数を使用していました。msvcrt.dll
すなわち:
private unsafe static extern int strlen( byte *pByte );
.NET 4.0 に移行した後、この関数を使用するとPInvokeStackImbalance
例外がスローされます。
msvcrt.dll
.NET 3.5 をインポートしたり、この例外を修正するにはどうすればよいですか?
visual-c++ - CRT メモリの初期化の制御
時折、リリース ビルドや一部のマシンでのみ再現可能なバグに遭遇することがあります。一般的な (決してそれだけではない) 理由は、初期化されていない変数であり、ランダムな動作をする可能性があります。たとえば、初期化されていない BOOL は、ほとんどのマシンでほとんどの場合 TRUE になりますが、ランダムに FALSE として初期化されます。
私が望んでいるのは、CRT メモリの初期化の動作を変更して、このようなバグを洗い流す体系的な方法です。私は MS デバッグ CRTマジック ナンバーをよく知っています。少なくとも、0xCDCDCDCD (新たに割り当てられたメモリを初期化するパターン) をゼロにするトリガーが必要です。デバッグビルドであっても、この方法で厄介な初期化害虫を簡単に吸い出すことができると思います。
これを可能にする利用可能な CRT フック (API、レジストリ キーなど) がありませんか? そこにたどり着くための他のアイデアはありますか?
[編集:]説明が整っているようです。
- 通常のマジック ナンバーには確かに多くの利点がありますが、bool の初期化 (常に true)、個々のビット マスクに対してテストされるビット フィールド、または同様のケースをカバーしていません。一貫したゼロ初期化 (もちろん、オンとオフを切り替えることができます) は、他の方法ではまれな初期化動作の悪さを表面化させる可能性があるテストのレイヤーを追加します。
- もちろん、私はCrtSetAllocHookを知っています。このように設定されたフックは、割り当てられたバッファーへのポインターを受け取らない (そのようなバッファーが割り当てられる前に呼び出される) ため、それを上書きすることはできません。global new をオーバーロードしても、有効なコンストラクターの初期化が上書きされるため、あまり効果がありません。
[編集:] @Michael、new をオーバーライドする意味がわからない。次のような単純なコード -
動作しません。::new コード全体を貼り付けて変更するとうまくいくかもしれませんが、ちょっと怖いようです (神は、実行するために #include してリンクする必要があることだけを知っています)。