기억속으로 날다

Windows 7이나 Windows Server 2008에서는 새로운 TCP/IP 특성으로 TCP Receive Window Auto-Tuning 를 지원한다. Auto tuning level로써 제공하는 여러 수준이 존재하는 데, 그 중 하나가 experimental 이라는 level이다. 문서 Mail flow to certain domains does not work when you run Exchange Server 2007 on a Windows Server 2008-based computer http://support.microsoft.com/kb/951291/en-us 에서 언급한 것처럼, experimental 옵션은 “Enable the receive window to grow to accommodate extreme scenarios” 기능으로 “Experimental setting can significantly decrease performance in typical scenarios. This setting should be used only for research purposes” 즉 Performance impact이 있는 수준이다. 그러므로, 정상적인 운영환경에서는 고려되기 어려운 level이다. 이것이 의미하는 바, 시스템의 환경 및 auto tuning level에 따라서 TCP/IP를 사용하는 Network 애플리케이션은 여러가지 Performance impact을 받을 수도 있다는 것이다.

최근에 접한 문제는 사용자 환경이 auto-tuning level이 experimental이고, Local File Copy를 목적으로하는 Socket 애플리케이션에서 극심한 성능이슈가 발생하는 문제였다. 이 경우에 간단하게 netsh interface tcp set global autotuninglevel=disable 를 통해서 문제를 해결할 수 있으나, 일일이 해당 시스템을 체크하여 변경하는 것은 애플리케이션 입장에서 보면 어려울 수 있다. 이 경우에 Receive Server의 Socket쪽에 아래와 같은 코드를 추가함으로써 문제를 피해갈 수 있다.

WSA_COMPATIBILITY_MODE mode;
 char dummy[4];
  DWORD ret_dummy;

 mode.BehaviorId = WsaBehaviorAll ;
 mode.TargetOsVersion = NTDDI_WIN7 ; // win7 target
 
 if (WSAIoctl(listen_sock, SIO_SET_COMPATIBILITY_MODE,
  (char *)&mode, sizeof(mode), dummy, 4, &ret_dummy, 0, NULL) == SOCKET_ERROR)
 {
      int err = WSAGetLastError();
      printf("WSAIoctl error: %d", err) ;
 };

관련해서는 다음의 문서를 참조하는 것이 좋겠다.

-       SIO_SET_COMPATIBILITY_MODE control code

-       Using the Windows Headers

알레프는 코엘료가 말하길 태초부터 영원까지 모든 것이 한 지점에 존재하는 것이라는 형이상학적 표현으로 정의하고 있다. 그렇기 때문에 우리는 알레프를 통해서 과거의 내 존재함을 확인할 수 있는 듯 한데, 불교의 용어로 카르마, 즉 내가 가지고 있는 업(보)이 어떻게 생성 되었는지를 내 본질 스스로가 확인할 수 있다는 데에서 의미를 가질 수 있다.

이야기는 시베리아 횡단 열차에 과거의 사랑에 대한 상처, 트라우마를 안고 있는 세 사람이 여행을 한다. 그 중 한 사람은 샤먼을 통해 이미 다른 세계에 존재하는 연인의 끊을 놓지 못하며, 다른 둘은 전생에 인연의 비극으로 인하여 업을 안고 있는 존재다. 현 존재가 자신에 대한 업의 본질을 잘 알지 못하나 결국, 알레프를 통해서 그 업의 본질에 대해서 파악하게 된다. 업의 본질을 정확히 파악하는 것은 업의 끈을 끊을 수 있는 해결점을 찾도록 노력할 수 있다는 데에서 의미가 있을 수 있다. (이에 대해서는 칼 구스타프 융의 심리적 치료의 접근법과 유사한 듯 하다. 그가 환상이나 꿈에 대한 역사적 또는 신화적 해석을 통해서 문제의 원인이 되는 부분에 접근했다는 부분에서 본다면, 알레프를 통해 본 그 환상을 해석함으로써 트라우마의 원인을 파악하는 부분은 매우 유사하지 않을 까) 다음은 그러한 전생의(또는 과거의) 업에 대해서 현 존재가 받아드리는 방식에 대한 코엘료의 답변이 아닐까 한다.

우리는 과거에서 배웠지만 우리가 그 결과물은 아닙니다. 우리는 과거에 고통 받았고, 과거에 사랑했고, 과거에 울고 웃었습니다. 하지만 그런 사실들은 현재에 아무런 쓸모가 없어요. 현재에는 현재의 도전, 현재의 나쁜 일과 좋은 일이 있을 따름입니다…

<알레프, “빗속의 눈물처럼” 중에서>

덧붙여 약간 생각해 볼 필요가 있는 부분은 다음의 문장이었다.

“산다는 것은 경험하는 것이지 삶의 의미에 대해 생각하고 앉아 있는 것은 아니다.(99p)”

개인적으로 게으름의 소산일지 모르지만, 나중에 진정으로 삶의 기쁨으로 누릴 수 있는 것이라 생각했던 자기 성찰의 방법인 내 책상에 앉아 앞서간 성인들의 기록을 통해 내 삶의 의미를 찾고자 했던 방식에서 벗어날 필요가 있을 수도 있음을 생각해 보게 된다.

Side By Side로 .NET 애플리케이션에서 필요에 의해 네이티브 DLL을 골라 올리고 싶을 때, 메니페스트 파일을 이용하게 된다. ClickOnce 애플리케이션의 경우는 알게 모르게, 프로젝트 속성의 보안 탭에 “CLickOnce 보안 설정 사용”이 체크 됨에 따라 app.manifest 파일을 자연스럽게 이용하는 경우가 있다. 이때, 해당 manifest 파일을 수정하여 필요한 네이티브 DLL을 Side By Side 형태로 올릴 수 있다.

예를 들어, Windows 7에서는 Windows Form과 같은 GDI를 사용하는 애플리케이션은 default로 GDI+1.1 과 WIC가 로드되는 데, 필요에 의해 WIC를 사용 안하고 GDI 1.0을 로드할 수도 있다. 이를 위해서는 다음과 같이 메니페스트 파일에 dependency를 추가하여 GDI 1.0 모듈을 로드하도록 지정할 수 있다.

<dependency>

    <dependentAssembly asmv2:dependencyType="preRequisite" >

      <assemblyIdentity type="win32" name="Microsoft.Windows.GdiPlus"

                        processorArchitecture="x86" version="1.0.0.0"

                        publicKeyToken="6595b64144ccf1df" language="*"/>

    </dependentAssembly>

  </dependency>

주의해야 하는 부분은, ClickOnce 기반의 WinForm App의 경우에

<dependency>

    <dependentAssembly dependencyType="preRequisite" >

      <assemblyIdentity type="win32" name="Microsoft.Windows.GdiPlus"

                        processorArchitecture="x86" version="1.0.0.0"

                        publicKeyToken="6595b64144ccf1df" language="*"/>

    </dependentAssembly>

  </dependency>

이와 같이 메니페스트를 추가하였을 경우에는 혹 컴파일시 “오류       1         'Microsoft.Windows.GdiPlus, Version=1.0.0.0, Culture=*, PublicKeyToken=6595b64144ccf1df, ProcessorArchitecture=x86, Type=win32' 파일을 찾을 수 없습니다.           WindowsFormsApplication5” 와 같은 메시지와 함께 ClickOnce Project가 컴파일 되지 않을 수 있으므로 주의해야 한다.

간간히 만나는 이슈중에 Visual C++ 재배포 패키지의 설치 중 문제로 인한 중단 이슈가 간혹 있다. 여러가지 많은 케이스가 있겠지만, 간혹 머신의 상태가 정상적으로 윈도우 업데이트가 안되는 가운데, 재배포 패키지가 정상 설치되지 않는 경우도 적지 않은 경우가 있다.

먼저, VC++ 재배포패키지의 설치 중 문제가 발생한다면, 가장 먼저 확인하는 것이 설치 로그일 것이다. 일반적으로는 vcredist_x86.exe /l [Log File] 와 같이 실행하여 로그를 남길 수 있다. 로그를 살펴보면 어느 정도 인터넷을 뒤져서 원인을 확인하고 fix가 될 텐데, 그렇지 않은 애매한 경우, 즉, 윈도우 업데이트와 관련이 있는 경우라면 정확하게 정보를 얻기가 어려울 수 있다. 다음의 로그를 보자.

MSI (s) (BC:44) [시간정보]: 제품: Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729 -- 오류 1935'Microsoft.VC90.ATL,version="9.0.30729.1",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86",type="win32"' 어셈블리를 설치하는 동안 오류가 발생했습니다. 자세한 내용은 도움말 및 지원을 참조하십시오. HRESULT: 0x8007054F. 어셈블리 인터페이스: IAssemblyCacheItem, 함수: Commit, 구성 요소: {AE56AAF5-F3C0-3D4B-8859-A1E50A3E27BF}

해당 로그에서 오류 1935나 기타 정보는 도움이 별로 되지 않는 다. HRESULT값 0x8007054F 가 힌트인데, 만일, 해당 오류를 경험한다면, cbs.log 를 살펴보는 것을 권고 하고 싶다. (Cbs.log는 sfc.exe 즉, System File Checker 프로그램을 수행하였을 때 뭔가 시스템에 이상이 있다면 이후에 살펴보는 로그 정보로 유용했던 그것이다. 물론, VC++ 재배포 패키지의 설치 중 문제가 있을 때 간혹, sfc.exe /scannow 를 실행하여 문제가 해결되는 경우도 많이 있지만, 해당 문제 0x8007054F  관련 이슈에 대해서 정보를 좀 더 찾아 볼 수 있는 부분이 cbs.log 파일이다. 해당 파일은 C:\Windows\Logs\CBS 폴더에 존재한다.) 문제 시점의 cbs 로그를 살펴보면, 다음과 같은 관련 정보를 찾아 볼 수 있을 지 모른다.  

[시간정보] Error                 CSI    00000320 (F) STATUS_RM_NOT_ACTIVE #50844# from Windows::Rtl::SystemImplementation::DirectRegistryProvider::SysOpenKey(flg = (AllowAccessDenied), key = {provider=NULL, handle=0}, da = (KEY_ALL_ACCESS|KEY_WOW64_64KEY), oa = @0x114e5d4->OBJECT_ATTRIBUTES {s:24; rd:NULL; on:[51]"\Registry\Machine\COMPONENTS\DerivedData\Components"; a:(OBJ_CASE_INSENSITIVE)}, disp = Unmapped disposition: 18146716 (0x0114e59c))[gle=0xd0190005]

이 경우가 맞다면 다음과 같은 작업을 통해서 문제가 해결되는 지 살펴보는 것이 좋을 듯 하다. 방법은 Windows File System Utility라는 fsutil.exe 를 이용해서 다음과 같은 명령을 수행하는 것이다.

fsutil resource setautoreset true DriveLetter:drive

예를 들어, C 드라이브에 운영체제가 인스톨되어 있다면, 관리자 권한으로 “fsutil resource setautoreset true c:\” 와 같이 실행하는 것이며, 이는 Windows File system Transaction log 를 reset 하는 명령이라고 보면 된다. 그리고, 해당 이슈는 transaction log corruption이 원인이라고 보면 될 듯 하다.

최근에 좀 오래된 PC에서 벼르다 IE 9을 윈도우 업데이트를 통해 인스톨하게 되었다. 사용에 그닥 어려움을 못 느꼈는데, 유달리 Flash 컨트롤이 많은 사이트에서는 High CPU 현상으로 사용에 어려움이 겪게 되었다. Flash 컨트롤 때문인가 할 수도 있지만, IE 9을 삭제한 이후에 IE 8에서는 해당 사이트에서 동일한 High CPU현상이 발생하지 않으므로, 그렇다고 보기 어려웠다. 왜 그런지 궁금한지라, 무심코 디버거를 붙여 봤더만,

0:026> !runaway

 User Mode Time

  Thread       Time

   4:91c       0 days 0:06:55.040

  14:4f8       0 days 0:00:00.811

  12:434       0 days 0:00:00.327

  11:8dc       0 days 0:00:00.296

  15:b48       0 days 0:00:00.046

…

0:026> g
…

 (b40.4ac): Break instruction exception - code 80000003 (first chance)

eax=7ffd6000 ebx=00000000 ecx=00000000 edx=77ddd7eb esi=00000000 edi=00000000

eip=77d73370 esp=126bfe90 ebp=126bfebc iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

ntdll!DbgBreakPoint:

77d73370 cc              int     3

0:027> !runaway

 User Mode Time

  Thread       Time

   4:91c       0 days 0:07:02.450

  14:4f8       0 days 0:00:00.826

  12:434       0 days 0:00:00.327

  11:8dc       0 days 0:00:00.312

15:b48       0 days 0:00:00.046

….

4번 쓰레드에서 뭔가 열심히 하고 있는 것으로 보여, 쓰레드를 살펴볼 수 밖에…

ChildEBP RetAddr  Args to Child              

02caa1a8 6ce10316 12466ed4 085be3dc 0000104c nvd3dum!QueryOglResource+0x13b643

02caa2e0 6ce04988 00000000 00000108 00000413 nvd3dum!QueryOglResource+0x7f496

02caa378 6ce04b67 00000000 00000000 00000413 nvd3dum!QueryOglResource+0x73b08

02caa3ac 6cd8e3c5 07c81be0 00000000 00000000 nvd3dum!QueryOglResource+0x73ce7

02caa5c8 6d25e61d 02506800 02caa5dc 00000000 nvd3dum!OpenAdapter+0xffffd5c5

02caa618 6d260d0a 01653248 00000000 01638430 D3D10Level9!LDDMUMDevice::UnderlyingCopySubResource+0xb7

02caa664 6d262bc2 02caa80c 02caa834 02caa85c D3D10Level9!CResourceCopyProxy::GPUCopyMips+0xcc

02caa698 6d264e25 02caa834 02caa80c 02caa85c D3D10Level9!CResourceCopyProxy::GPUCopy+0x53

02caa7e8 6d265810 02caa834 02caa80c 02caa85c D3D10Level9!CResourceCopyProxy::Copy+0x456

02caa884 6ec9e8de 0159b8b8 01653248 00000000 D3D10Level9!UMDevice::ResourceCopyRegion_Default+0x71

02caa8bc 627a01a9 0159a4b8 00000031 00000000 d3d10_1core!CBaseResource<ID3D10Resource,6>::CopySubresourceRegion+0x14e

02caa994 62c9800e 07a13878 016531d8 02caaa10 MSHTML!CDXSystem::CopyTexture+0x195

02caaa50 62c980e7 07a13878 016383c0 00000000 MSHTML!CDXSystem::ReadbackTexture+0x1ae

02caaa70 62caa2d0 016383c0 00000003 00000000 MSHTML!CDXSystem::SaveTextureAsWICBitmap+0x66

02caaa9c 62caa6d4 00000000 00000000 0b388820 MSHTML!CDXSwapChainTargetSurface::SaveAsWICBitmap+0x65

02caaac8 62ca5c17 002f10a8 00000002 00000000 MSHTML!CStagingSurfaceDCHolder::Initialize+0xa7

02caaae0 62a3c490 002f10a8 00000000 02caab14 MSHTML!RefCounted<CStagingSurfaceDCHolder,SingleThreadedRefCount>::Create<IDCHolder,CDXRenderTarget *,CRect const *>+0x74

02caab60 626e41c5 02cad980 02cada7c 02caadd4 MSHTML!CGDIRenderMode::OnBegin+0x84

02caab8c 62bdeb0c 002f10a8 00000000 02cada7c MSHTML!CDXRenderTarget::GetDC+0x1e0

02caabbc 62bdcac7 02caac00 02cab39c 02cad8e0 MSHTML!TSmartResource<CDispSurfaceDCMode>::Acquire<CDispSurface *,CRect *>+0x6a

02caac18 62bdc773 0ccacd88 02cad8e0 00000001 MSHTML!CPeerHolder::DrawPeerWithLegacyPath+0x272

02caade8 62bb2b7e 0ccacd88 02caae20 00000002 MSHTML!CPeerHolder::Draw+0x346

02caae74 62bb29da 00000004 02cab25c 02cab24c MSHTML!CElement::DrawClientLayers+0x26e

02caaf1c 62ded213 00000002 02cab25c 02cab24c MSHTML!CElement::DrawClientLayers+0xc6

02caaf48 62dfea69 02cab25c 02cab24c 02cad980 MSHTML!CLayoutBlock::DrawClientLayers+0x67

02caaf7c 62e271dc 02cab25c 02cab24c 02cad980 MSHTML!HtmlLayout::ContainerBox::DrawClientLayers+0x4f

02cab284 62a996a3 0cba9c98 079ce9c0 02cab418 MSHTML!CDispNode::DrawAtWindowTop+0x27e

02cab354 628f81e5 02cab4c4 00000000 04001200 MSHTML!CDispRoot::DrawEntire+0x254

02cab498 628f7a51 079ce9c0 02cab4c4 003007ec MSHTML!CDispRoot::DrawRoot+0x2d2

02cad89c 62882107 003007ec 00000000 00000000 MSHTML!CView::RenderView+0x1f1

02cada90 62881eac 00300608 00000001 07930390 MSHTML!CDoc::PaintWorker+0x408

02cadaa8 629a290a 00300238 00000000 000ca59d MSHTML!CPaintController::OnUpdateBeat+0x42

02cadad0 629a2ffc 00300238 00000ae4 07930390 MSHTML!CPaintBeat::OnBeat+0x1f0

02cadaf4 628819ff 07930390 00000000 00300238 MSHTML!CPaintBeat::OnVSyncMethodCall+0xbe

02cadb38 62944bec 2a343c98 00000000 0000000f MSHTML!GlobalWndOnPaintPriorityMethodCall+0x104

02cadb80 77a186ef 00040270 0000081f 00000000 MSHTML!GlobalWndProc+0x160

02cadbac 77a179cc 62944afe 00040270 0000000f USER32!InternalCallWinProc+0x23

02cadc24 77a170f4 00000000 62944afe 00040270 USER32!UserCallWinProcCheckWow+0xe0

02cadc80 77a1738f 005741b8 0000000f 00000000 USER32!DispatchClientMessage+0xda

02cadca8 77d8627e 02cadcc0 00000018 02cadd0c USER32!__fnDWORD+0x24

02cadcd4 77a17ba7 77a17bba 02cadd74 2a082903 ntdll!KiUserCallbackDispatcher+0x2e

02cadcd8 77a17bba 02cadd74 2a082903 002a3668 USER32!NtUserDispatchMessage+0xc

02cadd1c 77a18e9c 62944afe 00000000 02cafe54 USER32!DispatchMessageWorker+0x3d5

02cadd2c 6f561acc 02cadd74 0027b498 0027b4b4 USER32!DispatchMessageW+0xf

02cafe54 6f581996 0027b498 00276e98 763215a2 IEFRAME!CTabWindow::_TabWindowThreadProc+0x722

02caff10 763215b0 01592ba8 002720e0 02caff38 IEFRAME!LCIETab_ThreadProc+0x317

02caff20 6f56fcdb 00276e98 00000000 00000000 iertutil!CIsoScope::RegisterThread+0xab

02caff38 76631114 002720e0 02caff84 77d9b429 IEFRAME!Detour_DefWindowProcA+0x6c

4번 쓰레드는 MSHTML에서 온 렌더링 쓰레드로 보인다. nvd3dum.dll은 NVIDIA Windows Vista WDDM driver 로 이를 사용하는 것으로 봐서는 IE 9에서의 하드웨어 렌더링 기능으로 기인한 듯 보인다. 오히려 이건 성능 향상으로 위한 IE 9에서의 새로운 조치가 아닌가? 하지만, 해당 쓰레드에서 High CPU가 발생하는 것으로 봐서는 문제가 있다.

일단, 해당 NVIDIA Driver를 최신으로 업그레이드 해봤지만, 크게 도움이 되지 않았다. 그러므로, 해당 비디오 드라이버가 충분한 하드웨어 렌더링 기능을 지원하지 못하는 듯 하다. 이 경우에는 하드웨어 렌더링을 사용할 수 없으므로, 인터넷 익스플러러의 인터넷 옵션의 고급 탭에서 설정 중 가속 그래픽의 “GPU 렌더링대신 소프트웨어 렌더링 사용”을 선택하여 하드웨어 렌더링을 사용하지 않고 소프트웨어 렌더링으로 처리할 수 있다. 물론, 설정 후 브라우져 재 시작하여 문제를 재현해봤으나, 문제가 재현되지 않음을 확인할 수 있었다.