2013-05-03 3 views
4

첨부 된 디버거가있는 장치에서이 샘플 프로그램을 시작하면 심각한 오류가 발생합니다..NET CF 3.5 및 CE 6 R3 심각한 오류를 방지하는 방법

이것은 실제 응용 프로그램에서 일어나는 일들을 요약 한 것입니다. 내가 발견 무엇

은 다음과 같습니다

  • 디버거는
  • 메모리가 어떻게 든 채워 져야 첨부해야합니다
  • 쓰레기 (비트 맵) 오브젝트가 존재해야합니다 (I이 가비지 수집을 강제로 생각한다). 다른 목적 (Application.Run() 또는 ShowDialog를 사용하는 경우 차이) 양식이 표시되지해야
  • 동일한 오류 형태는 볼 때

그 다음 GC는 비트 맵 심각한 수집 초래할 수도 오류가 발생합니다.

.NET Compact Framework 3.5에서 WindowsCE 6 R3을 실행하고 있습니다. 이미 비슷한 질문을하지만 anwser를 발견했습니다

static class Program { 

    static void Main() { 
     // Fill up memory - Depends on device 
     var memory = new int[100000 * 150]; 

     // Settings the priority higher will raise the error earlier. 
     // With Priority set to Normal the EXE won't get freed correct. 
     // Without this line i have to reboot the CE after every test run... 
     Thread.CurrentThread.Priority = ThreadPriority.Highest; 

     // 80 is just random choosen. The error occurs also with 30 Bitmaps... 
     for (int o = 1; o < 80; o++) { 
      // Create a Bitmap and don't free it manually. The 
      // The garbage collector will take care of it :) 
      var bitmap = new Bitmap(100, 100); 

      // When i dispose the Bitmap, everything works fine... 
      //bitmap.Dispose(); 
     } 

     // Force a GC run 
     System.Diagnostics.Debug.WriteLine(GC.GetTotalMemory(true)); 

     // Then error occurs when the form is shown. 
     System.Windows.Forms.Application.Run(new System.Windows.Forms.Form()); 
    } 
} 

... 내가 지금까지 시도했습니다 무엇

:

  • 청소 리소스를 수동으로. 이미 모든 비트 맵 생성물을 검색하여 처리했거나 캐시했습니다. 오류가 여전히 발생합니다. 비트 맵은 나쁜 것만이 아닙니다.
+0

솔루션에 대한 의견이 맞지 않습니까? "비트 맵을 처리 할 때 모든 것이 정상적으로 작동합니다 ..." – Sayse

+0

문제는 비트 맵이 오류를 발생시키는 유일한 유형이 아니라는 것입니다. 실제 응용 프로그램에서 모든 비트 맵 참조를 수정했습니다. => 오류가 계속 발생합니다. 나는 내가 처리 할 필요가있는 비트 맵보다 더 많은 유형이 있다고 생각한다. 어떤 유형이 "불량"인지 어떻게 알 수 있습니까? 전체 프레임 워크에서 모든 IDisposables를 확인 하시겠습니까? – Benjamin

답변

0

이 점에 대한 답을 찾기는 어렵습니다.

a serious error occurs라고 말하면 내 생각에 OutOfMemoryException이 표시됩니다.

The Garbage Collector (GC) 프레임 워크가 GC에 시간을 할당하거나 호출합니다.

프레임 워크가 GC를 호출 할 수있는 속도보다 빠르게 메모리를 만들거나 사용하는 경우 메모리가 부족할 수 있습니다 (특히 CF 응용 프로그램에서).

.NET Framework에서의 가비지 컬렉터는 응용 프로그램의 메모리 할당 및 릴리스 관리 :

위의 MSDN 링크

는 다음과 말했다. new 연산자를 사용하여 객체를 만들 때마다 런타임은 관리되는 힙에서 객체에 대한 메모리를 할당합니다. 관리 힙에서 주소 공간을 사용할 수있는 한 런타임은 새 개체에 대한 공간을 계속 할당합니다. 그러나 기억은 무한하지 않습니다. 결국 가비지 수집기는 메모리를 확보하기 위해 콜렉션을 수행해야합니다. 가비지 수집기의 최적화 엔진은 할당을 기반으로 수집을 수행하는 최적의 시간을 결정합니다. 가비지 수집기가 컬렉션을 수행하면 응용 프로그램에서 더 이상 사용하지 않는 관리되는 힙의 개체가 있는지 확인하고 메모리를 회수하는 데 필요한 작업을 수행합니다.

이 문제를 해결하려면 리소스를 끝내야합니다. 나중에 데이터가 필요한 경우 나중에 검색 할 수 있도록 미디어 (플래시 데이터, 하드 드라이브 등)에 리소스를 저장할 수 있습니다.

자세한 내용은 Steven Pratschner의 블로그 An Overview of the .Net Compact Framework Garbage Collector을 참조하십시오.

1

나는 이론을 가지고 있으며, 그것은 시스템이 바뀌고 있다는 것입니다. 디버거가 자신의 크기가 CE's paging pool 크기를 초과하는 변수의 내용을 검색하려고하면 교착 상태에 빠질 수 있습니다. 디버거가 시스템을 중지하여 데이터를 읽었지만 시스템에서 데이터를 스왑 할 수 없기 때문에 컨텐트를 제공 할 수 없습니다. IOCTL_HAL_GET_POOL_PARAMETERS를 사용하면 시스템이 스와핑 중인지 여부를 감지 할 수 있어야합니다.

+0

재미있는데, 나는 이것을 조사하고 그 결과를 알려줄 것이다. – Benjamin

+1

당신의 이론을 확인하는 링크가 발견되었습니다 : http://support.microsoft.com/kb/946201/en-us. 그것을 테스트하기 위해 OS를 다시 빌드해야합니다. – Benjamin

+0

괜찮습니다. 작동하지 않았습니다. 페이징을 사용할 수 없으며 오류가 계속 발생합니다. – Benjamin