開發環境為VS2013,作業系統是Win10家庭版。在VS中,配置Release模式,直接運行的話,程式可以正常運行,但是雙擊Release生成的exe檔案,會有很大的概率(不是每次都會出現)程式在運行部分代碼后就會卡死,然后閃退,沒有任何錯誤提示資訊,程式出現閃退的位置也不固定。直接運行Debug生成的exe檔案則不會出現這個現象,可以正常運行。查看網上的方法,如果把Release生成的exe程式設定為兼容模式下(Win7或Win8)運行,也不會出現閃退的問題。但是設定兼容模式并非完美的解決方法。
請問誰知道產生這種現象的根本原因是什么?能否徹底解決這個問題?
注:代碼中的中文注釋都已經刪掉了,基本排除因編碼原因導致部分代碼未進行編譯。
uj5u.com熱心網友回復:
我軟體里面全部是中文變數中文函式就沒發現有運行錯誤退出的情況。uj5u.com熱心網友回復:
增加日志功能定位錯誤位置
uj5u.com熱心網友回復:
通過查看系統日志,顯示的錯誤模塊名稱是 ntdll.dll,例外代碼0xc0000374uj5u.com熱心網友回復:
看起來是,還是和陣列或者記憶體溢位相關visual studio呼叫的時候有一些保護措施, 直接運行的時候失去除錯的環境的支持了
用dump檔案,來查找吧
uj5u.com熱心網友回復:
導致錯誤的代碼找到了。程式里為了加載名稱不確定的dll,定義了一個LPCWSTR型別的變數,初始化為NULL。其值通過一string字串獲取。之前從網上找了一個string轉換為LPCWSTR函式,
LPCWSTR stringToLPCWSTR(std::string orig)
{
size_t origsize = orig.length() + 1;
const size_t newsize = 100;
size_t convertedChars = 0;
wchar_t *wcstring = (wchar_t *)malloc(sizeof(wchar_t)*(orig.length()-1));
mbstowcs_s(&convertedChars, wcstring, origsize, orig.c_str(), _TRUNCATE);
return wcstring;
}
呼叫這個函式時,會有一定概率出現錯誤,現象如前文所述。將呼叫這個函式的代碼注釋掉,直接運行Release生成的exe,沒有出現閃退的現象。不過具體的原因還沒看出來,哪位大佬給指點下?
部分代碼:
LPCWSTR lpcDllName=NULL;
string str="xxxxxxxx";
lpcDllName=StringToLPCWSTR(str);//這條陳述句導致的程式出錯
HMODULE h=LoadLibrary(lpcDllName);
uj5u.com熱心網友回復:
wchar_t *wcstring = (wchar_t *)malloc(sizeof(wchar_t)*(orig.length()-1));是加1 吧
uj5u.com熱心網友回復:
size_t origsize = orig.length() + 1;const size_t newsize = 100;
size_t convertedChars = 0;
wchar_t *wcstring = (wchar_t *)malloc(sizeof(wchar_t)*(orig.length()-1));
mbstowcs_s(&convertedChars, wcstring, origsize, orig.c_str(), _TRUNCATE);
return wcstring;
uj5u.com熱心網友回復:
確實,改成+1就對了。多謝樓上!這是另一種轉換的方式,好像沒發現問題。他就是+1的。
string image_path = "c:\\avi.png";
size_t size = image_path.length();
wchar_t *buffer = new wchar_t[size + 1];
MultiByteToWideChar(CP_ACP, 0, response->image_path.c_str(), size, buffer, size * sizeof(wchar_t));
buffer[size] = 0; //確保以 '\0' 結尾
::MessageBox(NULL, buffer, NULL, NULL);
delete buffer;
buffer = null;
uj5u.com熱心網友回復:
懷疑那個 -1 是不是你輸入代碼輸入錯了否則就是原作者挖的一個坑,專門收拾你這種復制粘貼不自己想為啥的人。

uj5u.com熱心網友回復:
網上復制粘題的代碼有坑的真多很多大部分都是屬于示范性的代碼,沒有自己的測驗過的, 拿來主義不是很靠譜
uj5u.com熱心網友回復:
就是從這里拷貝過來的
https://www.cnblogs.com/tsh292278/p/10522931.html
uj5u.com熱心網友回復:
這個問題真的很隱蔽,在VS里直接運行正常、在Debug里直接運行正常、Release里的exe以兼容模式運行正常,最頭疼的是出現這個問題是隨機性的,不僅僅是否出錯隨機,就連出錯的位置都是隨機的,程式啟動程序中不確定會運行到哪里就閃退,即使正常啟動了,程式退出時又是也會出錯uj5u.com熱心網友回復:
windows下的 MByte和Unicode(2位元組)真是坑爹,tchar.h里搞了一堆_T(),不設定好代碼頁還會報錯。這種機質使得大量的API都有兩個版本,一個char * ,一個wchar *,然后外部再用宏統一介面,搞出一堆 LPCTSTR,C/C++的名聲就是這樣被敗壞了。究其原因,還是因為windows出現的很早,windows 3.1時代,對國際化支持還很不完善,UTF-8等等終極方案還不成熟。后來為了向下兼容,一步步就成了現在這個樣子了。Linux出現的晚,現在如果你使用windows下的Linux子環境,或者是msys2等第三方的API,就全是UTF-8的,沒有這個問題。在原生Linux下也沒有問題。
目前我終極解決方案是用 msys2 下的Qt,以及 Qt 的預言家,全部用UTF-8就沒問題。Qt+VC更坑爹,如果源代碼的字符型別不匹配,界面按鈕用中文都是亂碼。
uj5u.com熱心網友回復:
為什么縮小擴大有軟健不好使用這個功能轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/130847.html
標籤:C++ 語言
