SW 개발

WM / Dll 관련 Memory Debug / Dll Load 주소 Debug 및 WM 6.0 개선사항

. . . 2012. 8. 15. 10:32
반응형
  • md 변환완료 (190927)

Windows Mobile 에서 Dll 이 로드되지 않던 사항에 대해서 디버깅했던 자료를 정리한다.

Device Driver DLL Debuging

Dll 형태의 드라이버 로딩되는 주소(Offset)

makeimg 할때 로그를 살펴보면.. 다음과 같은 로그가 나온다.

각 dll이 올라갈때의 offset부터 구하면.. makeimg 할때.. 아래와 같은 정보가 나온다.

  ...
  Module sio950.dll           at offset 01510000 data
  Module ohci2.dll            at offset 014f0000 data
  Module usb8023.dll          at offset 014e0000 data
  Module bbsysapi.dll         at offset 014d0000 data
  Module btd.dll              at offset 01460000 data
  Module wavedev2.dll         at offset 01450000 data
  Module pwrbutton.dll        at offset 01440000 data
  Module sdmemory.dll         at offset 01430000 data
  ...

위의 정보를 살펴보면.. device.exe가 dll을 올릴때 dll의 위치를 알수있다. 즉, 말그대로 offset xxxxxx 위치에 dll이 로드된다는 뜻이다.

devhealth.exe로 메모리구조를 살펴보면 아래와 같은 정보가 나온다.

Memory usage for Process 80324ee0: 'device.exe' pid 2 (partly pageable)
  Slot base 06000000  Section ptr 87712000
    06000000(1): ----------------  
    06010000(0): -CER              <-- End EXE: 0x06013030
    06020000(0): ----------SSSSSS  
    06030000(0): HHHHHHHHHHHHHHHH  <-- Heap:0x06030000
    06040000(0): HHHHHHHHHHHHHHHH  <-- Heap:0x06030000
    06050000(0): HHHHHHHHHHHHHHH   <-- Heap:0x06030000
    06060000(0): ---------------S  
    06070000(0): --------------SS  
    06080000(0): ---------------S  
    06090000(0): --------------SS  
    060a0000(0): ---------------S  
    060b0000(0): ---------------S  
    060c0000(0): ??                
    060d0000(0): ---------------S  
  ...
    073f0000(0): -ddDd             <-- DLL: nled.dll
    07400000(0): -dddddddddddddDd  <-- DLL: pxa320_keypad_us.dll
    07410000(0): -dddddddddddDd    <-- DLL: audiopath.dll
    07420000(0): ---------------S  
    07430000(0): -dddDd            <-- DLL: sdmemory.dll
    07440000(0): -ddDd             <-- DLL: pwrbutton.dll
    07450000(0): -ddddddddddddDd   <-- DLL: wavedev2.dll
    07460000(0): -ddddddddddddddd  
    07470000(0): dddddddddddddddd  
  ....위와 같은 내용이 나온다.

예로 sdmemory.dll 이 로드되는 위치를 살펴보자.

      07430000(0): -dddDd            <-- DLL: sdmemory.dll
  • 위의정보로 봤을때, 07430000에 로드된것을 알수있다.
  • 이값은 makeimg 할때나온정보 Module sdmemory.dll         at offset 01430000 data 에서의 offset 01430000 과 device.exe의 base 06000000 를 합친값이다.

결론적으로...

sdmemory.dll 이 로드되는 위치는 01430000(dll load offset) + 06000000(device.exe offset) = 07430000 이다.

Dll 제대로 로드 되지 않는 문제점..

dll이 제대로 로드되지 않는 문제점에 대해서..

WM5352 BSP 포팅도중에 sdmemory.dll 이 제대로 로드되지 않는 현상발생시에 devhealth.exe로 memory dump 를 해보면 다음과 같다.

    07400000(0): -dddddddddddddDd  <-- DLL: pxa320_keypad_us.dll
    07410000(0): -dddddddddddDd    <-- DLL: audiopath.dll
    07420000(0): d                 
    07430000(0): d                 
    07440000(0): -ddDd             <-- DLL: pwrbutton.dll
    07450000(0): -ddddddddddddDd   <-- DLL: wavedev2.dll

dll이 로드되지 않던 시점에 보면 해당 주소에 d 라고 어떤녀석이 잡혀있다.

  • ddup() 이라고 밑의 리포트에 나와있다.
    • 정식으로 된 문서는 없지만 다음의 url에 해당 내용에 대해서 나와있다
  • http://blogs.msdn.com/hopperx/archive/2006/09/19/devhealth-s-mysterious-dup-d-type-explained.aspx
  • d는 공용으로 쓰는 dll의 link 주소가있는것으로 판단된다.

정상적으로 로딩될때 메모리 ..

       07430000(0): -dddDd            <-- DLL: sdmemory.dll

로딩이 안될때 메모리 ..

       07430000(0): d

어떤 프로세스가 d 로 잡아놓고쓰고있다. 하지만 어느 녀석이 잡고있는지는 정확하게 알지는 못하는것같다.

결론적으로 dll이 로드되려고 했으나 해당 주소를 누가 쓰고있었으니… dll을 로딩하지 못하는것이다. - 정상적인경우라면.. 해당 dll이 로드될 위치가 reserved 영역/혹은 empty 영역이 되어있으면 정상적으로 로딩성공.

특이사항!!

희안하게도 빌드할때마다 올라오는 dll이 틀리게 된다. 예를들면, debug로 빌드할때는 올라왔던 dll이 ship으로 빌드하면 안올라오는 증상도있더라;;

즉, debug으로 빌드할때 오히려 dll의 size가 커져서 잘올라가던것이 ship으로 빌드하면 잘 올라갈것 같았는데… 꼭 그렇지도 않다는뜻이다;;

해결방법

해결방법은 어떤 Process가 dll을 올리는 주소를 침범해서 쓰기전에 미리 dll을 로딩시키는것. order값을 올려서 미리 로딩시켜놓던가, 중간에 올라가도 괜찮은 dll들은 LoadLibrary() 이용해서 쓰던가..

만약에.. dll이 올라갈 위치가 다른 큰 dll이 올라온다면, 위의 방법말고 service나 로딩위치를 바꾸는 방식으로 수정을 해야할것으로 보인다.

BSP를 WM5352로 포팅하는 도중에 기본적으로 특정드라이버가 로딩이 되지 않던 문제점 수정

해당문제 WorkAround Driver

아래의 자료조사는 AKU document 에서 검색한자료이다,

Pre Load Driver

위의 솔루션으로 미리 로딩시켜놓을수있다.

  • WM6.1의 메모리개선사항(문서제목 : Improved Virtual Memory)
    • 6.1 에서는 3가지의 vitual memory 성능개선이 있게 만들어져있다.
    • DLL code 의 핸들링을 위한 두개의 vitual memory slot 이 새로 생겼다.
    • Device 의 statck 부분이 새로운 슬롯으로 옮겨졌다.
    • vitual memory 가 더욱 효율적으로 만들어지게 만들어졌다.

새로운 Vitual memory Slot 에 관해서

system 은 vitual file memory 를 할당하기위해, 두개의 memory slot 을 추가하였다.

slot 60 (0x7800 0000-0x79FF FFFF)
slot 61 (0x7A00 0000 - 0x7BFF FFFF)

두개의 memory slot 은 OEM 과 software vender 들이 64MB의 virtual Memory를 사용할수있게 한다. 이 업데이트가 있기전에는 DLL 을 store 하기위해 slot0,slot1 의 virtual memory가 제한이있었다. 때문에 메모리가 중시되는 프로그램이 동시에 실행될때 시스템이 불안정해지는 결과가 나타났다.

Dll 을 slot 60,61 로 재배치를 하기위해서는 HKEY_LOCAL_MACHINE/System/Loader/LoadModuleLow 레지스트리에 등록을 해야한다.

기타사항

문서 Design Considerations for Memory Resources: RAM, ROM, and Virtual Memory 파트를 보면 다음과 같은 내용이 나와있다.

On Windows Mobile powered devices, specifically Windows Mobile 6 Classic and Windows Mobile 6 Professional devices, virtual memory may be a scarce resource.

위의 내용대로라면 WM6 에서는 vitual memory 가 모자르다고 나와있다. (한쪽문서에는 모자르다고 나오고 한쪽문서에는 개선했다고 나와서 비교해봄)

  • wm6.0 에만 해당되는 내용인것으로 판단
    • slot60 / slot 61의 개선사항은 WM6.1 에서만 적용되어있는것으로 보인다

이유는 다음과 같다.

  • aku616 에서는 HKEY_LOCAL_MACHINE/System/Loader/LoadModuleLow 가 실제로 존재하며 wzcsvc.dll / asyncmac.dll / irdastk.dll 등등 총 26개가 등록되어있다.
  • aku607 에서는 HKEY_LOCAL_MACHINE/System/Loader/LoadModuleLow 가 존재하지 않는다.

결론

WM5.0 / WM6.0 은 slot의 최대 size는 32MB고정 WM6.1 은 Slot size 최대 64MB 까지 사용가능

반응형