各種此類錯誤解決辦法的收集：
1.http://www.cnblogs.com/hfzsjz/archive/2010/01/19/1651406.html
情景：C#調用C的dll時出現這個提示
解決辦法：將dll裏函數需要返回的局部變量聲明爲static
2.http://zhidao.baidu.com/question/202392319.html
情景：處理圖片時越界 調用C或C++等直接操作內存的庫文件
解決辦法：參閱BItMap類，有LockBytes()之類的低級操作方法。
3.http://fqctyj.blog.163.com/blog/static/708434552011983216526/
情景：圖像處理，COM開發
解決辦法：
（1）.如果你用了NativeCode的資源，例如：Com、ActiveX；
沒有強制的釋放方法，底層的com組件根據你進程調用組件的次數來控制對象的增加和釋放(對象釋放會延遲，com自身的問題)。
一般是調用強制垃圾回收或ao自帶的回收對象的方法，效果不明顯。這種對象不釋放的情況，通常出現在應用程序反覆調用頻率極高的情況下，調用間隔的時間小於對象回收的速度，將報這種錯誤。通常是自己的程序寫的機構不合理，纔會產生這種情況。自己在程序裏強制釋放COM資源，調用Marshal.ReleaseComObject()方法將不再使用的對象釋放掉並在可能出現異常的地方去Catch，並留下日誌，轉移此異常。
（2）.指示測試的可執行文件與 Windows 數據執行保護功能兼容。
調用dll的程序，在運行時會出現 “嘗試讀取或寫入受保護的內存。這通常指示其他內存已損壞。"有關更多信息，請參 /NXCOMPAT（與數據執行保護兼容）。編譯器中加入了對DEP的安全性檢查，在編譯完後的exe文件中取消NXCOMPAT位可解決該問題editbin.exe /NXCOMPAT:NO myexe
（3）.排除環境因素：例如.net Fx 2.0和 .net Fx 2.0 SP2差距很大的，當然其他環境因素也好考慮在內。
一定要排除開發和部署環境差異引起的問題。 嘗試修改.net 4.5降低爲.net 3.5效果立竿見影 。特別是針對emguCV 3.
（4）.如果是突然出現這個問題，最好是回滾到之前的操作，重做這個操作，例如移除控件，再次添加；
反註冊Com，重新註冊； 如果你安裝了其他插件，卸除這些插件再試一試。
（5）.程序本身的問題。例如：數據庫訪問達到最大的併發量，出現死鎖。或頻繁的寫入和讀取操作，c#的垃圾回收機製造成的，即變量的回收速度大於使用的速度造成的，這樣就需要從新設計算法。
4.我遇到的這個比較奇怪，幸虧做了備份，用原來備份的C++程序重新生成，就能夠使用了。shit.
