The string binding is invalid. これは、いくつかの C++ ネイティブ スタティック ライブラリと DLL を参照する代わりに、C++/CLI DLL を使用する C# EXE で構成されるかなり複雑なアプリケーションをシャットダウンしようとすると発生します。(VS2013 と Boost 1.55 を使用しています。)
この問題が発生するのは、_atexit(DLL の終了時に) が_t2m@???__Fep@?1???$get_static_exception_object@Ubad_exception_@exception_detail@boost@@@exception_detail@boost@@YA?AVexception_ptr@1@XZ@YAXXZ@?A0x8b93c95f@@YAXXZネイティブからマネージへのサンクである を呼び出そうとしているためです。CLR はおそらくその時点で既にシャットダウンされています。
私の主な質問は、管理されたサンクがネイティブの終了ハンドラーに登録されている理由です。定義上、機能しないためです。関連する質問は、なぜこの型に対してマネージ サンクが生成されるのかということです。私が知る限り、#includeこの型を参照できるものはすべて、コンパイルされていない/clrファイルか、#pragma unmanagedブロック内の/clrいずれかにあるからです。コンパイルされたファイルであるため、管理されたバージョンはまったく存在しないはずです。( のヘルプで#pragma managedは、インスタンス化のポイントではなく、テンプレートが管理されているかどうかを定義するのは定義のポイントであると述べています。)
おそらく私はこれについて間違ってい#includeますが、ファイル内のネイティブ型 (非/clrファイルに実装されている)のヘッダー ファイルを ing するときは、ODR の問題を防ぐためにブロックに/clrラップする必要があると常に想定していました。unmanaged
質問 (私はここで読んだことを覚えていますが、今ではリンクを見つけることができません) は、解決策はすべてのプラグマを削除し、コンパイラにそれを理解させることであることを示唆しています。ただし、それを行うとManaged Debugging Assistant 'LoaderLock' has detected a problem、起動時に発生します。(コール スタックは、C++/CLI DLL をロードする原因となる C# コードを指しているだけなので、まったく役に立ちません。)
この質問は、テンプレートのインスタンス化に関するコンパイラのバグがあることを示唆しています。これがテンプレートであることを考えるとget_static_exception_object、これはもっともらしいように思えますが、回避する方法がわかりません。
同様に誤って登録された別の関数は ですが_t2m@???__FstrMgr@?1??GetInstance@CAtlStringMgr@ATL@@SAPAUIAtlStringMgr@2@XZ@YAXXZ@@YAXXZ、これはテンプレートではないため、ニシンである可能性があります。
(私はより小さな例で問題を再現しようとしましたが、まだできていません。明らかに、私が気付いていないトリガーがあります。)