VS2019利用Debug調(diào)試代碼解決0xC0000005: 讀取位置 0x0000000000000000 時(shí)發(fā)生訪問沖突
之前一直是使用release發(fā)布代碼模式進(jìn)行程序編譯，前天突然出現(xiàn)這個(gè)問題：

0xC0000005: 讀取位置 0x0000000000000000 時(shí)發(fā)生訪問沖突

查找資料發(fā)現(xiàn)大概率是出現(xiàn)了空指針。沒有判斷指針是否為空就進(jìn)行后續(xù)操作導(dǎo)致的錯(cuò)誤，但是release模式并沒有提示問題出現(xiàn)在哪里，只是顯示程序崩掉，并且給你錯(cuò)誤信息，查找資料后發(fā)現(xiàn)Release 稱為發(fā)布版本，它往往是進(jìn)行了各種優(yōu)化，使得程序在代碼大小和運(yùn)行速度上都是最優(yōu)的，以便用戶很好地使用，但是會(huì)忽略調(diào)試信息，這不利于我們進(jìn)行程序調(diào)試。（所以我只憑借經(jīng)驗(yàn)進(jìn)行初步調(diào)試，但是效率很低也沒有解決實(shí)際問題）

而debug配置能夠包含調(diào)試信息，并且不作任何優(yōu)化，便于程序員調(diào)試程序。

這就方便我們進(jìn)行程序的調(diào)試和斷點(diǎn)設(shè)置，設(shè)置了斷點(diǎn)就可以看到所有變量的信息。就方便我們找到問題出現(xiàn)在了哪里。

果然，當(dāng)我將配置改為debug后，運(yùn)行程序，就會(huì)自動(dòng)顯示下圖所示地方發(fā)生錯(cuò)誤：為nullptr，空指針。那么問題就顯而易見了。

但是我在上句語句中已經(jīng)獲得了pGalvanometer對(duì)象指針，這里不應(yīng)該是nullptr。所以我在該位置設(shè)置斷點(diǎn)，運(yùn)行后，發(fā)現(xiàn)hr不為S_OK，而是顯示加載有問題，那么很顯然問題出在我加載外部組件COM中了。

但是我并沒有改變COM組件的加載代碼，于是認(rèn)為可能組件注冊(cè)出現(xiàn)問題。于是我重新注冊(cè)了一下COM組件。

問題成功解決！

該次經(jīng)歷給我的經(jīng)驗(yàn)就是在編寫調(diào)試代碼時(shí)要及時(shí)切換為Debug模式，因?yàn)镈ebug會(huì)保留調(diào)試信息，而且代碼是原汁原味的，不會(huì)做任何改變，也方便我們進(jìn)行調(diào)試。我本身并不是計(jì)算機(jī)專業(yè)，所以這些很基礎(chǔ)的經(jīng)驗(yàn)對(duì)我來說也幫助甚大。

到此這篇關(guān)于利用Debug調(diào)試代碼解決0xC0000005: 讀取位置 0x0000000000000000 時(shí)發(fā)生訪問沖突問題的文章就介紹到這了,更多相關(guān)Debug調(diào)試代碼解決0xC0000005內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！