얼마 전부터 몇몇 Client 에서 프로그램을 Resize 할 때 마다 멈추는 현상이 발생하였다.
프로젝트 오픈이 얼마 남지 않은지라 비상전시 체계로 돌입하여 원인을 찾기 시작했다.
특정 Client 에서 프로그램의 내부 / 외부를 가지 않고 모든 Resize 시
CPU 점유율이 50%까지 치솟고 몇 십 초에서 몇 분까지 멈추기 때문에 굉장히 심각한 문제였다.
하지만 WPF 로 만들었기 때문에 Resize 에 대해서 특별히 다른 처리를 해준 것은 없었고
그래서 이벤트나 쓰레드 는 물론이고 안에 들어가 있는 거의 모든 로직에 대해서 검토를 하였지만 별 다른 이상을
찾지를 못했다.
테스트를 하다 보니 MeasureOverride 와 ArrangeOverride 에서 거의 대부분의 시간을 소요하는 것을 알게 되었다.
상위에서 하위 Child UIElement 로 내려갈 때 마다 그 시간이 곱으로 올라가며
마지막에 가장 하위에 있는 빈 TextBox 의 사이즈를 계산하는데 몇 분이 소모되는 어이없는 결과를 얻을 수 있었다.
결국 결국 화면을 다시 그리기 위한 사이즈와 위치를 계산하는 Measure 와 Arrange 메소드에서
몇 분 동안 CPU 50% 를 점유하고 있었던 것이다.
결국 WPF 의 뭔가 문제가 있다는 생각을 하고 외부의 요인을 찾다 보니..
(애초에 몇몇 Client 에서 발생하는 문제라 코드의 문제라기 보다 환경 문제라는 것을 대충(?) 은 짐작은 했지만..ㅡㅡ)
.Net Framework 4.0 Client Profile 에 문제가 있어서 패치가 있다는 허무한 사실을 끝으로
패치 설치로 문제가 해결 되었다.
KB2484841 : Hang When attaching UIAutomation to WPF process
> http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=35604
> http://support.microsoft.com/kb/2484841/ko
해당 핫픽스에서 설명하고 있는
현상 (WPF 응용 프로그램 CPU 를 소모하고 상당 기간 응답하지 않을 수 있습니다.) 이 정확하게 일치하고
원인은 "WPF 의 AutomationPeer 구현에 최적화 되지 않은 논리 때문에 문제가 발생합니다" 라고 되어있는데
잘 모르겠다...ㅡㅡ;
문제는 어떻게 보면 굉장히 심각한 문제인데 이런 문제에 대한 패치가 Window Update로 자동으로 되지 않았다는 점이다.
아시는 분의 말을 빌리자면 "특정 하드웨어를 사용하여 발생하는 문제에 대한 패치는 그 하드웨어의 드라이버의 업데이트를 통해서 같이하는 MS 의 배포 정책이 있다" 라고 하니...
특정 하드웨어를 사용함으로써 발생된 문제라 가정하면
몇몇 Client 에서만 해당 문제가 발생하였는지, 해당 패치가 필수 Update 요소에 포함되지 않았는지 어느 정도 설명이 가능할 것 같다.
어쩌든 나처럼 삽질 하는 분이 없기를 바라면서....
'Dev::DotNet > WPF' 카테고리의 다른 글
xaml 에서 enum binding 하기 (0) | 2013.12.16 |
---|---|
WPF TextBox Caret 의 좌표 가져오기 (0) | 2013.12.09 |
NetAdvantage XamDockManager 의 Menu 비활성화 (0) | 2013.12.02 |
ComboBox 의 SelectedValue 와 SelectedItem 의 성능적 차이 (0) | 2013.11.29 |
XmlnsDefinition 을 통한 namespace 매칭 (0) | 2013.11.22 |