先描述下高版本特點：

occt官網釋出了7.3最新版本後，很積極的安裝後，執行是成功的，但是每次關的時候就會出現錯誤。這個問題讓我鬱悶很久，就是覺得哪個配置出了問題，因為前期工程包編譯時間太久，所以我嘗試修改的次數不太久。最近安裝OpenCV時有些部落格說了32位與64位的區別，我查到了vs2010是沒有64位與32位區別的，就看程式碼是怎麼設計的。在使用6.8版本時我選擇的32位debug，在7.3時我也是32位，所以都還是正常的，但是7.3版本里編譯和執行是正常的，關閉的時候就出問題。所以我猜測是這個問題。

重新安裝和編譯，選擇debugX64，編譯後opencascade執行和關閉就正常了。找了一篇比較不錯的部落格講了這個問題。複製在下面，以供參考。簡單來說，就是dll中與exe中執行程式碼後，釋放記憶體出了問題。

---------------------------------------------------------分割線----------------------------------------------------------------------------------------------

一個模組一個堆，一個執行緒一個棧。
dll裡malloc的記憶體，在exe裡free會出錯。

CRT（C執行時期庫）不是使用程序預設的堆來實現malloc（new中呼叫malloc）的，而是使用一個全域性控制代碼 HANDLE _crtheap來分配記憶體的。這個_crtheap是在XXXCRTStartUp（CRT提供的進口點函式）中建立的。 
由於CRT靜態連線，則樓主的DLL裡有也有一個CRT，因此也有一個_crtheap。而在dll中的new使用dll中的_crtheap控制代碼分配 堆，在exe中的delete使用exe中的_crtheap釋放堆，當然失敗！

解決辦法：
1。在DLL中輸出一個函式給EXE呼叫，專門用來釋放由DLL分配的記憶體；
2。用 GlobalAlloc()代替new，用GlobalFree()代替delete；
3。使用單一的堆，分配記憶體使用 HeapAlloc(GetProcessHeap(),0,size)，釋放記憶體使用HeapFree(GetProcessHeap(),0,p)；
4。 把dll和exe的Settings的C/C++選項卡的Code   Generation的Use   Run-time   liberary改成Debug   Multithreaded   DLL，在Release版本中改成Multithreaded   DLL；這樣使用一個CRT了——MSVCRT.DLL。

一開始我的exe使用Single Thread（即靜態連線），dll改成了MultiThread Dll（即動態連線），依然使用兩個CRT，所以失敗。後來將exe改成使用MultiThread Dll後就成功了，因為都使用一個CRT了——MSVCRT.DLL。

以上是在網上找到的資料,今天做過詳細測試,結果如下:

測試1：使用malloc/free組合來分配和釋放記憶體,DLL中使用 malloc分配，exe中使用free釋放。
我建的是Win32 DLL工程, C/C++->Code generation 設定是 Multithread DLL debug, 但是exe工程設定是MultiThread debug,所以不管怎麼樣,總是會拋異常. 這就間接證明了上述的描述是正確的, 若我修改exe工程設定是 MultiThread DLL debug, 那麼malloc/free組合就能很好的工作起來了。

測試2：使用HeapAlloc/HeapFree組合來分配和釋放記憶體，DLL 中使用HeapAlloc分配，exe中釋放。
exe的配置還是MultiThread Debug，DLL中HeapAlloc(GetProcessheap(), HEAP_ZERO_MEMORY, 1024)分配，exe中HeapFree(GetProcessHeap(), 0, p)釋放，,則還是無法正常執行，還是拋異常。若exe中設定成MultiThread DLL debug就正常運行了。

測試3：還是 使用HeapAlloc/HeapFree來進行，但是DLL中匯出一個方法來釋放DLL中分配的記憶體。
若exe配置是MultiThread Debug，無法正常執行，拋異常。若修改成MultiThread DLL debug正常執行。

所以得到的結論如下：
不管 是使用malloc/free組合還是HeapAlloc/HeapFree組合，exe工程均需要設定成MultiThread DLL debug才能正常執行起來的，CSDN上的那個討論在這兒貌似是由出入的，而且DLL的設定不能隨意修改。所以若有涉及到這種問題的，最好的辦法還是在 哪個模組分配的就在哪個模組釋放最好，要不然反倒會引來更多的麻煩。

VC專案屬性→配置屬性→C/C++→程式碼生成→執行時庫 可以採用的方式有：多執行緒(/MT)、多執行緒除錯(/MTd)、多執行緒DLL(/MD)、多執行緒除錯DLL(/MDd)、單執行緒(/ML)、單執行緒除錯(/MLd)。

其中以小寫“d”結尾的選項表示的DEBUG版本的，沒有“d”的為RELEASE版本。大型專案中必須要求所有元件和第三方庫的執行時庫是統一的，否則將會出現LNK2005井噴。

    單執行緒執行時庫選項/ML和/MLd在VS2003以後就被廢了。

    /MT和/MTd表示採用多執行緒CRT庫的靜態lib版本。該選項會在編譯時將執行時庫以靜態lib的形式完全嵌入。該選項生成的可執行檔案執行時不需要執行時庫dll的參加，會獲得輕微的效能提升，但最終生成的二進位制程式碼因鏈入龐大的執行時庫實現而變得非常臃腫。當某專案以靜態連結庫的形式嵌入到多個專案，則可能造成執行時庫的記憶體管理有多份，最終將導致致命的“Invalid Address specified to RtlValidateHeap”問題。另外託管C++和CLI中不再支援/MT和/MTd選項。

    /MD和/MDd表示採用多執行緒CRT庫的動態dll版本，會使應用程式使用執行時庫特定版本的多執行緒DLL。連結時將按照傳統VC連結dll的方式將執行時庫MSVCRxx.DLL的匯入庫MSVCRT.lib連結，在執行時要求安裝了相應版本的VC執行時庫可再發行元件包（當然把這些執行時庫dll放在應用程式目錄下也是可以的）。 因/MD和/MDd方式不會將執行時庫連結到可執行檔案內部，可有效減少可執行檔案尺寸。當多專案以MD方式運作時，其內部會採用同一個堆，記憶體管理將被簡化，跨模組記憶體管理問題也能得到緩解。

    結論：/MD和/MDd將是潮流所趨，/ML和/MLd方式請及時放棄，/MT和/MTd在非必要時最好也不要採用了。

 =======================================================================================

以上是從網路上搜刮過來的東西，但可以從微軟官方文件獲得解釋。

地址http://msdn.microsoft.com/zh-cn/library/ms235460.aspx

Potential Errors Passing CRT Objects Across DLL Boundaries

其中解釋了CRT共享副本的問題，給出了三個例子。微軟搞的東西還真是麻煩。

下面描述下我的問題的來源，

我在自己的機器上使用opencv寫好了程式，想移植到另一臺沒有安裝opencv的機器上執行。

其中，opencv是編譯安裝，生成的是dll檔案，為了達到我的目標，我想當然的在自己編寫的exe中，將CRT選擇為MT。但是問題就來了，編譯即便通得過，每次執行程式到結尾時，都會報堆損壞的錯誤。

具體的原因我猜測是opencv某些動態庫內部執行了申請記憶體空間的操作，而沒有由dll自己顯式地釋放。也就是說，opencv的dll裡面的某些資源是在等到某個物件離開其作用域後由exe呼叫其解構函式釋放，或者作為棧上的區域性變數自動銷燬。當DLL和exe共享CRT記憶體空間時沒有問題。但是一旦兩者分離，exe嘗試釋放dll資源時，就會出現上文所描述的情況。

為了進一步說明這個問題，之後我會再轉載兩篇文章，一篇是CRT的，還有一篇是dll記憶體分配的。這兩篇文章基本可以解答我的疑問了。