繼續上次debug的階段

當我們把.NET在作什麼事情丟出來以後

如果要更深入的看裡面的變數也是可以的比方說我要在當下的 thread 裡看詳細是作了哪些事 (Dump Stack Objects)

0:054>!dso

OS Thread Id: 0xaf0 (54)
ESP/REG  Object   Name
15b3e4a8 05ba96a0 Microsoft.Win32.SafeHandles.SafeWaitHandle
15b3e4d0 05b0f710 System.AsyncCallback
15b3e564 01f9befc System.Object[]    (System.Object[])
15b3e570 01f9bf88 System.String    D:xxxCacheAdPV671671_2010101416.txt
15b3e574 01f9beb8 System.String    D:xxxCacheAdPV671
15b3e578 05b78060 System.String    1
15b3e60c 05b0f710 System.AsyncCallback
15b3e620 01f9bf50 System.String    671_2010101416.txt
15b3e634 01b0af64 System.String    D:xxxCacheAdPV
15b3e650 05bab274 System.String    Start
15b3e664 05af01d0 System.String    
15b3e688 01b0af64 System.String    D:xxxCacheAdPV
15b3e68c 01b0b320 System.Configuration.KeyValueInternalCollection
15b3e698 05b10220 System.Text.UTF8Encoding
15b3e6bc 01b09724 System.String    3
15b3e6c0 01b0b320 System.Configuration.KeyValueInternalCollection
15b3e6d0 05b10220 System.Text.UTF8Encoding
15b3e6dc 01f9a708 System.Object[]    (xxx.Data.Advertisement[])

………………………………..

中間 Object 下 8位 16 進制的就是記憶體位址

表示在這個位址裡面放了右邊所執行的命令

針對有些像是陣列或是object, 我們可以繼續下指令去dump看裡面到底包了什麼

共有以下三種指令 da dd do

說實在我並不清楚這三種的差別是什麼, 但最顯而易見的就是下對指令才dump的出來

0:054> !do 01f9a708
Name: System.Object[]
MethodTable: 793042f4
EEClass: 790eda64
Size: 28(0x1c) bytes
Array: Rank 1, Number of elements 3, Type CLASS
Element Type: xxx.Data.Advertisement
Fields:
None
0:054> !da 01f9a708
Name: xxx.Data.Advertisement[]
MethodTable: 793042f4
EEClass: 790eda64
Size: 28(0x1c) bytes
Array: Rank 1, Number of elements 3, Type CLASS
Element Methodtable: 0f867160
[0] 01f998f8
[1] 01f9a6ac
[2] 01f9a650

上面可以看到do拿他沒皮條時我換用da來下, 接著又出現三個address

繼續下指令去扒

0:054> !do 01f998f8
Name: Pushba.Data.Advertisement
MethodTable: 0f867160
EEClass: 0f945078
Size: 92(0x5c) bytes
 (C:WINDOWSMicrosoft.NETFrameworkv2.0.50727Temporary ASP.NET Filesroot141ebe66ccec38aeassemblydl3102e98b9ac990b34_d244cb01xxx.Data.DLL)
Fields:
      MT           Field       Offset            Type         VT     Attr       Value Name
79332d70  4000044       14         System.Int32  1 instance      671 id
79332d70  4000045       18         System.Int32  1 instance        3 venderID
79330b24  4000046        4        System.String  0 instance 01f9983c authKey
79330b24  4000047        8        System.String  0 instance 05af01d0 imageUrl
79330b24  4000048        c        System.String  0 instance 01f9985c navigateUrl
79330b24  4000049       10        System.String  0 instance 01f998c4 alternateText
79332d70  400004a       1c         System.Int32  1 instance        0 impressions
79332d70  400004b       20         System.Int32  1 instance    21907 viewed
79332d70  400004c       24         System.Int32  1 instance        5 clicked
7932a368  400004d       28        System.Single  1 instance 0.010000 valuePerView
7932a368  400004e       2c        System.Single  1 instance 0.000000 valuePerClick
79332d70  400004f       30         System.Int32  1 instance    30000 viewQuota
79332d70  4000050       34         System.Int32  1 instance  1000000 clickQuota
793045f0  4000051       3c       System.Boolean  1 instance        1 enabled
00000000  4000052       40                       1 instance 01f99938 startDate
00000000  4000053       4c                       1 instance 01f99944 endDate
79332d70  4000054       38         System.Int32  1 instance        0 orderID

因為直接貼文字的關係對齊有點亂掉

不過還是可以看出來在這段記憶體裡面擺了什麼東西

欄位從4000044開始, offset為記憶體的偏移植

比較重要的是你可以根據Name跟 Value來檢查到底發生問題時有沒有什麼值出錯了

其實在debug的階段經驗是很重要的

因為我們不可能把這麼多的thread一一分析

有經驗的工程師可以依照其經驗來判斷哪裡可能有問題並快速的驗證

由於我很菜, 這個bug還真花了我不少時間

因此分享一下解決的過程, 希望遇到類似困難的人看到這篇可以減少摸索的時間

首先既然我們不可能去分析所有的thread, 那麼就先來猜出可能搞鬼的是誰

由於每次發生deadlock時總是在線程數60以上

因此我們可以合理的懷疑某個thread死占著資源不放

而這支程式又常常被呼叫到, 導致後面大排長龍

先做一個表格來統計到底發生deadlock時, 到底這60多條thread在幹嘛…

在整理好之後我發現我應該抓出兇手了

程式再讀寫快取的thread竟然占了40條

顯然是因為快取檔案資源占用造成後面陸續要讀寫快取的線程塞爆了

這邊可以對照剛剛dump出來的資訊

0:054> !dso
OS Thread Id: 0xaf0 (54)
ESP/REG  Object   Name
15b3e4a8 05ba96a0 Microsoft.Win32.SafeHandles.SafeWaitHandle
15b3e4d0 05b0f710 System.AsyncCallback
15b3e564 01f9befc System.Object[]    (System.Object[])
15b3e570 01f9bf88 System.String    D:xxxCacheAdPV671671_2010101416.txt
15b3e574 01f9beb8 System.String    D:xxxCacheAdPV671
15b3e578 05b78060 System.String    1
15b3e60c 05b0f710 System.AsyncCallback

有好幾個thread都在吃這支D:xxxCacheAdPV671671_2010101416.txt

然後就在那邊癡癡的等 (System.AsyncCallback)

難怪造成服務的deadlock

幸好在花了這麼多時間後把問題給解了

沒想到網站上遇到的問題也可以memory dump

在debug上來講真的是很有威力

不過整個過程真是有點辛苦, 拜託網站不要再出包了…

大部分的指令參考自 http://www.cnblogs.com/juqiang/category/261813.html

裡面還有很多更進階的指令介紹喔

今天研究了一下用 windbg 來 trace aspnet_wp crash 的狀況

沒想到離開 NB ODM 之後還會用到這個 debug tool

因為整個過程真是有點複雜所以也順便紀錄一下

首先要先去下載微軟的windbg tool

他裡面有一個可以dump的小工具ADPlus

C:Program FilesDebugging Tools for Windows (x86)ADPlus.exe

直接打 adplus 就會有操作說明

我是在系統 hang 時 dump 出 aspnet_wp 這個程序的 dump file

adplus -hang -pn aspnet_wp.exe -o D:dump

再來先開啟 Windbg 並載入 dump file

這時候可能會出現跟我一樣的警告 找不到 Symbol file

請在 FileSymbol File Path 裡面輸入路徑如圖示

路徑可以隨便擺 後面MS的路徑是讓你可以直接下載Symbol回來用的

再來下指令0:000>~

這個指令會把你 dump 時所有的 thread 丟出來

以我的 dump file 來看當時有 62個 thread 在執行

可以用~*s 來切換到你要 trace 的 thread  *=0,1,2….,62

切過去以後可以下 0:000>kbn 來看這個 thread 在做什麼

根據網路上的資料 由於執行時是以 stack 的方式來作

所以在看的時候要由下往上看 也就是以記憶體大的位址開始看起

不過這在寫什麼鬼是看不懂的 這時候我們可以選擇 call out 求救…..

load 進 sos.dll 的指令下法有好多種 不過我還是直接指定路徑

0:002>.load C:WindowsMicrosoft.NETFrameworkv2.0.50727sos.dll

這時如果有出現 80004005 的錯誤訊息請參考 之前這篇

 現在就可以下指令來看到底 .net 在作什麼了

0:002>!clrstack

如此就能看出來 hang 住的時候你的系統到底在做什麼了

如果你跟我一樣不幸的擁有很多的 thread 可以用這個指令

0:002>!~*e!clrstack 

這又可以一次把所有的 thread 都丟出來

可惜以前在debug ACPI 的時候忙到快爆了沒有順便寫一篇

可以中斷電腦的執行並 trace ACPI code 真的也是非常有趣的事情

要感謝以前在英業達的前輩 Kuo

要不是他花了很多時間教我這些 debug 的方法

我也不可能在接觸.net 不到兩個月的時間能夠堪稱"會用" windbg 來 trace aspnet_wp hang

希望正在上海出差的他可以顧好他的肝

今天在用windbg的時候遇到一個問題

load完dll檔之後要下指令給他跑時出現這樣的錯誤訊息

仔細看一下發現原因出在load進來的dll版本

我的版本是4927而Server的版本是3615

這時直接把Server上的檔案copy回來在安全模式下覆蓋就可以了

PS:記得要先備份原始檔否則以後有要在本機上跑時會有問題

今天遇到一個問題事關於字串長度的判斷

如果我們使用 字串.Length 來抓取長度的話

他會把全形的中文字也算成1個字元

這樣如果遇到中英混和的情況就很難搞了

這時可以利用System.Text.Encoding.Default.GetBytes() 的方法來抓取編碼Byte數

一般英數為ASCII code = 1 Byte

中文字型為Unicode = 2 Bytes

這樣就能準確的算出字串長度

範例如下

string a = “我有3隻小毛驢";

System.Text.Encoding.Default.GetBytes(a).Length

長度 = 6*2 + 1 = 13

改程式的時候遇到一個問題

預設好的gridview如果整列裡面都沒放東西高度會動態縮小

就算是塞空格進去也沒有用也就是以下這個情形

這時只要去預設列高就可以了

只要在其中一列設定其他列就都會影響到

我是直接修改我grideview的第一個元素

<asp:HyperLinkField DataTextField="Column0″  Target="_self"
                ShowHeader="False" NavigateUrl="~/LotteryChNumber.aspx" ItemStyle-Height="20″ >

修改後如下

MSSQL的log檔如果沒有定期清除並釋放的話

不但log檔本身會長得很肥大

萬一需要trace時也會因為檔案太大而效率不佳最近因為某些原因要trace公司資料庫的log檔

沒想到檔案已經長到超過50G了

根本連解都解不出來

分享一下清除log檔並且釋放空間的語法

Backup Log DB_Name with TRUNCATE_ONLY                    //不指定備份裝置所以清空
dbcc shrinkfile (DB_Name_log , truncateonly)                      //沒有用的空間釋放出來,truncateonly可以改成要留下的log檔大小(MB)

有空再來研究如何定期去清…

先確認已經安裝IIS

如果是2003 SP2的版本則已經包含. NET Framework2.0 了

接下來註冊到IIS就可以了

cd

cd “C:WINDOWSMicrosoft.NETFrameworkv2.0.50727″

aspnet_regiis -i

今天差點被擊沉了

想架設一個 2003 server 的環境來debug沒想到這麼麻煩裝好IIS之後機器可以連上外網

但是跟區網內的其他機器卻沒辦法互ping

懷疑是跟防火牆有關

但是打開防火祥出現 “由於另一個程序或正在運行的服務可能正在使用網絡地址轉換組件(ipnat.sys)" 的警告

胡搞了一陣子又上網找了一下

原來這是因為 routing service 被打開

關掉就有解了

先到電腦管理下把"路由及遠端存取"關掉

再去服務裡面把ICS打開(靠….圖超胡但是我懶得重抓了)

之後就能開啟防火牆了…然後就ping的到了…