問題タブ [mixed-mode]

.NET サポートを C++ アプリケーションに統合しています。
これは昔ながらの MFC アプリケーションであり、CWinFormsControl を参照する "/clr" オプションを使用してコンパイルされた 1 つの追加ファイルがあります。

リンカー フラグ "/NODEFAULTLIB" を削除することはできません。
(Visual Studio ではなく、独自のビルド管理システムを使用しています。)
つまり、必要なすべてのライブラリ (VC ランタイムと MFC) を指定する必要があります。

その他のコンパイラ オプションには、「/MD」が含まれます

次に: リンカー フラグ "/FORCE:MULTIPLE" を使用できず、すべてを追加するだけです
。重複しないライブラリ セットを探しています。

マネージド/アンマネージド環境 (Visual Studio と ReSharper) が混在しており、CCW または RCW リークが疑われます。現在割り当てられているすべてのラッパーをダンプして、ソース/ターゲットを特定する方法はありますか? WinDbg、SOS、SOSEx があるので、!syncblk コマンドで RCW と CCW の合計数を確認できます。私はただオブジェクトを見たいだけなので、オブジェクトに対して !gcroot を呼び出して、そうでなければ容疑者を調べることができます。

さて、大量の調査を行い、見つけることができるほぼすべての管理された CPP Redist を試し、DLL をアプリの実行ディレクトリにローカルにコピーしようとした後、この混合モード ライブラリに欠けている依存関係を特定できません。

基本的に、大規模な C# アプリケーションがあり、作成した混合モード ライブラリを使用しようとしています。開発マシンでは (もちろん) 完璧に動作しますが、CRT の依存関係がないために例外を使用するためにライブラリをロードする必要がある場合に展開されます (私は推測します)。

依存関係ウォーカーを使用して、参照されているすべての DLL をチェックし、それらが展開マシン上に存在することを確認しました。 .

コードが混合モード ライブラリからクラスをインスタンス化しようとすると、次の例外が発生します。

例外の詳細: System.IO.FileLoadException: ファイルまたはアセンブリ 'USADSI.MAPI、Version=1.0.3174.25238、Culture=neutral、PublicKeyToken=null' またはその依存関係の 1 つを読み込めませんでした。アプリケーションの構成が正しくないため、このアプリケーションを開始できませんでした。アプリケーションを再インストールすると、この問題が解決する場合があります。(HRESULT からの例外: 0x800736B1)

/clr:oldSyntax を指定して VS2008 SP1 を使用してライブラリをコンパイルしています。

中間マニフェストは次のようになります。

必要に応じてさらに情報を提供できますが、残念ながら私は混合モード ライブラリの作成に精通していないため、これは私を失望させました。

誰かがアドバイスを提供できれば、私は非常に感謝しています!

プログラムをC＃で起動すると、アンマネージC++が呼び出されます。

管理されていないC++で行を分割すると、[新しいデータブレークポイント]メニュー項目がグレー表示されます。

とにかくこれの周りにありますか？

誰かがこれで私を助けてくれることを願っています。私は主に C# 開発者なので、C と C++ のスキルは低いです。私は、より大きなアプリケーションのプラグインであるネイティブ C dll を持っています。gccを使用して、Linux上のWindows用にこのdllをクロスコンパイルします。

D3DSurface を作成するときにネイティブ dll で、混合モード C++ dll で関数を呼び出し、Hwnd/ハンドルと共にサーフェスへのポインターを渡したいと考えています。その混合モード C++ は、私の C# マネージ コードを呼び出す必要があります。

例として、CI で次のことを行いたいとします。

C# では、これを混合モード アセンブリから呼び出したい

私は C++ が苦手なので、混合モード dll のコーディングに必要なものの例を誰かが教えてくれるかどうか知りたいだけです。また、混合モードのdllをdirectxヘッダーでコンパイルする必要がないようにしたいので、「C」LPDIRECT3DSURFACEを汎用ポインターにキャストする方法はありますか? C# では、とにかく IntPtr を使用します。

私はDllと共にプロジェクトを構築しています。

Dll はネイティブ コードをサポートする必要があるため、/clr として宣言しました。私のプロジェクトは最初は /clr プロジェクトでもあり、すべて問題ありませんでした。ただし、いくつかの NUnit テストを含めたいので、メイン プロジェクトを /clr から /clr:pure に切り替える必要がありました。

すべては引き続きコンパイルされますが、Dll 呼び出しで実行時エラーが発生します。/clr に戻ると、すべて問題ありません

私のDLLでは、エクスポートされた関数は次のように宣言されています：

エクスポートされたすべての関数の実際の名前を含む .def ファイルも作成しました

私のメインプロジェクトから、私のインポートは次のように宣言されています:

誰もそのような問題に遭遇したことがありますか?

Visual Studio 2005 で C++ 混合 (マネージ/アンマネージ) プロジェクトをデバッグしていると、次のようなデバッグ ウォッチから奇妙なデータを取得することがよくあります:
(ところで、変数i_processNameはconst std::string &)

代替テキスト http://img175.imageshack.us/img175/3561/43419953av1.jpg

変数は実際には有効なデータを保持していることに注意してください。標準出力に出力すると、出力された文字列は問題ありません。お問い合わせいただきありがとうございます。より単純なタイプのデータ ( ints など) (通常は?) は、正しい値が表示されます。

これはあなたにも起こったことがありますか？

これはデバッグ時の主要な PITA です。そのため、時計に正しいデータを表示させる方法についてのアイデア、またはこれの原因は何ですか?

状況は次のとおりです。

バックグラウンド

Visual Studio 2008 で開発された混合モードの .NET/Native アプリケーションがあります。

混合モードとは、ネイティブ C++ ライブラリを呼び出す C++ .NET でフロント エンドが記述されていることを意味します。ネイティブ コードは、必要に応じて新しいスレッドを開始するなど、アプリ内の作業の大部分を行います。.NET コードは、UI のみを目的としています (win フォーム)。

テスターのコンピューターで実行されているアプリケーションのリリース ビルドがあります。

ネイティブ ライブラリは完全に最適化された状態でコンパイルされていますが、デバッグも有効になっています (「デバッグ情報形式」は「プログラム データベース」に設定されています)。

これが意味することは、アプリケーションのデバッグ シンボルが PDB ファイルにあるということです。

問題

とにかく、テスターの 1 人が、XP で時折クラッシュするというアプリの問題を抱えています。ワトソン博士を数回実行して、クラッシュのミニダンプを取得できました。

(ミニダンプを使用して - 実際のアプリを実際にデバッグしているわけではありません) デバッグすると、すべてのデバッグ シンボルが正しく読み込まれます。すべてのネイティブ スレッドの完全なスタック トレースが正しく表示されます。他のスレッド (おそらく .NET スレッド) にはスタック トレースはありませんが、少なくともスレッドが開始された dll (つまり ntdll.dll) をすべて示しています。

失敗したスレッドを正しく報告します (「user(5).dmp の 0x0563d652 で未処理の例外: 0xC0000005: アクセス違反の読み取り場所 0x00000000)。

ただし、スレッドに入ると、有用なものは何も表示されません。スタック トレースには、メモリ アドレス "0563d652()" ("ntldll.dll" でさえない) を持つ単一のエントリがあります。

逆アセンブリに入ると、約 30 命令のランダムなセクションが表示されます。メモリ アドレスの両側は、"???" だけです。ソース コードの一部ではないように見えます (バイナリがメモリに順番にロードされていませんか? アセンブリ ステートメントのランダムなセットがどこにもないのは普通のことですか?)。

私の質問

したがって、基本的に私の質問は3倍です。

1) デバッガーの情報不足について説明できる人はいますか?

2）念頭に置いて、コードでエラーが発生したことを示すことはできません。誰かが失敗の理由を提案できますか

3) 将来、この現在の問題を診断するために何か他にできることはありますか?

ヘルプ！

ジョン

アップデート：

これは、WinDBG からの失敗したスレッドのスタック ダンプです。

変でしょ？DLLすら表示されません。

何らかの理由でスタック/ヒープが破損し、スレッドが破損した可能性はありますか?

私が取り組んでいるプログラムは、3rdPartyLibrary.lib に静的にリンクされています。

同じ 3rdPartyLibrary の新しいバージョン、たとえば 3rdPartyLibraryNewVersion.lib を利用したかったのです。

したがって、3rdPartyLibraryNewVersion.so を動的にリンクされたライブラリとして含めることを決定し、wrapper.so と呼ばれるラッパー動的ライブラリを介して含めます。3rdPartyLibrary の新しいバージョンと古いバージョンの両方を同時に使用したいと考えていますが、プログラムの別のパーティで使用します。

私たちが持っている解決策は、古い 3rdPartyLibrary を静的にリンクし、ラッパー ライブラリに動的にリンクして、同時に 3rdPartyLibraryNewVersion にリンクすることです。

プログラム --- 静的にリンク ---> 3rdPartyLibrary.lib. --- 動的にリンク --> wrapper.so --- 動的にリンク ---> 3rdPartyLibraryNewVersion.so.

これは可能ですか？

私たちが遭遇した問題は、wrapper.so がテスト実行可能ファイルで動作する一方で、3rdPartyLibrary.lib に静的にリンクされているプログラムからラッパーが呼び出されると、3rdPartyLibraryNewVersion.so 内で失敗することです。

私は何か悪いことをしましたか？

コードを 3rdPartyLibrary.lib に更新するのが正しい方法であることはわかっていますが、面倒です...

ありがとう、

ティム

This is actually a solved problem, but it's so esoteric I thought I'd share it for other users.

Also perhaps others might suggest reasons?

Anyway, I'm working on a "mixed mode" .NET application written in managed C++, but with heavy links into existing native libraries.

The problem was, unhandled managed exceptions ended up as Win32 Access Violations. What I mean by this is that instead of showing the nice .NET dialog one gets with an unhandled managed exception, instead I would get the older style "Unhandled win32 exception occurred in..." message.

Here's the interesting thing: if I start the app in the debugger, then the thrown managed exception gets correctly picked up. i.e., the debugger shows me the line.

However, when executing normally, it would turn into this Access Violation. Attaching the debugger at that point would produce little useful information (it wouldn't even show a sensible stack trace).

So, to me it suggests that something is happening in native code just before the unhandled managed exception reaches the exception handler.

So anyway, I managed to solve the issue by comparing my project to a clean new C++ managed project generated by Visual Studio 2008.

The fix was to do the following:

1. Change the /SUBSYSTEM flag (Project properties->Linker->System->SubSystem) from /SUBSYSTEM:WINDOWS to "Not Set"

2. Switched from using old style WinMain() to using the new style main().

i.e. it used to be

And it is now

[Why am I using this weird _tWinMain? This was what got generated by the Visual Studio .NET IDE many years ago when you create a sample mixed mode Windows app. It's always worked fine (until now) so I never bothered changing it. _tWinMain is just a macro to WinMain]

I made this change and the problem disappears. Unhandled .NET exceptions now get properly trapped so I can now actually debug them.

I also made the inverse change to the clean sample C++ app and proved that it was the cause.

So, really my questions is, what the heck is going on?

Was it just that I was using the old style WinMain instead of the new main(array <String^>^)?

Should I maybe report this to Microsoft (will anyone care ;-) )?