Quantcast
Channel: windows –易春木
Viewing all articles
Browse latest Browse all 57

Windbg 指令與分析之教學筆記

$
0
0

先說一些有用的工具:Useful tools

  • Process explorer: Process Explorer是一個類似Windows「工作管理員」的程式,主要功能就是列出目前電腦中正在運行的全部程式以及跟運行中程式相關的全部詳細資料,讓我們可以在簡單的圖表與清單中,找出哪些程式佔用最多CPU資源、哪些執行序用掉最多記憶體以及其他更深入的資訊,方便對整個Windows系統做更完整的監控與管理。

    Process Explorer算是一個進階版的「工作管理員」,它可以列出比原本工作管理員還更多、更詳細的各式資料,包含執行檔的圖示、完整的影像與程式所在路徑、記憶統計、權限與安全性屬性…等,更可針對單一處理程序列出使用中的DLL檔,或透過搜尋的方式找出你要的DLL或相關資源,對於程式開發者或電腦管理原來說,應該會是個很方便的實用工具。

  • Process dump: Procdump是一個輕量級的Sysinternal團隊開發的命令行工具, 它的主要目的是監控應用程序的CPU異常動向, 並在此異常時生成crash dump文件, 供研發人員和管理員確定問題發生的原因.你還可以把它作為生成dump的工具使用在其他的腳本中.

    ProcDump與Procexp一樣是Windows平台上的內部調試工具,Procexp採用圖形界面體現系統整體及個別進程的性能信息,而ProcDump則與我們在Unix平台上使用的性能分析工具類似使用CLI命令行界面。

  • LiveKD:使用Microsoft內核調試器檢查系統。
  • NotMyFault:NotMyFault 是一款用來檢測臭蟲(Bug)並除錯的工具,由微軟公司的 Sysinternals 小組發佈。允許使用者主動以多種方式來損毀、當機或凍結系統。使用者可以透過當機後產生的傾印檔案轉存映射來分析 bug 臭蟲。另外,NotMyFault 還能更改系統當機時的預設顏色,使之不再侷限於「藍底白字(BSOD)」。
    警告:極易造成資料遺失。不建議將此工具用於在有生產用途的電腦上作檢測、除錯。使用本工具有著極大的風險,欲使用嘗試者請自行承擔風險。

    NotMyFault 使用系統驅動程式(myfault.sys – 命名是因為該驅動程式是損毀/當機的實際罪魁禍首)在記憶體中四處胡鬧,並做您命令它做的其它壞事。它也可以用於導致系統當機(所以您可以練習除錯問題)或造成重大的記憶體流失。

 

Windbg basic operations

  • Open crash dump with File > Open crash dump
  • Load symbols
  • .symfix C:\symbols: Set local symbol folder
  • .reload: Reload symbols
  • .sympath: Show current symbol path

 

List threads

  • ~: List all threads

 

Switch thread

  • ~0s: Change to thread 0
  • ~1s: Change to thread 1

 

Show stacks

  • ~*k: List all threads’ stacks
  • ~*kv: List all threads’s stacks with 3 function arguments
  • k: List current thread’s stack
  • kv: List current thread’s stack with 3 function arguments
  • kp: List current thread’s stack with all function arguments (need symbol)

 

Show environment

  • lm: List modules
  • lmv: List module versions
  • lmvm: List specific module versions

 

Crash dump automatic analysis

  • !analyze –v: Analyze a crash
  • !analyze –v –hang: Analyze a hang

 

Show exception context

  • Get context address from kv
  • .cxr <address>
    • If there is “???” shown in the result of .cxr, it indicates an invalid address access or memory corruption

 

Disassemble code

  • u: Disassemble code at the address
  • ub: Disassemble code before that address

 

CPU high analysis

  • !runaway 7: Check thread used CPU time and total elapsed time
    • If thread CPU used time occupies a large portion of total execution time, it might indicate a CPU high symptom.

 

Analyze deadlock

  • !analyze –v –hang
    • However, it might not give correct result
  • !locks
    • Show current locks
  • !cs –s –l –o
    • Show critical section owner
  • ub <return address for EnterCriticalSection line>
    • Show the critical section it is going to enter

 

Analyze Stack overflow (recursive)

  • ~*k
    • Shows a lot of same functions in call stack
  • !teb
    • Show stack base and limit
  • dps <stack limit> <stack base>
    • Show stack range content

 

Analyze .NET framework process crash

  • There is “mscorwks” in call stack
  • Show .NET version
    • lmvm mscorwks
  • Load sos extension dll
    • .load C:\Windows\Microsoft.NET\<version>\SOS.dll
    • .unload sos
  • Print .NET exception with sos extension dll
    • !pe

 

Analyze WoW64 process

  • There is “wow64” in call stack
  • Show current machine type
    • .effmach
  • Set machine type to x86
    • .effmach x86
  • !sw can switch between x86 and x64
  • .load wow64exts
    • Then we can see x86 call stacks
  • To see MessageBox parameters
    • du <argument address>

 

Analyze memory leak

  • Turn on gflags by executing Windows Kits > Global Flags > System Registry > Create user mode stack trace database
  • Show current gflag
    • !gflag
  • Show heaps
    • !heap –s
    • !heap –k –h <heap id>

 

Analyze infinite wait

  • Analyze with !analyze
    • !analyze –v –hang
  • Show WaitForMultipleObjects arguments
    • 1st argument = number of handles
    • 2nd argument = handle array
    • dp <2nd argument address>
  • Show each handle
    • !handle <handle address> f

 

Analyze kernel dump

  • List current process
    • !process
  • List all processes
    • !process 0 0
    • !process 0 7: with call stack
  • Get IRP list from output of !process <process address>
  • Show IRP
    • !irp <irp address>
  • Get device object from “Device” in IRP list, then show its info
    • !devobj <device obj address>
  • Get file object from “File” in IRP list, then show its info
    • !fileobj <file obj address>
  • Show thread info
    • !thread
    • !thread <thread address>
  • Change thread
    • .thread <thread address>
  • Show page table entry
    • !pte <address>
  • Check if is running on VM
    • lmvm vmmemctl: for VMware

 

Analyze kernel dump for memory problem

  • Show memory
    • !vm
  • If NonPagedPool Usage is close to NonPagedPool Max, or if PagedPool Usage is closed to PagedPool Max, there could be memory stress problem.
    • !poolused 2: non-paged memory
    • !poolused 4: paged memory
  • Show running processors and threads
    • !running
    • !running –i –t: include idle processor, and show call stack
  • Show system info
    • !sysinfo cpuinfo
    • !sysinfo

 

Analyze complete kernel dump

  • There is “Kernel Complete Dump File: Full address space is available” in the output of windbg
  • Change process
    • .process /r /P <process address>
  • Change thread
    • .thread <thread address>

Viewing all articles
Browse latest Browse all 57

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>