如何保護導入的Win32 DLL從內存問題到.NET應用程序

我有一個C＃應用程序需要使用傳統的Win32 DLL。該DLL幾乎是它自己的應用程序，它有對話，與硬件等進行操作。當這個DLL是進口和使用，有一對夫婦的出現的問題：如何保護導入的Win32 DLL從內存問題到.NET應用程序

拖動對話框（而不是Windows 系統對話框，但是由DLL創建的DLL）導致UI不會重新繪製。此外，它會從各種UI 控件中生成一個存儲異常中的系統。
表現令人難以置信的是緩慢。
似乎沒有辦法卸載DLL所以內存從未得到清理。當我們關閉我們的託管應用程序時，我們得到另一個內存異常。

目前，我們導入的每個方法調用這樣：

[DllImport("dllname.dll", 
    EntryPoint = "MethodName", SetLastError = true, 
    CharSet = CharSet.Auto, ExactSpelling = true, 
    CallingConvention = CallingConvention.StdCall)]

來源

2010-05-14 Eric

我假設你已經測試過從非託管代碼調用DLL，它的行爲是否正確？ – egrunin 2010-05-14 20:36:15

是的，我們用託管代碼取代的早期版本是非託管的。 – Eric 2010-05-15 01:19:53

我會創造一個exe包裝（可能非託管）暴露爲您的新應用程序使用的API。

另一種可能的解決方案是創建第二個UI線程來處理麻煩的DLL。不過，我更傾向於使用exe包裝器，因爲這種方法更適合處理OOM（如果需要，您可以重新啓動過程）。

來源

2010-05-14 21:21:38

我認爲這個exe包裝器，但非託管dll必須在託管應用程序相同的過程中被調用。 – Eric 2010-05-14 21:37:14

爲什麼不在同一個過程中？ - 用戶不知道它是否如此 – Mark 2010-05-15 05:40:52

@Mark：如果您的控件中有一個錯誤的組件會崩潰整個過程（例如，使用OOM），那麼exe包裝器就很有用。重新啓動失敗的子進程並不難，幾年前我必須要做一個Oracle客戶端dll，它會讓我們的24x7工廠自動化系統崩潰。用戶沒有看到任何區別，但它對操作系統有很大的影響（不同的exe有自己的內存空間，不會崩潰父exe文件）。 – 2010-05-15 14:00:08

如何保護導入的Win32 DLL從內存問題到.NET應用程序

回答

相關問題