其原因可能是堆被損壞，這也說明 TestMySticker.exe 中或它所加載的任何 DLL 中有 bug。
想了半天以爲是自己的寫法有問題，後終於在google上找 到了原因，汗。。。
一個模塊一個堆，一個線程一個棧。
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。
以下是CSDN上的討論，同樣討論的很詳細了
以上是在網上找到的資料,今天做過詳細測試,結果如下:
測試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的設置不能隨意修改。所以若有涉及到這種問題的，最好的辦法還是在 哪個模塊分配的就在哪個模塊釋放最好，要不然反倒會引來更多的麻煩。
from
http://blog.csdn.net/blz_wowar/archive/2008/03/13/2176536.aspx
上面這文章是我在找“...其原因可能是堆被損壞，這也說明 **.exe 中或它所加載的任何 DLL 中有 bug。”解決辦法的時候找到的，學到一點，呵呵。可惜我那工程的直接原因並不是因爲上面所說的(也許間接原因是)，我的工程裏是開啓一個UI線程，UI 線程中有一個view，結果單步調試時報錯“...其原因可能是堆被損壞，這也說明 **.exe 中或它所加載的任何 DLL 中有 bug。”，最後解決辦法是，view需要用new創建，不能直接通過create來創建，原因是view應該是建在堆上
==========
→配置屬性→C/C++→代碼生成→運行時庫 可以採用的方式有：多線程(/MT)、多線程調試(/MTd)、多線程DLL(/MD)、多線程調試DLL(/MDd)、單線程(/ML)、單線程調試(/MLd)。
Reusable LibrarySwitchLibraryMacro(s) DefinedSingle Threaded/MLLIBC(none)Static MultiThread/MTLIBCMT_MTDynamic Link (DLL)/MDMSVCRT_MT and _DLLDebug Single Threaded/MLdLIBCD_DEBUGDebug Static MultiThread/MTdLIBCMTD_DEBUG and _MTDebug Dynamic Link (DLL)/MDdMSVCRTD_DEBUG, _MT, and _DLL
其中以小寫“d”結尾的選項表示的DEBUG版本的，沒有“d”的爲RELEASE版本。大型項目中必須要求所有組件和第三方庫的運行時庫是統一的，否則將會出現井噴。
單線程運行時庫選項/ML和/MLd在VS2003以後就被廢了。
/MT和/MTd表示採用多線程CRT庫的靜態lib版本。該選項會在編譯時將運行時庫以靜態lib的形式完全嵌入。該選項生成的可執行文件運行時不需要運行時庫dll的參加，會獲得輕微的性能提升，但最終生成的二進制代碼因鏈入龐大的運行時庫實現而變得非常臃腫。當某項目以靜態鏈接庫的形式嵌入到多個項目，則可能造成運行時庫的內存管理有多份，最終將導致致命的“Invalid Address specified to RtlValidateHeap”問題。另外託管C++和中不再支持/MT和/MTd選項。
/MD和/MDd表示採用多線程CRT庫的動態dll版本，會使應用程序使用運行時庫特定版本的多線程DLL。鏈接時將按照傳統VC鏈接dll的方式將運行時庫MSVCRxx.DLL的導入庫MSVCRT.lib鏈接，在運行時要求安裝了相應版本的VC運行時庫可再發行組件包（當然把這些運行時庫dll放在應用程序目錄下也是可以的）。 因/MD和/MDd方式不會將運行時庫鏈接到可執行文件內部，可有效減少可執行文件尺寸。當多項目以MD方式運作時，其內部會採用同一個堆，內存管理將被簡化，問題也能得到緩解。
結論：/MD和/MDd將是潮流所趨，/ML和/MLd方式請及時放棄，/MT和/MTd在非必要時最好也不要採用了。
選項說明
/MD
使應用程序使用運行時庫的多線程並特定於 DLL 的版本。定義 _MT 和 _DLL，並使編譯器將庫名 MSVCRT.lib 放入 .obj 文件中。
用此選項編譯的應用程序靜態鏈接到 MSVCRT.lib。該庫提供允許鏈接器解析外部引用的代碼層。實際工作代碼包含在 MSVCR80.DLL 中，該庫必須在運行時對於與 MSVCRT.lib 鏈接的應用程序可用。
當在定義了 _STATIC_CPPLIB (/D_STATIC_CPPLIB) 的情況下使用 /MD 時，它將導致應用程序與靜態多線程標準 C++ 庫 (libcpmt.lib) 而非動態版本 (msvcprt.lib) 鏈接，同時仍通過 msvcrt.lib 動態鏈接到主 CRT。
/MDd
定義 _DEBUG、_MT 和 _DLL，並使應用程序使用運行時庫的調試多線程並特定於 DLL 的版本。它還使編譯器將庫名 MSVCRTD.lib 放入 .obj 文件中。
/MT
使應用程序使用運行時庫的多線程靜態版本。定義 _MT 並使編譯器將庫名 LIBCMT.lib 放入 .obj 文件中，以便鏈接器使用 LIBCMT.lib 解析外部符號。
/MTd
定義 _DEBUG 和 _MT。此選項還使編譯器將庫名 LIBCMTD.lib 放入 .obj 文件中，以便鏈接器使用 LIBCMTD.lib 解析外部符號。
/LD
創建 DLL。
將 /DLL 選項傳遞到鏈接器。鏈接器查找 DllMain 函數，但並不需要該函數。如果沒有編寫 DllMain 函數，鏈接器將插入返回 TRUE 的 DllMain 函數。
鏈接 DLL 啓動代碼。
如果命令行上未指定導出 (.exp) 文件，則創建導入庫 (.lib)；將導入庫鏈接到調用您的 DLL 的應用程序。
將 解釋爲命名 DLL 而不是 .exe 文件；默認程序名成爲 basename.dll 而不是 basename.exe。
除非顯式指定 /MD，否則將暗指 /MT。
/LDd
創建調試 DLL。定義 _MT 和 _DEBUG。
有關
