!analyze -v

[AskPerf]Windows 7 / Windows Server 2008 R2: Upgrade Paths, Registry Enhancements, Crash Dumps and Page File Sizing

2009-10-19T04:11:07Z

http://blogs.technet.com/askperf/archive/2009/10/01/windows-7-windows-server-2008-r2-upgrade-paths-registry-enhancements-crash-dumps-and-page-file-sizing.aspx

위의 문서에서는 Vista 에서 Windows 7 으로 그리고 Windows 2003 또는 2008 dptj 2008 R2로 upgrade 할 수 있는 Path 에 대해서 설명하고 있습니다.

아래의 방식은 지원하지 않습니다.

x86 에서 X64로 x64에서 x86으로의 Upgrade
다른 언어로의 Upgrade (영문 –> 한글)
다른 빌드로의 변환 (Checked 에서 Free)

레지스트리를 관리하는 Configuration Manager 의 향상된 점

기존의 Configuration Manager 는 하나의 lock 을 사용해서 레지스트리 정보를 가지고 있는 Key Control Block(KVB)블럭을 동기화 했고 이로 인해 여러 문제가 발생하였고 이 부분이 수정 되었습니다. 각각의 레지스트리 하이브는 각각의 KCB 테이블을 가지고 정말 필요할 경우만 lock 을 수행하게 됩니다.

page file size 에 대해서 이야기 하고 있습니다.

Window 7 이전에는 페이지파일 크기가 다양한 요인에 의해서 달라 지게 되어 있었습니다. 그리고 일반적으로 물리 메모리 +1 또는 물리 메모리 * 몇 으로 가이드 되고 있었습니다. Windows 7 과 2008 에서는 기본 크기가 설치 되어 있는 물리 메모리 크기 입니다. Windows 7 과 2008 은 기본적으로 커널 덤프로 설정되어 있으며 전체 메모리 덤프로 설정할 경우 페이지 파일은 물리 메모리 + 300MB 로 설정되어 있을 것 입니다.

새로운 Dump 유지 방식

시스템이 크래쉬 된 후 메모리는 페이지 파일로 쓰여지고 재 부팅되면서 다른 공간으로 복사 되게 됩니다. 그리고 Windows Customer Experience Improvement Program 이 설정됭 ㅓ 있는 경우 Microsoft 로 정보를 upload 하게 됩니다 이후 Server, Client SKU, Domoin 에 Join 하였는지 남은 공간을 얼마나 되는지 등을 확인하여 덤프를 남겨 놓을지 삭제할 지를 결정 합니다.

장비가 Server 이거나 Domoni 에 join 하지 않은 경우 항상 덤프는 유지 됩니다. 클라이언트이고 Domoin 에 join 하지 않았다면 25GB 이상의 공간이 디스크에 남아 있다면 유지하게 됩니다.

[Hyper-V]How to: Upgrade Hyper-V to Hyper-V R2

2009-10-19T03:09:02Z

아래 문서에서 Hyper-V 에서 Hyper-V R2 로 upgrade 하는 내용을 설명하고 있습니다.

http://blogs.technet.com/tonyso/archive/2009/10/16/hyper-v-how-to-upgrade-hyper-v-to-hyper-v-r2.aspx

[PowerShell]PowerShell Cmdlet Reference

2009-10-09T03:42:57Z

앞으로는 PowerShell 을 잘 사용하지 못하면 Windows Admin 을 할 수 없을 것이라고 합니다. UI를 가지고 있는 많은 Tool 들 또한 내부에서는 PowerShell 을 사용하고 있습니다.

Failover cluster, AD, 등 다양한 Cmdlet 의 참조가 아래 링크에서 제공되고 있습니다.

http://blogs.technet.com/tonyso/archive/2009/10/08/hyper-v-how-t0-powershell-cmdlet-reference.aspx

[Windows]Boot 가 오래 걸리는 경우

2009-10-09T03:40:01Z

아래 문서에서는 Boot 시점에 시간이 많이 걸리는 경우 어떻게 이를 분석할 수 있는지를 알려 주고 있습니다.

http://www.microsoft.com/whdc/system/sysperf/On-Off_Transition.mspx

또한 Procss Monitor 의 Boot log 기능을 사용해서 부팅 시점에 발생하는 I/O를 모니터링할 수도 있습니다.

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

[Hyper-V]Clustered Hyper-V Upgrades from Server 2008 to Server 2008 R2

2009-10-09T03:30:25Z

Windows 2008 R2의 Failover cluster에는 CSV 와 같은 중요한 기능들이 추가 되었습니다. 아래 링크에서는 Windows 2008 Failover cluster 를 Windows 2008 R2 Failover cluster로 Upgrade 하는 방법과 마이그레이션 관련된 정보가 들어 있습니다.

http://blogs.msdn.com/clustering/archive/2009/10/08/9905089.aspx

[Sysinternals]Disk2vhd1.0 Release

2009-10-09T03:28:14Z

가상화 환경이 점점 다가 오고 있는 상태에서 Sysinternals 에서 새로운 툴을 발표 하였습니다. Computer 가 켜져 있는 상태에서 물리 디스크를 Hyper-V 나 Virtual PC 에서 사용할 수 있는 VHD 파일로 변환해 주는 툴 입니다. Test 환경을 가상화 한다 던지 고객 지원을 하는 도중 재현을 위해 Windows 자체를 받아야 하는 경우(개인 정보가 없는 경우)에 사용할 수 있을 것 같습니다.

http://technet.microsoft.com/en-us/sysinternals/ee656415.aspx

[Virtualization]Hyper-V How to: Find Hyper-V Patches

2009-10-01T03:54:01Z

http://blogs.technet.com/tonyso/archive/2009/09/30/hyper-v-how-to-find-hyper-v-patches.aspx

요약

Hyper-V 에 대한 패치를 찾는 방법에 대해서 이야기 하고 있습니다. 다음 링크로 이동한 후 http://technet.microsoft.com/en-us/library/dd430893.aspx Community Content 를 클릭하고 Annotations 를 클릭하여 RSS Feed로 최신 Patch 에 대한 정보를 받아 보실 수 있습니다.

[Virtualization]Hyper-V How to: Turn off IPV6

2009-10-01T03:46:07Z

http://blogs.technet.com/tonyso/archive/2009/09/28/hyper-v-how-to-turn-off-ipv6.aspx

요약 : IPV6는 Windows 2008 서버에 기본으로 활성화 되어 있습니다. 그런데 VM에서 문제가 있어 IPV6를 사용하지 않게 하려면 레지스트리를 직접 수정해야 하는 불편이 있는데 아래 링크에 있는 Microsoft Fix it 을 사용하면 편리하게 작업을 수행할 수 있습니다.

The installation of the Exchange Server 2007 Hub Transport role is unsuccessful on a Windows Server 2008-based computer

http://support.microsoft.com/kb/952842/en-us

요약 : IPV6 때문에 Microsoft Exchange Server 2007 Hub Transport role 이 설치 되지 않는 경우 Fix it을 사용해서 IPV6를 Disable

감사합니다.

[Virtualization]Hypervisor is not running error: how to fix

2009-10-01T03:38:41Z

가상화가 새로운 트랜드로 자리 잡았고 가상화 서버들이 많이 도입되고 있습니다. 앞으로는 가상화에 대한 정보를 공유 하도록 하겠습니다.

Hypervisor is not running error: How to fix

http://www.microsoft.com/video/en/us/details/25d07f2e-b2e0-4c0c-b456-79b08bfe58be

요약 : Host 의 BIOS 에서 Virtualization, DEP가 활성화 되었는지 확인 해야 합니다. 각 Hardware vendor 에서 Virtualization과 DEP에 대해 용어가 다르기 때문에 Manual 을 확인 하셔야 합니다.

감사합니다.

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

2009-10-01T03:25:03Z

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

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]실력이 시험되는 장, 하드웨어 조사하기

2009-09-04T10:19:22Z

"이 문서는 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

2009-09-04T03:54:31Z

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!

[Channel9]Melur Raghuraman: Inside Windows 7 - Diagnostics and Troubleshooting

2009-09-04T03:51:48Z

Channel 9 의 Going Deep 에 새로운 동영상이 올라 왔습니다. Windows 7 에 추가된 분석 및 문제 해결 방법에 대한 소개를 하는 것으로 보입니다. 아직 저도 동영상을 보지 않았기 때문에 자세한 설명은 나중에 추가 하도록 하겠습니다.

Melur Raghuraman: Inside Windows 7 - Diagnostics and Troubleshooting

Windows Development Manager Melur Raghuraman and team have taken troubleshooting and diagnostics to a whole new level in Windows 7. For one thing, Windows 7 uses managed code "natively" as PowerShell has become the de facto language used for creating diagnostic algorithms that live inside of diagnostic packages. So, when something goes wrong eventually a PowerShell script runs and diagnosis happens.
You've probably already noticed the information flag that appears in your task bar notification area when Windows wants to tell you something important. Well, in order for Windows 7 to inform you of a problem and its solution it must first diagnose the issue and collect troubleshooting steps. Sometimes, and more so than ever before, Windows will simply fix the problem and let you know about it - this is a trend that will only become more common over time and with each iteration of Windows going forward. This troubleshooting fabric has both client and server (cloud) components.
How does this all work, exactly? What's the story?
Tune in. Lots to learn here. The new troubleshooting and diagnostics capabilities in Windows 7 marks a signficant step forward in the evolution of Windows supportability. Of course, you, the human user, can write your own diagnostic scripts - so you'll be more efficient when you need to diganosis and then fix some computer problem.

[Channel9]Silviu Calinoiu: Inside Windows 7 - Fault Tolerant Heap

2009-08-28T11:01:32Z

Windows 7 의 특징 중 하나인 Fault Tolerant Heap 에 대한 동영상 입니다. 많은 Application 들이 Crash 되는 원인이 잘못된 메모리 사용이라고 합니다. Windows 7 에서는 동일 Application 이 잘못된 메모리 참조로 수 회 종료될 경우 Fault Toleant Heap이 자동으로 적용되어 Application이 Crash 되는 것을 막아 줍니다. 자세한 내용은 동영상을 확인하시기 바랍니다.

Silviu Calinoiu: Inside Windows 7 - Fault Tolerant Heap

The Fault Tolerant Heap (FTH) is a subsystem of Windows 7 responsible for monitoring application crashes and autonomously applying mitigations to prevent future crashes on a per application basis. For the vast majority of users, FTH will function with no need for intervention or change on their part.
Principal Development Lead and rock star developer Silviu Calinoiu is the mastermind behind FTH. Here, we go deep into how FTH works and why it's designed the way it is.
The Fault Tolerant Heap is another example of the low level efficiency built into the system: FTH automatically corrects memory faults that cause applications to crash which has the pleasant side effect of preventing future crashes. How does FTH work, exactly? What types of memory problems does it address, specifically? How do developers monitor FTH events and can they override FTH's behavior? What does this all mean to the average user?
FTH, as an autonomous monitoring and correction system, represents a step in the right direction for the evolution of a more homeostatic general purpose operating system. Simply, Windows is getting smarter in the sense that it's increasingly becoming better at self-regulation and self-healing. Yes, there's a very long way to go, but we're making real progress.
You will continue to learn about recoverability in Windows over the coming months here on C9.

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

2009-08-26T11:50:31Z

"이 문서는 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: {