!analyze -v : windbg

x64 Stack Frame layout

DebugMachine — Mon, 21 Dec 2009 01:59:20 GMT

아래 포스트에 따르면 rsp 가 return address를 가리키고 있을 때 x64의 rsp+8 에는 rcx를 저장하기 위한 공간이 있다고 합니다. rsp+10 에는 RDX를 위한 공간이 있고요 물론 항상 그 공간이 사용되는 것 같지는 않은데 다음 번 x64 Dump 분석을 할 때 확인해 봐야겠습니다.

x64 Stack Frame layout

http://analyze-v.com/?p=468

x64 Calling Convention

DebugMachine — Mon, 21 Dec 2009 01:51:15 GMT

아래 포스트에서는 x64의 calling convention에 대해서 설명하고 있습니다. 파라미터가 rcx, rdx, r8, r9 순서로 들어가게 되고 5번째 부터는 스택에 들어가게 됩니다. 하지만 이후 다른 함수들을 호출하면서 해당 레지스터 값들이 변경되기 때문에 x64는 정말 분석하기 힘듭니다.

x64 Calling Convention

http://analyze-v.com/?p=458

많은 Thread 가 TCPip!tcpcleanup에서 대기하고 있는 패턴

DebugMachine — Mon, 21 Dec 2009 01:46:02 GMT

시스템이 Hang 된 상태에서 원인을 찾는 내용으로 먼저 locks 명령으로 resource를 소유하고 있는 Thread를 파악한 후 tcpip 의 disconnect 와 연관되어 있는 것을 확인한 후 tcpip와 관련된 IRP들이 대부분 tcpipcleanup에서 멈추어 있는 것에 대한 분석 입니다.

Wait chain, blocked thread, waiting thread time, IRP distribution anomaly and stack trace collection: pattern cooperation

http://www.dumpanalysis.org/blog/index.php/2009/12/17/wait-chain-blocked-thread-waiting-thread-time-irp-distribution-anomaly-and-stack-trace-collection-pattern-cooperation/

x64 Trap Frames에 대한 이야기

DebugMachine — Sun, 20 Dec 2009 09:27:31 GMT

WinDbg를 사용해서 x64장비의 덤프를 분석 하다 보면 parameter를 믿을 수가 없는 경우가 많이 있습니다. 아래 포스트에서는 trap frame 의 rbx, rbp, rdi, rsi 그리고 r12-r15를 믿지 말라고 합니다. 자세한 내용은 osronline을 참고 하셔야 합니다.

x64 Trap Frames

http://analyze-v.com/?p=451

Internet 에 연결되어 있지 않은 경우 liveKD를 이용한 덤프 수집 방법

DebugMachine — Thu, 10 Dec 2009 02:14:08 GMT

서버를 Down 하지 않고 Dump를 만드는 경우 Sysinternals 의 liveKD를 많이 사용하게 됩니다. 하지만 Dump를 수집해야 하는 서버가 Internet 에 연결되어 있지 않은 경우 Symbol 서버에 접근할 수 없어 livekd가 실행되지 않습니다.

아래 포스트에서는 Dump를 수집할 서버에서 커널과 관련된 파일을 Internet 연결이 가능한 다른 장비로 복사한 후 Windbg 안에 있는 툴인 SymChk.exe를 사용해 Symbol 서버로부터 심볼을 받은 후 덤프를 생성할 수 있습니다.

http://blogs.technet.com/carlh/archive/2009/11/30/online-kernel-memory-dump-using-livekd-exe.aspx

[UnderTheHood]Microsoft System Journal 중 좋은 글 모음

DebugMachine — Fri, 06 Nov 2009 09:26:53 GMT

안녕하세요 이태화 입니다.

저도 다 읽어 보지는 않았지만 WSJ 에 있는 좋은 글 모음 입니다.

Matt Pietrek shows how to call NtQueryInformation APIs in order to gain system-level information from WindowsNT.

http://www.microsoft.com/msj/0197/hood/hood0197.aspx

Sure, you may use _try and _except in your C++ code, but have you ever wondered what's going on under the hood? Matt Pietrek goes where almost no one has gone before, diving into the abyss of SEH and surfacing with a human-readable explanation.

http://www.microsoft.com/msj/0197/Exception/Exception.aspx

Calling DispatchMessage isn't optional if you're using timers. DispatchMessage is needed for both varieties of timer notifications (that is, window messages and callback functions).

http://www.microsoft.com/msj/0397/hood/hood0397.aspx

Matt Pietrek explains how to implement an exception handler that can be used as the default exception handler for each thread.

http://www.microsoft.com/msj/0497/hood/hood0497.aspx

Linkers In-Depth: Get a guided tour through the workings of the Win32 linker.

http://www.microsoft.com/msj/0797/hood0797.aspx

This month we'll take a look at Win32 exceptions specific to the Intel x86 architecture, beginning with the beloved GPF.

http://www.microsoft.com/msj/1097/hood1097.aspx

Ever since Matt Pietrek wrote his PEDUMP article (MSJ, March 1994), many people have asked how to access the data for an arbitrary resource. Finding hidden dialog controls was just the excuse he needed to write some C++ classes that traverse the PE resource format.

http://www.microsoft.com/msj/0198/hood0198.aspx

Welcome to Matt Pietrek's "Just-Enough-Assembly-Language-to-Get-By Guide," the source for programmers who need to know at least a little assembler to be able to debug compiled code.

http://www.microsoft.com/msj/0298/hood0298.aspx

A handy feature of Windows NT® is the performance data counter which provides information about a system like running processes, interrupts per second, network I/O stats, etc. But the interface is horrible. There is an API-based interface that is even accessible in Visual Basic. Matt Pietrek covers it this month.

http://www.microsoft.com/msj/0398/hood0398.aspx

When do you use the CreateThread function., and when do you use _beginthreadex instead?

http://www.microsoft.com/msj/0799/Win32/Win320799.aspx

Where has all the memory gone? Managing memory and resource leaks.

http://www.microsoft.com/msj/1199/hood/hood1199.aspx

감사합니다.

[UnderTheHood]분석에 필요한 어셈블리 언어

DebugMachine — Fri, 06 Nov 2009 07:46:53 GMT

안녕하세요 이태화 입니다.

Dump 분석을 하기 위해서는 어셈블리 언어를 알고 있어야 합니다. 하지만 어셈블리 언어로 코딩을 할 수 있을 정도의 레벨이 아니라 어셈블리 코드를 보고 흐름을 따라갈 수 있을 정도만 알고 있으면 됩니다. 굉장히 방대한 어셈블리 언어 중 어디까지 알아야지 Dump 분석을 위한 레벨에 올랐다고 할 수 있을지 많은 분들이 궁금해 하셨으리라 생각 합니다.

Microsoft 의 아주 오래된 잡지인 Microsoft Systems Journal 에는 Matt Pietrek 가 작성한 Under The Hood 라는 아주 좋은 글들이 있고 이중 아래 두 개의 글은 어셈블리 언어를 공부하는데 아주 좋은 자료 입니다.

http://www.microsoft.com/msj/0298/hood0298.aspx

http://www.microsoft.com/msj/0698/hood0698.aspx

감사합니다.

[Mark’s Blog]Pushing the Limits of Windows: Handles

DebugMachine — Thu, 01 Oct 2009 03:25:03 GMT

번역을 할 시간이 부족해서 원문의 링크를 걸어 놓았습니다.

http://blogs.technet.com/markrussinovich/archive/2009/09/29/3283844.aspx

Handle 은 Object 를 가리키는 것이라고 하고 있으며 Mark가 만든 툴인 testlimit 을 사용해서 핸들을 최대 몇 개나 만들 수 있는지 확인해 보고 있습니다.

64bit 시스템에서는 16,711,657 개의 핸들이 생성 되었고 32Bit 시스템에서는 16,744,434 개의 핸들이 생성 되었습니다.

Windows Excutive 즉 실행부에서는 16,777,216(16*1024*1024)개로 핸들의 최대 갯수가 하드 코드 되어 있습니다.

Handle table 이 사용하는 Memory 에 대한 설명 및 handle leak 발생 시 Windbg 에서 !htrace를 사용해서 문제를 찾는 방법을 이야기 하고 있습니다.

[Ntdebugging]실력이 시험되는 장, 하드웨어 조사하기

DebugMachine — Fri, 04 Sep 2009 10:19:22 GMT

"이 문서는 http://blogs.msdn.com/ntdebugging blog 의 번역이며 원래의 자료가 통보 없이 변경될 수 있습니다. 이 자료는 법률적 보증이 없으며 의견을 주시기 위해 원래의 blog 를 방문하실 수 있습니다. (http://blogs.msdn.com/ntdebugging/archive/2007/06/22/where-the-rubber-meets-the-road-or-in-this-case-the-hardware-meets-the-probe.aspx )

실력이 시험되는 장, 하드웨어 조사하기

안녕하세요 Bob 입니다.Microsoft critical problem resolution 팀에서 근무하는 Escalation engineer 입니다. 독자 중 한 분이 저희가 얼마나 자주 하드웨어 문제를 다루는지 문의해 주셨는데 최근 아주 흥미로운 문제를 처리 하였는데 이 내용을 공유해 드리고자 합니다. 이 문제는 아주 흥미로운데 일부 멀티 프로세서에서 발생하고 드라이버를 개발한 사람에게는 문제가 되지 않는 것으로 보입니다.

무엇이 문제일까요?

시스템의 시간이 업데이트 되지 않는다는 것 이외에는 모든 것이 정상 입니다. RTC 가 정지된 것 입니다. RTC가 어떻게 동작하는지 확인해 보았고 마더보드의 RTC에 오실로스코프로 연결하여 특정 값을 디버거로 써서 RTC를 끌 수 있는지도 확인해 보았습니다. 오실로스코프를 사용하여 어떤 값을 포트에 써야 클럭을 끌 수 있는지도 검증해 보았습니다. 이를 통해 드라이버가 문제를 일으킬 수 있는 방법에 대해서 완벽히 이해할 수 있었습니다. 클럭은 매 10ms 마다 발생하며 매우 빠른 오실로스코프가 필요하지는 않습니다.

특별한 키보드 드라이버 작성

문제가 발생한 상태에서 덤프를 수집하기 위해 키보드 드라이버 수정하여 Bugcheck E2가 발생하지 않고 Int 3이 호출되도록 수정하였습니다. RTC는 퀀텀을 소모하지 않는 Idle 쓰레드에서는 동작하지 않고 일반적인 덤프에서는 원하는 결과를 얻을 수 없습니다. 하지만 시스템은 ISR 에 응답 합니다.

발견한 것.

모든 RTC 인터럽트가 멈추었다. – 클럭이 동작하지 않는다. RTC가 사용되지 않게 되었는지 모든 방면에서 확인해 보았습니다.

I/O APIC의 ICR을 확인해 보았습니다. 이것은 인터럽트 컨피그레이션 레지스터로 APIC의 모든 인터럽트 핀에 있는 레지스터 입니다. 이 레지스터들은 APIC에 어떤 벡터 값이 프로세서로 전달되었는지 알려주고 프로세서가 인터럽트 서비스를 실행할 수 있게 해 줍니다. 또한 레벨에 대한 설정 정보를 가지고 있으며 트리거 되었는지 마스크 되었는지 알려 줍니다. 마스크 비트는 설정되어 있지 않았습니다..

아래는 사용 규칙 입니다.

0: kd> ed ffd01000

ffd01000 00000034 20 <- 핀 8번에 해당하는 20번 레지스터 선택.

0: kd> ed ffd01010

ffd01010 000008d1 <- 내용 <- 벡터 D1 비트 16, 인터럽트 마스크는 설정하지 않았습니다.

I/O 포트 70번과 71번의 RTC 상태 레지지스터를 확인 합니다. 70번 포트는 어드레스 포트이고 71번 포트는 데이터 포트 입니다. 이 정보는 BIOS 관련 책에서 확인할 수 있습니다.

0: kd> ob 70 b <- ‘B’ 는 컨트롤 레지스터 입니다.

0: kd> ib 71

00000071: 42 <- 42는 RTC 사용을 의미 합니다. 6번째 비트가 활성화 입니다.

무엇일까요?

RTC는 특정 간격으로 인터럽트를 발생시킬 것이고 인터럽트가 서비스 될 때 상태 레지스터가 읽힐 것 입니다.

덤프에서 다른 드라이버들을 디스어셈블하여 특정 드라이버가 포트 70과 71에 대한 연산을 통하여 클럭을 읽는 것을 확인 하였습니다. 낮은 어드레스가 포트 70으로 설정되어 읽을 때의 시간을 산출하고 있었습니다. 이것이 드라이버가 문제를 일으킨 동작 입니다.

시간을 읽는 작업은 간단한 것으로 다른 곳에 영향을 미치지 않을 것이라고 생각 할 수 있습니다. 하지만 멀티 프로세서 시스템에서는 포트에 대한 접근은 직렬화 됩니다.

하나의 클럭, 주소, 데이터에 대해서 두 개의 프로세스로 인해서 두 개의 접근이 발생하여 결과에 오류가 발생하였습니다.

아래는 접근에 대한 시간 흐름도 입니다.

프로세서 0 : OS RTC 핸들러 프로세서 1 : XYZ 드라이버

T1 상태 레지트러를 선택하도록 레지스터 설정

T2 시간을 읽도록 레지스터 선택

T3 클럭을 재 시작 하기 위해 상태 레지스터 읽기

T3 에서 OS RTC 핸들러는 잘못된 레지스터를 읽어 클럭이 시작되지 않습니다.

결론

이 문제는 직렬화를 잘 이야기 해 줄 수 있는 좋은 예제라고 생각 됩니다. 그리고 멀티 프로세서 환경을 잘 보여주는 것이라고 생각 됩니다. 항상 다른 프로세서에서 무엇을 하는지 생각해 보는 것이 좋다고 생각 됩니다.

아래 정보를 통해 보다 많은 BIOS에 대한 정보를 얻을 수 있습니다.

http://www.geocities.com/SiliconValley/Campus/1671/docs/rtc.htm

[Channel9]David Grant and Ryan Kivett: !Analyze - Automatic Root Cause Analysis

DebugMachine — Fri, 04 Sep 2009 03:54:31 GMT

Windbg를 사용하면서 !analyze –v 명령을 사용해 보지 않으신 분은 없으리라 생각 합니다. 자동으로 문제점을 진단하는 !analyze 를 개발하는 Engineer 두 명의 인터뷰 입니다.

David Grant and Ryan Kivett: !Analyze - Automatic Root Cause Analysis

!Analyze is an automatic root cause analysis tool for software failures. For years, it has provided insight to engineers both inside and outside of Microsoft. It is a key enabling technology behind numerous higher-level feedback systems, including Windows Error Reporting and Watson.
!Analyze runs millions of times each day, producing actionable results from reliability telemetry data sent to Microsoft. Ordinary debugging tools report the file and function where a failure ended. !Analyze pinpoints where the failure started.
How does it work, exactly? What's the story behind !Analyze?
Meet two of the Software Developers behind !Analyze, David Grant and Ryan Kivett. They share with us how !Analyze works, it's history and provide a glimpse into it's potential future.Tune in.
Great job, !Analyze team!

[CDA]크래쉬 덤프 분석 케이스 스터디 (1)

DebugMachine — Wed, 26 Aug 2009 11:50:31 GMT

"이 문서는 http://www.dumpanalysis.org/blog/ blog 의 번역이며 원래의 자료가 통보 없이 변경될 수 있습니다. 이 자료는 법률적 보증이 없으며 의견을 주시기 위해 원래의 blog 를 방문하실 수 있습니다. ( http://www.dumpanalysis.org/blog/index.php/2007/02/21/crash-dump-analysis-case-study-1/ )

크래쉬 덤프 분석 케이스 스터디 (1)

덤프를 WinDbg로 열어 보았을때 아래와 같이 빨간색으로 되어 있는 코드를 확인해 보도록 하겠습니다.

Consider the following legacy C++/Win32 code fragment highlighted in WinDbg after opening a crash dump:

1: HANDLE hFile = CreateFile(str.GetBuffer(), GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); 2: if (hFile != INVALID_HANDLE_VALUE) 3: { 4: DWORD dwSize = GetFileSize(hFile, NULL); 5: DWORD dwRead = 0; 6: CHAR *bufferA = new CHAR[dwSize+2]; 7: memset(bufferA, 0, dwSize+2); 8: if (ReadFile(hFile, bufferA, dwSize, &dwRead, NULL)) 9: { 10: DWORD i = 0, j = 0; 11: for (; i < dwSize+2-7; ++i) 12: { 13: if (bufferA[i] == 0xD && bufferA[i+1] != 0xA)

코드를 먼저 살펴 보면 정상적으로 보입니다. 파일을 열고 사이즈를 얻고 파일을 읽기 위한 버퍼를 할당하고… 모든 인덱스들은 배열 경계 안에 있는것으로 보입니다. 디스어셈블리 코드를 살펴 보도록 하겠습니다.

0:000> uf component!CMyDlg::OnTimer … … … 004021bc push 0 004021be push esi 004021bf call dword ptr [component!_imp__GetFileSize (0042e26c)] 004021c5 mov edi,eax ; dwSize 004021c7 lea ebx,[edi+2] ; dwSize+2 004021ca push ebx 004021cb mov dword ptr [esp+34h],0 004021d3 call component!operator new[] (00408e35) 004021d8 push ebx 004021d9 mov ebp,eax ; bufferA 004021db push 0 004021dd push ebp 004021de call component!memset (00418500) 004021e3 add esp,10h 004021e6 push 0 004021e8 lea edx,[esp+34h] 004021ec push edx 004021ed push edi 004021ee push ebp 004021ef push esi 004021f0 call dword ptr [component!_imp__ReadFile (0042e264)] 004021f6 test eax,eax 004021f8 jne component!CMyDlg::OnTimer+0×3b1 (00402331) … … … 00402331 xor esi,esi ; i 00402333 add edi,0FFFFFFFBh ; +2-7 (edi contains dwSize) 00402336 cmp edi,esi ; loop condition 00402338 mov dword ptr [esp+24h],esi 0040233c jbe component!CMyDlg::OnTimer+0×43e (004023be) 00402342 mov al,byte ptr [esi+ebp] ; bufferA[i]

0:000> r eax=00002b00 ebx=00000002 ecx=00431000 edx=00000000 esi=00002b28 edi=fffffffb eip=00402342 esp=0012efd4 ebp=0095b4d8 iopl=0 nv up ei pl nz ac pe cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000217 component!CMyDlg::OnTimer+0×3c2: 00402342 8a042e mov al,byte ptr [esi+ebp] ds:0023:0095e000=??

만약 EBX (dwSize+2) 와 EDI 레지스터( 배열의 상위 경계, dwSize+2-7)를 확인하였다면 dwSize 가 0이라는 것을 쉽게 확인할 수 있었을 것 입니다. 버퍼 오버런이 발생한 것으로 배열의 경계가 0+2-7 = FFFFFFFB 로 계산되었기 때문입니다.(루프의 인덱스는 unsinged integer, DWORD 입니다.). 인덱스가 signed integer 값(int) 라면 루프의 비교 조건이 0<0+2-7로 아무런 문제가 발생하지 않습니다.

아래와 같은 수정이 필요 합니다.

1: HANDLE hFile = CreateFile(str.GetBuffer(), GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); 2: if (hFile != INVALID_HANDLE_VALUE) 3: { 4: DWORD dwSize = GetFileSize(hFile, NULL); 5: DWORD dwRead = 0; 6: CHAR *bufferA = new CHAR[dwSize+2]; 7: memset(bufferA, 0, dwSize+2); 8: if (ReadFile(hFile, bufferA, dwSize, &dwRead, NULL)) 9: { 10: DWORD i = 0, j = 0; 10: int i = 0, j = 0; 11: for (; i < dwSize+2-7; ++i) 11: for (; i < (int)dwSize+2-7; ++i) 12: {

GetFileSize 는 INVALID_FILE_SIZE(0xFFFFFFFF)을 리턴할 수 있고 new 연산자 역시 실패할 수 있어 아래와 같이 수정하는 것이 좋습니다.

1: HANDLE hFile = CreateFile(str.GetBuffer(), GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); 2: if (hFile != INVALID_HANDLE_VALUE) 3: { 4: DWORD dwSize = GetFileSize(hFile, NULL); 4a: if (dwSize != INVALID_FILE_SIZE) 4b: { 5: DWORD dwRead = 0; 6: CHAR *bufferA = new CHAR[dwSize+2]; 6a: if (bufferA) 6b: { 7: memset(bufferA, 0, dwSize+2); 8: if (ReadFile(hFile, bufferA, dwSize, &dwRead, NULL)) 9: { 10: int i = 0, j = 0; 11: for (; i < (int)dwSize+2-7; ++i) 12: {

[DebuggingToolbox]Portable Executable 헤더 얻기

DebugMachine — Tue, 18 Aug 2009 11:45:48 GMT

"이 문서는 http://blogs.msdn.com/debuggingtoolbox/default.aspx blog 의 번역이며 원래의 자료가 통보 없이 변경될 수 있습니다. 이 자료는 법률적 보증이 없으며 의견을 주시기 위해 원래의 blog 를 방문하실 수 있습니다. ( http://blogs.msdn.com/debuggingtoolbox/archive/2007/05/03/windbg-script-get-portable-executable-headers.aspx )

[Windbg Script] Portable Executable 헤더 얻기

There are several tools you can use to read the image headers, like Dumpbin.exe and Link.exe, for instance. You can, however, also use Windbg for doing that! In other words, during your debugging session you can see the header from an image file without executing any other tool except this script.

Dumpbin.exe와 Link.exe 와 같이 이미지 헤더를 읽을 수 있는 많은 툴이 있지만 Windbg 또한 읽을 수 있습니다. 다시 말하면 디버깅 도중 다른 툴의 도움이 필요 없이 이미지 헤더를 읽을 수 있습니다.

This is a very simple script that lists all loaded modules and gives you two options:

- Visualize a summarized view of the header for a specific image.

- Visualize a detailed view of the header for a specific image.

Actually, there is one more option: run the script and provide the module as an argument. J

이번에 알려드릴 스크립트는 매우 간단한 것으로 로드 되어 있는 모든 모듈을 리스트 하는 것으로 두 가지 옵션이 있습니다.

- 특정 이미지의 간략한 헤더 정보만 보이기

- 특정 이미지의 자세한 헤더 정보 보이기

인자로 모듈을 전달할 수 있는 옵션이 하나 더 있습니다.

디버깅 스립트를 실행하는 중에 인자를 사용하는 방법을 이 스크립트를 통해서 배울 수 있었습니다. 매우 좋은 기능으로 다음 Windbg 버전에서는 이것을 추가 하였으면 합니다. 여러분 또한 스크립트를 실행하고 인자를 변경하면서 배우실 수 있습니다.

아래와 같이 스크립트를 실행할 수 있습니다.

$$>a<scriptname.txt arg1 arg2 arg3 … <- >a<에 주의

별칭을 사용하여 스크립트 소스코드에서 인자를 받을 수 있습니다.

${$arg1} <- 별칭, 가상 레지스터가 아닙니다.

$art1 에서 시작해서 $arg<n> 로 이어 집니다.

저의 스크립트에서 인자를 사용할 수 있는지 확인해 보았고 이 아이디어를 사용하기를 원하실 수도 있습니다.

문법상 에러를 발견할 경우 한번 더 실행하면 실행될 것 입니다. 이러한 문제는 별칭과 관련된 것으로 이미 이전에 말씀 드린바 있습니다.

아래 스크린 샷이 있습니다.

스크립트를 실행할 때 모듈 이름을 사용해 보도록 하겠습니다.

Source code for GET_HEADERS.TXT:

$$ =============================================================================

$$ Get headers from images.

$$ Compatibility: Win32.

$$ Usage: $$>< to run the program without arguments.

$$ $$>a<scriptfile dllname to run the program using arguments.

$$ Example: $$>a<myscripts\get_headers.txt kernel32

$$ If necessary change the filename below to include your path and filename.

$$ Default file name and path should be changed below if necessary.

$$ Roberto Alexis Farah

$$ Blog: http://blogs.msdn.com/debuggingtoolbox/

$$ All my scripts are provided "AS IS" with no warranties, and confer no rights.

$$ =============================================================================

.block

{

as ${/v:ScriptName} MYSCRIPTS\\GET_HEADERS.TXT

}

r @$t0 = 0

.if(${/d:$arg1})

{

.printf /D "\nYou selected the module: ${$arg1}\n\n"

!dh ${$arg1} -a

}

.else

{

.printf /D "\n\nSelect option below for loaded modules:\n\n"

.foreach(obj {lm1mo})

{

.block

{

.printf "${obj}\t <-- "

.printf /D "<link cmd=\".echo ${obj};!lmi ${obj};ad ${/v:ScriptName};$$><${ScriptName}\">Summarized</link> or "

.printf /D "<link cmd=\".echo ${obj};!dh ${obj} -a;ad ${/v:ScriptName} *;$$><${ScriptName}\">Detailed</link>\n"

}

.printf /D "\nAfter selection scroll up the screen to see the information.\n"

}

[Windbg Command]dt 사용 팁

DebugMachine — Thu, 18 Jun 2009 11:48:56 GMT

디버깅을 진행 하다 보면 특정 메모리의 tag는 확인하였으나 구조체를 알 수 없는 경우가 많이 있습니다. 이 때 dt 명령을 적절히 사용하면 손쉽게 원하는 정보를 얻을 수 있습니다.

먼저 process 정보를 확인해 본 후 fffffa8004952c10 가 어떤 구조체를 가지는지 확인해 보도록 하겠습니다.

lkd> !process 0 0 explorer.exe
PROCESS fffffa8004952c10
    SessionId: 1 Cid: 12dc    Peb: 7fffffdb000 ParentCid: 1248
    DirBase: a3fd9000 ObjectTable: fffff8800b1a30f0 HandleCount: 1003.
    Image: explorer.exe

!pool 명령을 사용해서 이 주소는 NonPagedPool 이고 Proc 즉 Process object 와 관련이 있다는 것을 알 수 있습니다.

lkd> !pool fffffa8004952c10 2
Pool page fffffa8004952c10 region is Nonpaged pool
*fffffa8004952bd0 size: 430 previous size: 130 (Allocated) *Proc (Protected)
Pooltag Proc : Process objects, Binary : nt!ps

Process 와 관련이 있다는 것을 알았으므로 아래와 깉은 방법으로 어떤 구조체들이 존재하는지 확인해 볼 수 있습니다.

lkd> dt nt!_*proc*
          ntkrnlmp!_KPROCESSOR_STATE
          ntkrnlmp!_PROCESSOR_POWER_STATE
          ntkrnlmp!_KPROCESS
          ntkrnlmp!_EPROCESS
          ntkrnlmp!_EPROCESS_QUOTA_BLOCK
          ntkrnlmp!_WOW64_PROCESS
          ntkrnlmp!_SE_AUDIT_PROCESS_CREATION_INFO
          ntkrnlmp!_ALPC_PROCESS_CONTEXT
          ntkrnlmp!_WHEA_GENERIC_PROCESSOR_ERROR
          ntkrnlmp!_RTL_USER_PROCESS_PARAMETERS
          ntkrnlmp!_PROCESSOR_CACHE_TYPE
          ntkrnlmp!_WHEA_GENERIC_PROCESSOR_ERROR_VALIDBITS

감사합니다.

[Stack Trace]System PTEs 는 무엇일까요?

DebugMachine — Thu, 11 Jun 2009 15:30:59 GMT

"이 문서는 http://msdn.microsoft.com/en-us/magazine/default.aspx 의 번역이며 원래의 자료가 통보 없이 변경될 수 있습니다. 이 자료는 법률적 보증이 없으며 의견을 주시기 위해 원래의 site를 방문하실 수 있습니다. (http://msdn.microsoft.com/en-us/magazine/dd420461.aspx)"

System PTEs는 무엇일까요?

Bob Golding and David Butler

내용
어떤 API들이 이 주소들을 Map 하는데 사용될까?

Bugcheck 0x3F 상황에서 Track PTEs 가 항상 필요한 것은 아니다

커널 스택

System PTEs 는 모든 PTEs 와 비슷하게 시스템 어드레스 공간을 나타내는데 사용 됩니다. 그렇다면 시스템 리소스에서 이 두 PTEs가 다른 점은 무엇일까요? System PTEs 는 시스템을 위해서만 사용되고 System PTEs 는 시스템 어드레스 공간 Map 의 동적인 슬롯 입니다. 다시 말해 많은 어드레스 공간이 시스템 어드레스 공간에 Map 되어 있고 동적으로 버퍼 또는 커널 스택 등에 Map 되는 것 입니다. 이 주소공간은 넌페이지드풀과 페이지드 풀 사이에 위치하고 아래 정보는 mi386.h 에서 발최 한 것 입니다.

E1000000 | 페이지 시스템 공간 |
 | 커널 모드만 접근 가능 |
 | |
 | |
 +-----------------------------------------+
 | |
 | 시스템 PTE 공간 – 커널 스택, |
 | MDL을 시스템 가상 주소에 Map함 |
 | 커널 모드만 접근 가능 |<----- 예약된 동적 map 을 위한 공간
 | Kernel mode access only. |
 | |
 +-----------------------------------------+
 | |
 | 넌페이지 시스템 공간 |
 | 커널 모드만 접근 가능 |
 | |
 +------------------------------------------+
FFBE0000 | 크래시 덤프 드라이버 역억 |
 | 커널 모드만 접근 가능 |
 +------------------------------------------+

시스템 PTEs 의 크기는 페이지드와 넌페이지드 풀의 크기에 따라 변경 됩니다. 또한 시스템 주소 공간으로 /3GB 와 같은 옵션에 영향을 받습니다.

어떤 API들이 이 주소들을 Map 하는데 사용될까?
MiMapLockedPagesInUserSpace, MiUnmapLockedPagesInUserSpace, MmMapLockedPages, and MmUnmapLockedPages 와 같은 API 들이 주소를 Map 하는데 사용 됩니다. 이 API 들은 버퍼를 동적 주소 공간에 map 하는 역할을 하며 전체 버퍼를 map 하고자 할 때 버퍼의 크기가 얼마나 많은 연속된 page 가 사용될 지 결정 합니다.

위에서 보신 것과 같이 모든 Map API 에는 Unmap API 가 존재 합니다. 이것은 아주 중요한데 모든 버퍼는 Unmap 되어야 합니다. Map 된 page 가 Unmap 되지 않는다면 No more PTEs 문제가 발생할 것 입니다. System PTEs 가 낮아 질 경우 성능 또한 낮아질 것이며 Bugcheck 3F 가 나타날 것 입니다. 하지만 NT 에서 리소스를 잘 처리하기 때문에 이러한 현상은 자주 발생하지 않습니다.

Bugcheck 0x3F 상황에서 Track PTEs 가 항상 필요한 것은 아니다
System Ptes 가 부족한 현상은 보통 TrackPtes 를 사용하여 얼마나 많은 PTEs 가 사용되었는지 확인 합니다. 하지만 가끔은 이것이 문제를 찾는데 충분하지 않을 수 있습니다. TrackPtes 는 sysptes.c 에 구현되어 있지 않기 때문에 모든 System PTEs 사용이 기록되지는 않고 MiReserveSystemPtes 와 같은 함수를 호출할 때 기록 됩니다.

커널 스택

Sysptes 를 소모하지만 기록되지 않는 요인 중 하나가 커널 스택 입니다. 다행이도 메모리 매니저에서 몇 가지 전역 변수를 통해 얼마나 많은 sysptes 가 커널 스택에 사용되었는지 알 수 있게 해 줍니다. 아래의 예를 보면 23,000 개의 sysptes 가 존재 합니다. 이것은 아주 작은 숫자로 /3GB 가 적용 되었을 경우 많이 나타나는 결과 입니다. 17,860 개의 sysptes 가 커널 스택으로 사용되고 있으며 프로세스와 스레드의 분석 만으로는 문제점을 찾을 수 없습니다. 문제점은 사용자의 응용 프로그램이 많은 GDI 스레드를 사용하고 있다는 것 입니다. 장비의 메모리 상태를 분석 한 후 system ptes 의 갯수를 늘리는 것 과 같은 조취를 취해야 할 것 입니다.

1: kd> !sysptes

System PTE Information
Total System Ptes 23006

1: kd> dc nt!MmKernelStackPages l 1
80483680 000045c4 .E..
1: kd> ?45c4
Evaluate expression: 17860 = 000045c4

1: kd> dc MmLargeStacks l 1
8048368c 0000037b
1: kd> dc MmSmallStacks l 1
8048367c 00000385
1: kd> ?37b*f
Evaluate expression: 13365 = 00003435
1: kd> ?385*3
Evaluate expression: 2703 = 00000a8f
1: kd> ?3435+a8f+37b+385
Evaluate expression: 17860 = 000045c4

역자주) UI thread 의 경우 Stack 이 15page(60kb) 이고 일반 Thread 의 경우 3page(12kb) 그리고 각각의 커널 스택에 보호 페이지가 1씩 필요하다.

Bob Golding 은 1997년부터 Microsoft 에서 일하고 있습니다. 그는 Global Escalation Services team 의 Senior Escalation Engineer 로 많은 고객의 중요 문제를 지원하고 있습니다.

David Butler 은 2000년부터 Microsoft 에서 일하고 있습니다. 그는 Global Escalation Services team 의 Escalation Engineer 로 많은 고객의 중요 문제를 지원하고 있습니다.

IDT 와 ISR

DebugMachine — Tue, 17 Mar 2009 03:40:28 GMT

오늘은 IDT 와 ISR 에 대해서 알려 드리고자 합니다. IDT, ISR 에 대해 설명하고자 하면 책을 한권을 써야 하고 저의 내공이 그렇게 깊지 않기 때문에 Windbg 를 사용해서 IDT 에서 ISR 을 찾아가는 과정을 설명 드리고자 합니다.

먼저 !idt 명령을 사용하면 IDT 의 내용이 확인 가능 합니다.

0: kd> !idt

Dumping IDT:

37:    80a7817c hal!PicSpuriousService37
3d:    80a79560 hal!HalpApcInterrupt
41:    80a793b4 hal!HalpDispatchInterrupt
50:    80a78254 hal!HalpApicRebootService
51:    89535044 serial!SerialCIsrSw (KINTERRUPT 89535008)
52:    8956d044 i8042prt!I8042MouseInterruptService (KINTERRUPT 8956d008)
53:    895f8044 USBPORT!USBPORT_InterruptService (KINTERRUPT 895f8008)
             USBPORT!USBPORT_InterruptService (KINTERRUPT 89571008)
             USBPORT!USBPORT_InterruptService (KINTERRUPT 89569008)
63:    895fe044 VIDEOPRT!pVideoPortInterrupt (KINTERRUPT 895fe008)
72:    8a10f044 atapi!IdePortInterrupt (KINTERRUPT 8a10f008)
73:    89b08044 storport!RaidpAdapterInterruptRoutine (KINTERRUPT 89b08008)
83:    89b38044 SCSIPORT!ScsiPortInterrupt (KINTERRUPT 89b38008)
93:    89be6044 SCSIPORT!ScsiPortInterrupt (KINTERRUPT 89be6008)
a2:    89537044 serial!SerialCIsrSw (KINTERRUPT 89537008)
a3:    8a34d044 storport!RaidpAdapterInterruptRoutine (KINTERRUPT 8a34d008)
b1:    8a35d044 ACPI!ACPIInterruptServiceRoutine (KINTERRUPT 8a35d008)
b3:    8953a044 i8042prt!I8042KeyboardInterruptService (KINTERRUPT 8953a008)
b4:    895f1044 NDIS!ndisMIsr (KINTERRUPT 895f1008)
c1:    80a783e0 hal!HalpBroadcastCallService
d1:    80a77754 hal!HalpClockInterrupt
e1:    80a787f4 hal!HalpIpiHandler
e3:    80a78618 hal!HalpLocalApicErrorService
fd:    80a78d64 hal!HalpProfileInterrupt
fe:    80a78f0c hal!HalpPerfInterrupt

자 여기서 키보드 인터럽트를 직접 IDT 에서 ISR 까지 따라가는 작업을 해 보겠습니다.

먼저 r idt 명령으로 idtr 레지스터의 값을 확인하여 idt 의 address 를 찾습니다.

0: kd> r idtr
idtr=8003f400

keyboard interrupt 에 해당하는 index b3 을 확인 합니다.

0: kd> dt _KIDTENTRY 8003f400 + b4 * @@(sizeof(_KIDTENTRY))
nt!_KIDTENTRY
   +0x000 Offset           : 0xa044
   +0x002 Selector         : 8
   +0x004 Access           : 0x8e00
   +0x006 ExtendedOffset   : 0x8953

실제로 virtual address 에 있는 내용을 확인해 봅니다.

0: kd> dd 8003f400 + b3 * @@(sizeof(_KIDTENTRY)) L2
8003f9a0 0008a044 89538e00

여기서 ExtendedOffset 과 Offset 을 합친 0x8953a044 가 실제로 Interrupt 가 발생하였을 때 실행되는 Code 의 위치인데 Windows 에서는 이것을 Interrupt Object 라는 것으로 관리 합니다. 이 구조체는 아래와 같습니다.

0: kd> dt _KINTERRUPT
nt!_KINTERRUPT
   +0x000 Type             : Int2B
   +0x002 Size             : Int2B
   +0x004 InterruptListEntry : _LIST_ENTRY
   +0x00c ServiceRoutine   : Ptr32     unsigned char
   +0x010 ServiceContext   : Ptr32 Void
   +0x014 SpinLock         : Uint4B
   +0x018 TickCount        : Uint4B
   +0x01c ActualLock       : Ptr32 Uint4B
   +0x020 DispatchAddress : Ptr32     void
   +0x024 Vector           : Uint4B
   +0x028 Irql             : UChar
   +0x029 SynchronizeIrql : UChar
   +0x02a FloatingSave     : UChar
   +0x02b Connected        : UChar
   +0x02c Number           : Char
   +0x02d ShareVector      : UChar
   +0x030 Mode             : _KINTERRUPT_MODE
   +0x034 ServiceCount     : Uint4B
   +0x038 DispatchCount    : Uint4B
   +0x03c DispatchCode     : [106] Uint4B

결국 0x895f1044 는 KINTERRUPT 구조체의 0x3c 위치에 있는 DispatchCode 의 Address 입니다.

0: kd> ? 8953a044 - 3c
Evaluate expression: -1991008248 = 8953a008

이 값은 !idt 의 결과에서 확인한 8953a044 의 값과 동일 합니다.

b3: 8953a044 i8042prt!I8042KeyboardInterruptService (KINTERRUPT 8953a008)

자 그럼 확인해 볼까요?

0: kd> dt _KINTERRUPT 8953a008
nt!_KINTERRUPT
   +0x000 Type             : 22
   +0x002 Size             : 484
   +0x004 InterruptListEntry : _LIST_ENTRY [ 0x8953a00c - 0x8953a00c ]
   +0x00c ServiceRoutine   : 0xbaabe0a5     unsigned char i8042prt!I8042KeyboardInterruptService+0
   +0x010 ServiceContext   : 0x899eac88
   +0x014 SpinLock         : 0
   +0x018 TickCount        : 0xffffffff
   +0x01c ActualLock       : 0x899ead48 -> 1
   +0x020 DispatchAddress : 0x8083a63c     void nt!KiInterruptDispatch+0
   +0x024 Vector           : 0x1b3
   +0x028 Irql             : 0xa ''
   +0x029 SynchronizeIrql : 0xa ''
   +0x02a FloatingSave     : 0 ''
   +0x02b Connected        : 0x1 ''
   +0x02c Number           : 0 ''
   +0x02d ShareVector      : 0 ''
   +0x030 Mode             : 1 ( Latched )
   +0x034 ServiceCount     : 0
   +0x038 DispatchCount    : 0xffffffff
   +0x03c DispatchCode     : [106] 0x56535554

DispatchCode 에는 어떤 내용이 있는지 확인해 보도록 하겠습니다.

lkd> u 89c03008 + 3c L30
89c03044 54              push    esp
89c03045 55              push    ebp
89c03046 53              push    ebx
89c03047 56              push    esi
89c03048 57              push    edi
89c03049 83ec54          sub     esp,54h
89c0304c 8bec            mov     ebp,esp
89c0304e 89442444        mov     dword ptr [esp+44h],eax
89c03052 894c2440        mov     dword ptr [esp+40h],ecx
89c03056 8954243c        mov     dword ptr [esp+3Ch],edx
89c0305a f744247000000200 test    dword ptr [esp+70h],20000h
89c03062 0f8531010000    jne     89c03199
89c03068 66837c246c08    cmp     word ptr [esp+6Ch],8
89c0306e 7423            je      89c03093
89c03070 8c642450        mov     word ptr [esp+50h],fs
89c03074 8c5c2438        mov     word ptr [esp+38h],ds
89c03078 8c442434        mov     word ptr [esp+34h],es
89c0307c 8c6c2430        mov     word ptr [esp+30h],gs
89c03080 bb30000000      mov     ebx,30h
89c03085 b823000000      mov     eax,23h
89c0308a 668ee3          mov     fs,bx
89c0308d 668ed8          mov     ds,ax
89c03090 668ec0          mov     es,ax
89c03093 648b1d00000000 mov     ebx,dword ptr fs:[0]
89c0309a 64c70500000000ffffffff mov dword ptr fs:[0],0FFFFFFFFh
89c030a5 895c244c        mov     dword ptr [esp+4Ch],ebx
89c030a9 81fc00000100    cmp     esp,10000h
89c030af 0f82b8000000    jb      89c0316d
89c030b5 c744246400000000 mov     dword ptr [esp+64h],0
89c030bd 648b0d24010000 mov     ecx,dword ptr fs:[124h]
89c030c4 fc              cld
89c030c5 83652c00        and     dword ptr [ebp+2Ch],0
89c030c9 f64103ff        test    byte ptr [ecx+3],0FFh
89c030cd 7522            jne     89c030f1
89c030cf 8b5d60          mov     ebx,dword ptr [ebp+60h]
89c030d2 8b7d68          mov     edi,dword ptr [ebp+68h]
89c030d5 89550c          mov     dword ptr [ebp+0Ch],edx
89c030d8 c74508000ddbba mov     dword ptr [ebp+8],0BADB0D00h
89c030df 895d00          mov     dword ptr [ebp],ebx
89c030e2 897d04          mov     dword ptr [ebp+4],edi
89c030e5 bf0830c089      mov     edi,89C03008h
89c030ea e96d64c3f6      jmp     nt!KiInterruptDispatch (8083955c)

Dispatch code 는 대부분의 내용이 모든 Interrupt 에서 공통적으로 사용되는 것인데 파란색으로 되어 있는 부분이 각각의 Interrupt 마다 다르다. edi 에 89c03008h 즉 이 Interrupt 의 Interrupt Object 값을 넣고 nt!KiInterruptDispatch 로 Jump 합니다.

KiInterruptDispatch 코드를 살펴 보면

lkd> u nt!KiInterruptDispatch L100
nt!KiInterruptDispatch:
8083955c 8bec            mov     ebp,esp
8083955e 8b4724          mov     eax,dword ptr [edi+24h]
80839561 8b4f29          mov     ecx,dword ptr [edi+29h]
80839564 50              push    eax
80839565 83ec04          sub     esp,4
80839568 54              push    esp
80839569 50              push    eax
8083956a 51              push    ecx
8083956b ff1554108080    call    dword ptr [nt!_imp__HalBeginSystemInterrupt (80801054)]
80839571 0ac0            or      al,al
80839573 7449            je      nt!KiInterruptDispatch+0x62 (808395be)
80839575 64ff0544060000 inc     dword ptr fs:[644h]
8083957c 83ec0c          sub     esp,0Ch
8083957f 648b0d1c000000 mov     ecx,dword ptr fs:[1Ch]
80839586 83790800        cmp     dword ptr [ecx+8],0
8083958a c745f400000000 mov     dword ptr [ebp-0Ch],0
80839591 753f            jne     nt!KiInterruptDispatch+0x76 (808395d2)
80839593 8b771c          mov     esi,dword ptr [edi+1Ch]
80839596 f00fba2e00      lock bts dword ptr [esi],0
8083959b 7229            jb      nt!KiInterruptDispatch+0x6a (808395c6)
8083959d 8b4710          mov     eax,dword ptr [edi+10h]
808395a0 50              push    eax
808395a1 57              push    edi
808395a2 ff570c          call    dword ptr [edi+0Ch]

edi+0Ch 즉 edi 에는 InterruptObject 구조체의 포인터가 들어 있고 0Ch 위치에는 ServiceRoutine 이 있으므로 해당 Interrupt 의 Service routine 을 호출하는 것입니다.

마지막으로 그럼 ISR 을 개발하는 개발자는 이런 것들을 직접 넣어줘야 할까요?

아래 링크를 확인해 보면 ISR 을 만드는 것에 대한 자세한 설명이 있습니다.

http://msdn.microsoft.com/en-us/library/ms795203.aspx

간단히 설명하자면 개발자는 Interrupt 에 대한 ServiceRoutine, SpinLock 등을 정의 한 후 IoConnectInterrupt 함수를 호출하면 결과로 _IO_CONNECT_INTERRUPT 구조체가 나오는 것 입니다.

아래는 WDK Sample 중 PnPi8042 에서 사용된 IoConnectInterrupt 에 대한 내용으로 자세한 내용은 WDK Sample 중 \WinDDK\6001.18000\src\input\pnpi8042 를 참조하면 됩니다.

status = IoConnectInterrupt(
    &(KeyboardExtension->InterruptObject),
    (PKSERVICE_ROUTINE) I8042KeyboardInterruptService,
    self,
    &KeyboardExtension->InterruptSpinLock,
    KeyboardExtension->InterruptDescriptor.u.Interrupt.Vector,
    (KIRQL) KeyboardExtension->InterruptDescriptor.u.Interrupt.Level,
    configuration->InterruptSynchIrql,
    KeyboardExtension->InterruptDescriptor.Flags
      == CM_RESOURCE_INTERRUPT_LATCHED ? Latched : LevelSensitive,
    (BOOLEAN) (KeyboardExtension->InterruptDescriptor.ShareDisposition
        == CmResourceShareShared),
    KeyboardExtension->InterruptDescriptor.u.Interrupt.Affinity,
    configuration->FloatingSave
    );