問題タブ [msvcrt]

私のシステムでビルドした Visual C++ 2005 は、CRT DLL バージョン 8.0.50727.4053 を使用しています。最新のもので、Windowsによって自動的に更新されたと思います。

ユーザー システムでは、このバージョンの DLL が見つかりません。過去に、インストーラーの一部として vcredist_x86.exe を使用して、ランタイム DLL をインストールしました。以前は機能していました。

私の問題は、最新バージョンの vcredist_x86.exe (Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)) でさえ、このバージョンの DLL をインストールしないことです。

それでは、どの vcredist_x86.exe ファイルが必要ですか?

PS アプリに特定のバージョンの CRT へのリンクを強制すると、問題は解決しますか? それはまったく好ましい方法ですか？

ありがとう、

ポール

更新: vcredist_x86.exe (Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)) が 8.0.50727.4053 をインストールしないことを観察する他の人がいます。

UPDATE2: 少なくとも 1 人が、以前のバージョンの CRT ( http://tedwvc.wordpress.com/ ) の使用を強制することを提案しています。ただし、これにより、プロジェクトが大幅に複雑になります。

Tessnet2を使用するアプリがあります。Init メソッドを呼び出そうとすると、アプリケーションが失敗します。
失敗はひどいものです - 例外 (ANY) も、エラーの痕跡も、「レポートの送信」ウィンドウさえもありません。アプリのプロセスがちょうど削除されました。

問題のあるコードは次のとおりです。

役立つかもしれないいくつかのメモ：

• Tessnet2 には、Visual C++ 2008 ランタイムが必要です。msvcm90.dll か msvcm80.dll かは不明です。
• アプリケーションはデスクトップ WPF です。
• 開発環境: VS 2008 SP、.NET 3.5 SP1
• 以前は機能していました (SOAP Web サービスを使用するために Web 参照を追加したと思いますが、それを削除しようとしても結果はありませんでした)。
• 単体テストは完全に機能しており、障害は発生していません。

これらの観察から、WPF アプリケーション自体に問題があるように思えます。

私が持っている唯一の情報は、デバッグ中の出力です。

そして、アプリが失敗したときの最後のピース:

更新:イベント ログを確認しました。「SideBySide」ソースのエントリはありません。この問題に関連するエントリのみを以下に示しますが、残念ながら多くはわかりません。

ヒントをお寄せいただきありがとうございます。

私、および他の数千人の人々は、Microsoft Visual C++ ランタイムによってスローされるエラーを取得しています。

検索エンジンの利益のために、次のように述べています。

これで、バッファ オーバーランとは何か、なぜそれが悪いことなのかを理解できました。Microsoft が新たに「壊れただけだ」と強調したことを考えると、 MSVCRTの追加のバッファ チェックは便利な機能です。

一方、私は気にしません。プログラムが続行できないのではなく、プログラムが安全に続行できないということです。それは何もないよりはましだからです。私は危険な生活を楽しんでいます。

誰でも何か提案できますか？私は次のようなことを考えていました：

• MSVCRT が実行を停止しないようにするためのレジストリ キー
• 以前のオペレーティング システム (Windows 7 より前) との互換性でアプリケーションを実行する
• アセンブリ マニフェストを実行可能フォルダーに追加して、このオーバーフロー チェックを実行しない古いバージョンの MSVCRT を使用するようにします。
• オーバーフロー チェックを行わない MSVCRT のコピーのバージョン番号またはダウンロード場所

Microsoft Visual C++ ランタイム ライブラリを作成した会社のサポート サイトを検索してみましたが、どの関数がオーバーフローする可能性があるか、またはオーバーフロー チェックを無効にする方法については言及されていません。

次のシナリオを考えてみましょう: アプリケーションがサードパーティのライブラリ A にリンクしています。

A は MSVC 2008 を使用してビルドされ、C ランタイム ライブラリ v9.0 に静的にリンクされています (つまり、/MT でビルドされています)。

アプリケーションは MSVC 2005 を使用して構築され、A および (/MT を使用して) C ランタイム ライブラリ v8.0 に静的にリンクしています。

これには問題があります。たとえば、ランタイム ライブラリのバージョン間でヘッダーの型が変更された場合などです。

バージョン間でランタイム ライブラリ ヘッダーの互換性を維持するように注意していますか?それとも、静的にリンクされたすべてのライブラリが同じバージョンのランタイム ライブラリにリンクしていることを常に確認する必要がありますか?

msvcrt の rand() 関数を使用して 3 つのサイコロの面を生成するプログラムの出力を予測しようとしています。コードは次のようなものだ dice[0] = rand() % 6 + 1; dice[1] = rand() % 6 + 1; dice[2] = rand() % 6 + 1;と思います: 、線形合同ジェネレーターの予測プログラムを使用して、シーケンス内の次の数値を予測できるかどうか疑問に思っていました。

プロジェクトの名前を変更するために長いプロセスを経た後、私の DLL プロジェクトはデバッグ モードでビルドされません (リリース ビルドは機能します)。

このプロジェクトと、それが依存する 5 つのスタティック ライブラリは、「マルチスレッド デバッグ (/MTd)」(C/C++|コード生成|ランタイム ライブラリの下) を使用するように設定されています。LIBCMTD.lib はマルチスレッド デバッグ用のものだと思いますが、MSVCRTD.lib とは何ですか? このエラーの原因は何ですか?

違いがある場合、この DLL は Windows CE 用です。

プロジェクト プロパティ ->c/c++ ->CodeGeneration ->RuntimeLib: MTd (静的 CRT ライブラリ LIBCMTD を使用) を使用して、Visual Studio 2005 でアプリケーションをビルドしています。アプリケーションは、MDd に組み込まれているサードパーティの dll とライブラリを使用しています (動的 CRT lib-MSVCRTD を使用)。

MSVCRTD.lib(MSVCR80D.dll): error LNK2005: __mktime64 already defined in LIBCMTD.lib(mktime64.obj) MSVCRTD.lib(MSVCR80D.dll): error LNK2005: __gmtime64 already defined in LIBCMTD lib(gmtime64.obj) MSVCRTD.lib(MSVCR80D.dll): エラー LNK2005: __localtime64 はすでに LIBCMTD.lib(loctim64.obj) で定義されています

サードパーティの設定を変更できません。CRT ライブラリを動的に使用すると、アプリケーションは正常に動作しますが、これを変更することはできません。

ありがとう

サードパーティの dll とライブラリを使用するプロジェクトを開発しています。「IBM purifier」でアプリケーションを実行したいので、静的 CRT (LIBCMTD) を使用してプロジェクトをビルドしたいと考えています。ただし、サードパーティのライブラリは動的 CRT (MSVCRT) を使用して構築されています。

これにより、次のようなリンク エラーが発生します。 gmtime64.obj) MSVCRTD.lib(MSVCR80D.dll): エラー LNK2005: __localtime64 はすでに LIBCMTD.lib(loctim64.obj) で定義されています

さまざまなリンカー設定を試しました。また、リンカー コマンド ラインに /FORCE:MULTIPLE を指定して、複数の定義を無視してビルドを作成しました。そうしましたが、私のアプリケーションはまだ浄化装置で実行できませんでした。

私が達成しようとしていることを行う良い方法はありますか? サードパーティのソース コードを制御して、その設定を制御することはできません。

ありがとう

多数の DLL を使用する大規模な MFC アプリケーションがあります。ここまでは、vcredist_x86.exe を使用して、MFC と CRT をアンマネージ サイド バイ サイド アセンブリ キャッシュ (C:\Windows\WinSxS) にインストールしてきました。この方法で MFC/CRT をインストールすると、アプリケーションが (クリーンな XP マシンで) 実行されます。

MSDN のドキュメントによると、アプリケーションがインストールされているフォルダーにアセンブリ ファイルをコピーすることで、MFC/CRT をインストールできます。これを単純な MFC アプリケーションでテストしたところ、動作しました。しかし、このアプローチを使用して大規模な MFC アプリケーションを動作させるには問題があります。

この問題は、一部の DLL に以前のバージョンの CRT を参照するマニフェストが含まれていることが原因であると思われます。たとえば、ある DLL には次のマニフェストが含まれています。

CRT アセンブリのバージョン 8.0.50727.762 をアプリケーションのフォルダーにコピーしています。ご覧のとおり、これは CRT の新しいバージョンです。しかし、何らかの理由で、OS ローダーが上記のマニフェストで DLL をロードできません。同じ CRT アセンブリが WinSxS にインストールされている場合、これは発生しません。DependencyWalker を使用して読み込みをトレースすると、エラー LDR: LdrpWalkImportDescriptor() failed to probe c:\documents and settings\qatest\desktop\test\log4cpp.dll for its manifest, ntstatus 0xc0150002 が表示されます

アセンブリの新しいバージョンをロードするローダーの機能は、プライベート サイド バイ サイド アセンブリを使用している場合は機能しないようですが、アセンブリが WinSxS にインストールされている場合は機能します。

これに対する解決策はありますか？

VisualCRTのメモリリーク検出ルーチンを使用してい<crtdbg.h>ます。私が呼び出す_CrtDumpMemoryLeaksと、プログラムのすべての呼び出しで1つの割り当てが一貫して報告されます。

アドレスは異なりますが、{133}常に同じです。

メモリ割り当て番号にブレークポイントを設定する方法に関するMSDNの指示によると、この呼び出しで133番目の割り当てにブレークポイントを設定できるはずです。

また、実際に133に設定されているウォッチウィンドウで確認することもできます{,,msvcr90d.dll}_crtBreakAlloc。プログラムが終了した後も、リークレポートには＃133が（いくつかの高い数値とともに）表示されますが、ブレークポイントは発生しません。なぜこれが発生する可能性があり、ブレークポイントを発生させるにはどうすればよいですか？

潜在的に関連する情報：

1. VS2008、「マルチスレッドデバッグDLL」CRTを使用
2. 私のコードはサードパーティ製品によってロードされるDLLです
3. 「通常の」ブレークポイントは問題なく機能します。ステップスルーは正常に機能します。__asm int 3うまくいきます。
4. の他の値_crtBreakAllocもブレークポイントを引き起こしません（とにかく試したものではありません）
5. ＃133はリークレポートの最小数です