請及時關注“高效運維(微信ID：greatops)”公衆號，並置頂公衆號，以免錯過各種乾貨滿滿的原創文章。
作者簡介：
作 者：史影（擅長運維開發、雲存儲、負載技術）、童寧（擅長監控、WEB前端技術）、張凱俊（擅長運維開發）
執筆人：韓曉光(專業運維，兼職開發，幹過商務。信息系統項目管理師、ITIL Foundation認證、IBM CATE、RHCE)
作者團隊著有《系統運維全面解析:技術、管理與實踐》
內容概要
由於操作系統自身問題，軟硬件兼容問題，驅動問題、應用程序的bug問題以及各種複雜因素，都會導致運營的業務系統出現異常。對此，如果運維人員沒有很好地分析處理能力，往往就會背黑鍋。
那麼作爲運維人員，如何擺脫背黑鍋的尷尬局面呢，也許Debug調試是一招破局必殺技能。
幹運維，僅僅會Linux運維及其Debug調試是遠遠不夠的，另外鑑於“高效運維”社區已經有介紹Linux調試專題文章，因此本文僅對Linux系統調試工具作簡要介紹，而主要探討Windows系統調試分析技術。
一、運維尷尬的現象
先說幾個運維常見的尷尬場景：
1、用戶反映系統慢，希望儘快解決。但你發現CPU、內存、磁盤、帶寬等各項指標非常正常。於是問題僵持，用戶很生氣，你很委屈。
2、系統本來正常，但你發現自從部署某個應用後，系統就有些不正常了。但你苦於沒有確鑿證據去證明是這個應用軟件的BUG。於是研發（產品）同事得意地笑了，你卻很委屈地咬牙。
3、艾瑪！系統出現故障，宕機了。然後你從系統日誌裏，並沒找到問題的根源線索，或者看到了異常日誌，也只是看看，然並卵。於是領導很生氣，你依然很委屈。
如果你幹過運維工作，那麼上面的幾個場景或許都會碰到過。也許我們會感慨運維就是“黑鍋俠”，這就是幹運維的命運，作爲救火員，當你救不了火，那就背黑鍋。
二、運維尷尬背後的原因
其實運維工作，難免遇見故障，是硬件總有罷工的那一天，是軟件總有不合理的BUG、是人的地方就有江湖。作爲運維工程師，要想成爲運維大神，就得不斷升級打怪，歷經九九八十一難，你就得道了。
當你再驀然回首，其實當年運維尷尬的背後，是我們當時無法定位妖怪的老巢，沒法徹底一窩端掉。最核心原因是我們當時還不具備那種一捅到底的能力。
三、解決運維尷尬的殺手鐗
那麼在這個快節奏運維年代，有沒有速成的大法，直搗上述尷尬問題的底層原因呢？答案：有！
Debug調試分析！學得此本領，可以上天入地，幹得了用戶態，也搞得了內核態。
當然，有了這麼好的大法祕籍，並非每個人都有機遇練就這身本領。所謂的速成，也看個人修爲了。
接下來，我就簡要介紹一些Debug調試大法。
我相信，祕籍不在長短，也不可能盡舉。高手往往都是悟出來的。
四、Debug調試分析
作爲運維工作，通常會分爲傳統運維、互聯網運維。作爲互聯網運維工作者，我們通常用Linux系統。鑑於“高效運維”社區已經有介紹Linux調試專題文章，因此本文僅作一些Linux系統調試分析的概要介紹，不再贅述。
1、Linux調試分析
當Linux系統出了系統問題，程序問題，性能問題，怎麼辦？其實還是有很多工具方法可以用的。這裏簡單概括一下
點擊可查看高清大圖
2、Windows調試分析
運維的世界那麼大，想成爲一個運維大神，僅僅會Linux運維及其Debug調試是遠遠不夠的。僅論服務器操作系統，還有AIX、HP-UX、Solaris、FreeBSD、Z/os、Windows，等等。
在傳統運維企業及桌面運維中，其中Windows Server服務器還是佔有相當的比重的。下面就探討一下Windows系統調試分析。
2.1 Windows Debug及性能調試基礎概念
2.1.1 名稱概念
Process：進程，是操作系統結構的基礎，是一個具有一定獨立功能的程序關於某個數據集合的一次運行活動。
Thread：線程，是進程中的一個實體，是被系統獨立調度和分派的基本單位，線程自己不擁有系統資源，它可與同屬一個進程的其它線程共享進程所擁有的全部資源。
User Mode：用戶態，應用程序運行時所處的模式，不能直接訪問物理硬件及內存。
Kernel Mode：內核態，操作系統運行時所處的模式，可以訪問系統的所有部分。
用戶態與內核態的關係如圖所示:
用戶態模式包括：
用戶的應用程序。
系統服務程序。
若干關鍵的系統進程，如Winlogon.exe、Csrss.exe、Lsass.exe。
內核態模式包括：
設備驅動。
系統組件。
硬件抽象層。
顯示驅動。
Exception：異常，就是CPU在執行代碼時，碰到的非預期的指令時所做出的反饋。它表明CPU需要中斷當前正常執行的代碼流程，去處理碰到的非正常情況。如：
除數爲0。
頁面錯誤，訪問非法內存地址。
特殊的調試指令。
異常通常分爲：
first chance — 程序不會崩潰；
second chance — 程序會崩潰。
在用戶模式，大部分異常會被應用程序中的異常處理模塊處理。如果程序沒有正常處理這些異常，程序可能會異常退出。
在內核模式，系統異常處理模塊會處理碰到的異常，部分異常會直接導致機器藍屏出錯。
簡單來說，應用故障發生在用戶態，系統故障發生在內核態。
Paging：換頁，把物理內存中的數據移到磁盤上的PageFile中的操作。如果系統嘗試訪問PageFile中的數據，內存管理器會產生一個Page Fault，然後把相應數據重新從PageFile中讀到物理內存中。
Paged pool：分頁內存池，一部分內核使用的內存，可以被移到磁盤上的PageFile中。
NonPaged pool：非分頁內存池，一部分內核使用的內存，需要一直保持在內存中，不能被移到磁盤的PageFile上，用於滿足各種中斷等需求。
Interrupt：中斷，中斷請求是由某個設備/進程發出的請求CPU產生中斷當前執行流程的一個請求響應信號。
Blue Screens and Bug Check
Codes：藍屏，系統碰到異常時，爲保證數據完整性而把機器重啓的保護機制，會同時顯示藍屏界面。
Crash Dump File：內存轉儲文件，系統藍屏時，內存中記錄系統狀態的數據的文件轉儲。
2.1.2 系統常見性能問題與分析指標
常見性能問題：
CPU使用率高。
內存及內核資源使用。
磁盤性能問題分析。
系統失去響應及藍屏重啓。
常見性能分析指標：
內存
可用物理內存。
分頁內存池。
非分佈內存池。
緩存。
工作集空間。
CPU
CPU佔用率（內核態CPU時間，用戶態CPU時間）。
中斷CPU時間與DPC（延時過程調用）CPU時間。
磁盤
磁盤忙碌\空閒時間比。
磁盤平均單次讀寫耗時。
磁盤IO排隊隊列。
Split IO/Sec。
2.1.3 內存地址空間分配架構
在x86系統上，虛擬地址空間是2^32=4GB。所以系統分配2GB給用戶態，2GB給內核態使用。在內核態，我們可以使用/PAE的選項，來支持高達64GB的物理內存。
在x64的系統上，可以支持2TB的內存。
在Windows 2003及以前，內核虛擬地址空間是固定的。而在Windows 2008及以後，內核虛擬地址空間是動態分配的。
二者對比如圖所示：
Windows進程使用內存的分配構成方式，如下圖所示，其實是這樣的。
英文解釋如下：
Virtual Byte是整個進程佔用的全部虛擬地址空間。包含保留和提交的內存。32位Windows用戶模式下，進程默認最大可以使用2GB。在64位Windows下，進程的虛擬地址空間可以達到8TB。
Committed bytes 是虛擬地址空間正在被使用的那部分。這部分空間可以保證進程的地址可以映射到實際的物理內存（及磁盤page分頁）上。
Private Bytes是隻被本進程用佔用的虛擬地址空間，不包括其他進程共享的內存。
Shared bytes 是與其他進程共享的一部分虛擬地址空間。
Working Set是一個進程可以用到(但不一定會使用)的物理內存。即不引起page
fault異常就能夠訪問的內存。Working Set包含了可能被其他程序共享的內存。
2.2 Debug調試常用概念
2.2.1 Windows系統有時候會出現死機及異常重啓的情況，可能的現象例如：
機器非常慢，多個應用程序異常的慢，無法進行操作。
鼠標/鍵盤沒有響應。
網絡沒有響應，PING/RDP/文件共享失敗。
本地無法登錄，桌面鎖死，黑灰屏或是隻有背景界面。
系統直接異常重啓。
系統藍屏。
出現上述情況的可能的原因：
硬件問題。
系統/應用程序死鎖。
內核資源使用異常。
病毒/惡意軟件。
2.2.2 調試系統死機/藍屏的基本思路，如下：
檢查系統日誌，看是否有出錯記錄。
開啓性能監控器，檢查系統資源使用。
檢查硬件。
卸載最近安裝的軟硬件。
用最後一次正常配置的模式恢復到之前的正常配置。
手動的收集死機時的DUMP文件。
收集系統藍屏時的DUMP文件。
通過另一臺機器進行Live debug。
2.2.3 DUMP概念
在系統藍屏時，內核會嘗試把當前內存中的數據保存下來，寫成Memory.dmp文件，用於事後分析出錯原因。
DUMP文件其實就是出錯一瞬間，系統內存中內容的一份備份。它是一份靜態的數據備份，並不是一個動態的一段時間內系統狀態的記錄。
2.2.4 DUMP文件類型
Complete Memory Dump 完全內存轉儲：系統藍屏時，內存中的所有數據，包括用戶態及內核態數據。該文件較大，一般就是當時內存使用大小。
ernel Memory Dump核心內存轉儲：系統藍屏時，內存中內核態的數據。一般只在完全內存轉儲文件的1/3大小。
Small Memory Dump (“Minidump”)：包括最基本的調試信息，如loaded drivers、kernel-mode stack、出錯代碼等。較小，64KB–256KB。
2.2.5 DUMP文件調試工具
調試的配置及分析工具有很多，例如：
Windbg：即可分析用戶態dump，也可以分析內核態dump
gflags ：Windbg中的gflag.exe，能夠很好地分析捕獲heap破壞異常問題。
Adplus： 能夠交互式分析停止響應(掛起)或失敗(崩潰)的進程或應用程序的問題。
debug diagnostic：可以自動分析用戶態dump文件，但不能分析內核dump（如系統藍屏dump）。可以很好地分析定位內存泄露問題。
visual studio： 只能分析用戶態dump
perfmon：Windows系統默認自帶的性能分析工具。其實是很好很強大的。用得好不好，就看你對Windows瞭解有多深了。
PAL：通過PAL分析perfmon的性能日誌文件，可以自動產生一個網頁版的性能分析報告，大大方便了我們分析系統性能工作，是一款非常好用的性能分析輔助工具。
2.2.6 Windbg簡介
Windbg是常用而且強大的Windows調試分析工具，界面如圖17-10所示。
Windows debugger安裝程序下載地址:
X86:
http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.404.msi
X64:
http://msdl.microsoft.com/download/symbols/debuggers/dbg_amd64_6.11.1.404.msi
一般情況，我們使用Windbg工具進行DUMP調試。
Windbg 也可以用於代碼調試及實時調試。除了直接安裝Windbg，我們也可以把其它機器上安裝好的Windbg文件夾直接拷貝到另一臺機器上即可使用。
Windbg Symbol 文件
在Windows 系統中，Symbol文件以.pdb 爲擴展名。
Symbol Files是一個數據信息文件，它包含了應用程序二進制文件（比如EXE、DLL等）調試信息，專門用於調試時解釋可執行文件中的變量信息。
WindowsPublic Symbol 地址：
Private Symbols 包含更多的信息，如本地變量名、源程序行、變量類型等信息。
有很多信息在public symbol中是看不到的，但是這些信息只限於操作系統內核，即使有private symbol，也需要配合source code一起分析。
Windbg中設置Symbol Path
設置Symbol的目的是告訴debugger哪裏去對應或下載相應的Symbol files。
設置Symbol時，可以包含多個路徑，包換Microsoft Symbol服務器、本地Symbol路徑、內部Symbol文件共享、程序開發時創建的Symbol等。這些路徑以“;”分隔。
Symbol path 示例如下:
SRVc:\symbolshttp://msdl.microsoft.com/download/symbols
WinDbg中四種方法設置symbol path
Set the _NT_SYMBOL_PATH environment variable
Use the -y command line option
Use the .sympath (Set Symbol Path) debugger meta-command
Use the “Symbol File Path” command in the File menu
Windbg基本使用方法
當打開一個dump文件，!analyze –v是唯一默認出現在Windbg中的命令。這個命令可以查看關於此DUMP文件的最基本的信息，如下示例：
點擊可查看高清大圖
在檢查完!analyze –v的輸出後，我們需要切換到出錯當時的frame（單擊出現的trap 命令），然後用k命令檢查真正出錯時的stack：
點擊可查看高清大圖
其它可能出現的trap的形式有：
.tss/.exr/.cxr/.trap
在!analyze –v的輸出中，Windbg會自動指出最可能出錯的驅動，例如：
點擊可查看高清大圖
這個結果其實是Windbg自動把stack上出現的驅動，按出現順序的由後到前，與…\Debugging Tools for Windows (x64)\triage\triage.ini 中列出的驅動進行比較後過濾，當過濾到第一個沒有記錄在triage.ini中的驅動時，把它列爲可能引起出錯的程序。
所以Windbg自動分析出來的這個結果，並不是100%完全可信，僅可以作爲參考。
2.3 Windbg debug調試分析實例
2.3.1 案例：關於應用dump文件的分析
問題描述：
這個是一個基於.NET開發的應用程序，之前一直運行良好，但現在只要一按附欄中的“校驗”，就會產生錯誤，如圖所示：
問題分析：
首先，收集應用程序dump，抓取dump文件，方法如下：
1）運行程序Windbg
2）打開命令行(cmd.exe), 將當前目錄切換至c:\debuggers（Windbg的安裝目錄）,
在問題重現之前輸入以下語法格式命令用以開始監視目標進程:
cscript adplus.vbs -quiet –crash -fullonfirst -pn.exe -o c:\dumps
例如這裏輸入命令：
C:\Debuggers>cscript adplus.vbs -quiet -crash -fullonfirst -pn Arms.Server.Remoting.exe -o d:\dumps
3）回到程序並重現問題。
注意：如果C:\盤空間不足的話，可以將dump生成目錄（c:\dumps）更改到其他位置（例如這裏設置爲d:\dumps）。請不要手動關閉debugger窗口（cdb.exe），當應用程序重現問題之後這個窗口會自動關閉。
4）當問題重現時，也就是您看到錯誤對話框以後，請不要關閉那個錯誤框，之後打開命令行，輸入以下命令收取一個新的dump文件。
cscript adplus.vbs -hang -pn Arms.Server.Remoting.exe -o d:\dumps
通過上述步驟，也即在hang模式下抓取了dump文件，例如這裏抓取的dump文件名稱爲：
[PID-3436ARMS.SERVER.REMOTING.EXEfull_0268_2012-11-28_10-06-00-687_0d6c.dmp]
通過Windbg打開該dump文件，主要分析要點如下：
點擊可查看高清大圖
分析結論：
從Windbg分析來看，其調用的棧應是一個Windows Service程序。
從上述提供的報錯截圖來看，拋錯的程序應就是一個Winform的程序，基本上與該dump分析出來的堆棧信息一致。因此該程序這段代碼出錯的可能性很大。
從而基本排除系統層面的問題，並且大致定位到應用程序的故障範圍。剩下問題就是扔給應用開發人員調試程序。
至此，作爲運維的你是不是感覺清爽了很多，起碼擺脫了黑鍋。
2.3.2 案例： 關於系統dump的調試分析
問題描述：
windows服務器異常宕機，已產生dump
問題分析：
使用Windbg對系統dump進行分析。
主要分析內容如下:
點擊可查看高清大圖
分析總結：
服務器發生藍屏的直接原因是一個驅動程序嘗試去在一個過高的IRQL（Interrupt ReQuest Level）上訪問一個被換頁的內存（也有可能是不合法的內存地址）。
通常情況是由驅動訪問不合法的地址造成的。經過檢查DUMP，我們發現SYMTDI很有可能是導致藍屏的原因，同時由於系統並未升級到最新版本，建議做版本升級。
GetAddress是windows系統函數，出錯的具體原因是tcpip對一個irp(I/O Request Package)的對象做檢查的時候出現異常。
這個irp是從rpcxdr下發，經過symtdi，最後到了tcpip，因此懷疑可能是symtdi或者rpcxdr的問題，因此建議升級symtdi和tcpip.sys到最新版本(從時間戳來看，驅動是有些老舊)，並繼續觀察服務器運行狀況。
限於篇幅和作者水平，就先到此吧。
想了解IT運維更多內容，請參閱：
作者書籍：
《系統運維全面解析：技術、管理與實踐》
作者微信：
