最近重構某項目過程中發現的,有同事反饋調試不正常,很久以前也發生過,雖然搜索了一下找到解決方案,但個人覺得還是有必要再記錄一下。 調試某CS結構的應用程式,大致效果可以看下圖: 我們組最終解決方案是:將編譯的目標平臺設置為X64而不是AnyCPU或者X86。 這個問題,我在前廠開發過一個OCR(光學 ...
最近重構某項目過程中發現的,有同事反饋調試不正常,很久以前也發生過,雖然搜索了一下找到解決方案,但個人覺得還是有必要再記錄一下。
調試某CS結構的應用程式,大致效果可以看下圖:
我們組最終解決方案是:將編譯的目標平臺設置為X64而不是AnyCPU或者X86。
這個問題,我在前廠開發過一個OCR(光學字元識別)客戶端工具,記得非常清楚,因為當時折騰了很久才找到解決方案。
開發這個工具的過程中,碰到的問題是,無法LoadLibrary,因為我調用的自動識別庫是第三方發佈出來的,要調用這個三方庫(要配合DllImport),我原來以為直接COM組件引用就可以了。
但是實際開發的時候,發現GetLastError返回的code為193,MSDN的解釋是:%1 is not a valid Win32 application.
調試的時候,和上面提到的“應用程式中斷模式“一樣效果。
反覆調試實驗後,最終解決方案是:將編譯的目標平臺設置為X86而不是AnyCPU或者X64。
我想要知道調試發生中斷的原因,想起我們組最近引用了架構部編譯生成的一個庫,目標平臺是X64,而那個OCR自動識別庫,大膽推斷目標平臺可能是X86。
下麵就是本文得出的最終結論:
如果你的應用引用了二方庫或者三方庫,一定要註意dll生成的目標平臺,否則調試時就可能會報“應用程式中斷模式”錯誤。