欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

w3wp進(jìn)程發(fā)生死鎖ISAPI aspnet_isapi.dll報告它自身有問題,原因Deadlock detected

 更新時間:2012年09月16日 13:51:13   作者:  
ISAPI c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll 報告它自身有問題,原因如下: Deadlock detected
這個問題,字面意思是程序發(fā)生死鎖了,它會導(dǎo)致w3wp進(jìn)程重啟。通常這個問題不好查到原因。我知道兩個可能導(dǎo)致此問題的實(shí)例

1. 在程序中使用了lock或者ReaderWriterLock,鎖資源發(fā)生了爭用
下面是一小段代碼:

復(fù)制代碼 代碼如下:

//_rwLock的類型是ReaderWriterLock
_rwLock.AcquireWriterLock(100);
DoSomething();
_rwLock.ReleaseWriterLock();


這行代碼是有問題的,如果在DoSomething()方法執(zhí)行中發(fā)生一次異常,這個寫鎖就釋放不了了,再次請求時就會等待直到超時,在多線程的情況下就會發(fā)生死鎖'Deadlock detected'
正確的寫法應(yīng)該是:

復(fù)制代碼 代碼如下:

try
{
_rwLock.AcquireWriterLock(100);
DoSomething();
}
finally
{
if (_rwLock.IsWriterLockHeld)
_rwLock.ReleaseWriterLock();
}


這樣就算在DoSomething方法執(zhí)行時發(fā)生了異常,也可以釋放寫鎖。

2. 數(shù)據(jù)庫連接的超時時間設(shè)置的很長而在設(shè)定的超時時間之內(nèi)連接耗盡了,再次要求打開數(shù)據(jù)庫連接時也可能會出現(xiàn)此問題。這個是數(shù)據(jù)庫連接串的配置問題,超時時間要設(shè)置的適當(dāng),不要過長。

發(fā)生這個問題時的日志寫的很籠統(tǒng):
ISAPI 'c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll' 報告它自身有問題,原因如下: 'Deadlock detected'。

有關(guān)更多信息,請參閱在 http://go.microsoft.com/fwlink/events.asp 的幫助和支持中心。

這樣導(dǎo)致不容易找到問題發(fā)生在哪塊,所以我記錄兩種發(fā)生此問題的實(shí)例,希望有用。

問題分析方法(這個很有必要的)

今天系統(tǒng)突然折了,但是問題在哪呢?很費(fèi)周折。

  錯誤信息:

  ISAPI'c:windowsmicrosoft.netframeworkv2.0.50727aspnet_isapi.dll'報告它自身有問題,原因如下:'檢測到死鎖'。

  有關(guān)更多信息,請參閱在http://go.microsoft.com/fwlink/events.asp的幫助和支持中心。

  癥狀:系統(tǒng)總是不穩(wěn)定,一會能用,一會兒又死掉了。

  分析過程:

  這個版本已經(jīng)跑了很長時間,估計不是程序死鎖的問題。倒底是什么問題呢。應(yīng)該是外部環(huán)境的問題。由于錯誤信息比較的抽象,之前沒有遇到過,所以google了下,但是好像遇到此問題的人很少,不過在博客園還是遇到一位受到同樣遭遇的人,但是并沒有一種很好的解決方案,也沒有確切的指出問題的癥結(jié)。所以只有自己進(jìn)行一些檢查。

  <1>查看最近的系統(tǒng)更新,看是否有關(guān)于IIS之類的更新

  <2>查看系統(tǒng)的殺毒軟件的日志文件,看是否收到了攻擊

  但是,檢查上述兩個步驟,并沒有發(fā)現(xiàn)問題??聪到y(tǒng)是有一些更新,迫于無奈,只好重啟系統(tǒng)試一下(也順便重啟IIS)。重啟之后,問題依舊。

  觀察進(jìn)程管理器,發(fā)現(xiàn):

  W3WP的線程數(shù),一直在變化,一會增加一個高峰值,重新增加一個W3WP進(jìn)程,之前的進(jìn)程過一會就自動關(guān)閉,一會又恢復(fù)正常。

  這說明網(wǎng)站,在不斷的死亡、重啟。到底是哪里的問題呢?應(yīng)該還是系統(tǒng)自己的問題了。但是它自身的版本并沒有問題,為了確定這一點(diǎn),我也試了之前穩(wěn)定的版本,同樣出現(xiàn)此類問題。最后,是否是系統(tǒng)中調(diào)用的第三方服務(wù),將整個系統(tǒng)給拖死了呢?

  罪魁禍?zhǔn)祝航?jīng)過檢查,果然是由于程序中實(shí)時調(diào)用了一個服務(wù),由于此服務(wù)已經(jīng)停止,請求無果,出現(xiàn)了死鎖。

  教訓(xùn):

  <1>最大大限度保證系統(tǒng)與第三方服務(wù)的穩(wěn)定、安全,并在請求過程中做超時判斷、消息分級處理。

  <2>遇到問題,首先應(yīng)全面分析系統(tǒng)的問題可能性,因?yàn)橄到y(tǒng)本身的運(yùn)行環(huán)境一般都是固定不變的,出現(xiàn)問題的可能性很小。

  有的時候在寫程序的時候,如果出了問題,首先應(yīng)該懷疑自己的思路、代碼哪里出了問題,而不應(yīng)該去怪罪IDE或者OS出了什么BUG。這樣你就少走很多彎路。

通過上邊的介紹,我出現(xiàn)此問題的原因是:(在此貼出備注一下)


首選我代碼里沒有用到加鎖代碼(例如:Application.Lock(), Application.UnLock()等);

其次在此問題之前,沒有出現(xiàn)過此問題,并且良好運(yùn)行過很長時間;

最后發(fā)現(xiàn),由于我代碼里調(diào)用c/c++ DLL, 而DLL里要鏈接網(wǎng)關(guān)服務(wù),然后網(wǎng)關(guān)服務(wù)此時沒有開啟,從而出錯,開啟DLL需要的網(wǎng)關(guān)服務(wù),就可以了。

相關(guān)文章

最新評論