.NET アプリケーションを終了すると、DBEXPSDA40.DLL (Dev Art MS SQL Server dbexpress ドライバー) でアクセス違反が発生します。私のアプリケーション (VB.NET) は、dbexpress を使用して SQL Server に接続する Delphi で記述された COM サーバーを呼び出します。
同じことを行っても、ホスト アプリケーションがネイティブの Delphi アプリケーションまたは Excel VBA である場合、A/V が表示されません。また、VS IDE でデバッグを使用して VB.NET アプリケーションを実行しても表示されません。
A/V を dbexpress ユニットのファイナライズ句まで追跡しました。これにより、ドライバーが閉じられます (この場合、SQL サーバー用と SQL Server Compact 用の 2 つ)。
.NET 環境でデバッグを行う場合と行わない場合の違いがわかれば、どこを調べればよいかわかるでしょう。
あなたの違いはメモリレイアウトです。
プロセスに影響を与える微妙な要因がたくさんあります。1 つには、デバッガーの下で、JIT は (デバッガーに対応するために) わずかに異なるコードを生成します。デバッガーの設定によっては、Visual Studio がプロセスに他のコードを挿入することもあります (.vshost.exe など)。デバッガーもタイミングに影響を与える可能性があり、競合状態が発生したり、メモリの割り当て方法が変更されたりする可能性があります。
簡単に言うと、アプリケーションを閉じるまでに、[わずかにまたは大幅に] 異なるメモリ レイアウトになります。もちろん、別のホスト アプリケーションでも同じことが言えます。
しかし、それは話の一面にすぎません。反対側は、dbexpress にバグがあることです。または、他のモジュールが dbexpress のデータのメモリ破損を引き起こしている可能性があります。いずれにせよ、dbexpress はランダムなアドレスにアクセスすることになります。
そして、そのアドレスは、ある場合には割り当てられていないメモリ ページにあり、別の場合には割り当てられたページにあります (メモリ レイアウトが異なるため、覚えていますか?)。後者の場合、dbexpress は単にメモリから値を読み取り、それに対して何らかの処理を行い、明らかに結果に満足して終了します。
これは (追跡不可能な競合状態と共に) 未熟に書かれた管理されていないコードで非常に一般的な問題です (私の経験から、Delphi が関係している場合は非常によくあるケースです)。
ソリューション？条件を変更します。別のマシンで試すことができます。または、同じマシン上で、負荷が高い場合。または、さらにいくつかのモジュールをロードします。または、通常行う一部のモジュールをロードしないでください。それで遊びます。
そうは言っても、あなたの個人的には決してそのようにはなりません。干し草の山の中からピンを探すだけで、終わることのない、感情を消耗させるような冒険になります。さらに、別の場所で AV を取得する可能性が高くなります (ただし、根本的な原因は同じです)。
もう 1 つの (そしてより良い) オプションは、debug print です。つまり、dbexpress のソース コードをお持ちの場合です (申し訳ありませんが、よくわかりません)。
それ以外の場合は、Delphi コンポーネントの非常に慎重なコード レビューから始めます。そしておそらくデバッグ印刷もあります。
幸運を。
ホスト アプリケーションが例外を隠している可能性があります。シャットダウン エラーは最も困難です。ロギングを追加して、デバッガーがデタッチされたときに例外が発生するかどうかを確認します。