在關閉我的.NET應用程序時，我在DBEXPSDA40.DLL（Dev Art MS SQL Server dbexpress驅動程序）中發現訪問衝突。我的應用程序（VB.NET）調用Delphi寫的COM服務器，它使用dbexpress連接到SQL Server。在Visual Studio中使用和不使用調試時，.NET程序的行爲有何不同？
如果我做同樣的事情，但我的主機應用程序是本機Delphi應用程序或Excel VBA，那麼我沒有看到A/V。我也沒有看到它，如果我在VS IDE中運行VB.NET應用程序進行調試。
我已在A/V追查到在dbExpress的單元中的最後完成子句，它負責關停驅動器（在這種情況下爲兩個，一個用於SQL服務器，另一個用於SQL Server精簡）
的如果我能弄清楚在.NET環境下調試和不調試的區別，我可能知道在哪裏可以看得更遠。
您的區別在於內存佈局。
有很多影響過程的微妙因素。首先，在調試器下，JIT生成稍微不同的代碼（以適應調試器）。根據您的調試器設置，Visual Studio可能還會在您的過程中注入一些其他代碼（例如.vshost.exe）。調試器也會影響時序，並可能反過來暴露競爭條件和/或改變分配內存的方式。長話短說，在應用程序關閉時，最終會以[稍微或顯着]不同的內存佈局結束。顯然，對於不同的主機應用程序也是如此。
但這只是故事的一面。另一方面是dbexpress中存在一個錯誤。或者，也許某些其他模塊導致dbexpress數據中的內存損壞。無論哪種方式，dbexpress最終訪問一些隨機地址。
而且這種地址在一種情況下恰好在未分配的內存頁上，但在其他情況下恰好在分配的內存頁上（因爲內存佈局不同，請記住？）。而在後一種情況下，dbexpress只是從內存中讀取值，對它做些什麼，顯然對結果感到滿意，並且優雅地退出。
這個（與無法追蹤的競爭條件一起）是未成熟編寫的非託管代碼（這是我的經驗表明，在涉及Delphi的情況下通常是這種情況）非常常見的問題。
解決方案？改變條件。 你可以嘗試不同的機器。或者在同一臺機器上，但負載很重。或者加載一些更多的模塊。或者不要加載你通常做的一些模塊。玩吧。
這就是說，你真正的個人永遠不會這樣。它只是在大海撈針中尋找，永不結束，在情感上耗盡冒險。另外，您在其他地方獲得AV的可能性很高（但由於相同的根本原因）。
另一個（也是更好的）選項是調試打印。也就是說，如果你有dbexpress的源代碼（對不起，我不熟悉它）。否則，我會先從Delphi組件的非常仔細的代碼審查開始。也可能在那裏調試打印。
祝你好運。
主機應用程序可能隱藏了您的異常。關機錯誤是最難的。添加一些日誌記錄以查看調試器分離時是否發生異常。
我很確定主機應用程序不隱藏錯誤，我可以在Delphi中調試自動化dll，並且當我通過調試啓動主機時，違規行可以正常工作，但是當我在VS之外啓動它時沒有問題。 – Steve 2010-02-24 00:21:48
AV可以隱藏，但並不意味着它不存在。你如何檢查它？ – Torbins 2010-02-24 17:14:15
我可以跟蹤（在德爾福）通過最終確定，並且驅動程序（指針）的句柄是有效的，當它工作，而不是當它不 – Steve 2010-02-24 22:42:42