업데이트: 2007년 11월
잘못 작성된 프로파일러에서는 자체가 순환 참조되어 예기치 않은 동작이 발생할 수 있습니다.
CLR 프로파일링 API를 검토해 보면 COM interop 또는 간접 호출을 통해 서로를 호출하는 관리되는 구성 요소와 관리되지 않는 구성 요소가 포함된 프로파일을 작성할 수 있는 것처럼 보입니다.
설계 측면에서는 이것이 가능할 수도 있지만 프로파일링 API에서는 관리되는 구성 요소를 지원하지 않습니다. CLR 프로파일러는 완전히 관리되지 않아야 합니다. CLR 프로파일러에서 관리 코드와 비관리 코드를 함께 사용하면 액세스 위반, 프로그램 오류 및 교착 상태가 발생할 수 있습니다. 프로파일러의 관리되는 구성 요소가 관리되지 않는 구성 요소로 다시 이벤트를 발생시키고, 이어서 관리되지 않는 구성 요소가 관리되는 구성 요소를 다시 호출하여 순환 참조가 발생합니다.
CLR 프로파일러가 관리 코드를 안전하게 호출할 수 있는 유일한 위치는 메서드의 MSIL(Microsoft Intermediate Language) 본문뿐입니다. 함수의 JIT(Just-In-Time) 컴파일이 완료되기 전에 프로파일러에서 관리되는 호출을 메서드의 MSIL 본문에 삽입한 다음 JIT 컴파일할 수 있습니다. ICorProfilerInfo::GetILFunctionBody 메서드를 참조하십시오. 이 기술은 관리 코드의 선택적 계측에 사용할 수 있으며 JIT에 대한 통계 및 성능 데이터를 수집하는 데에도 사용할 수 있습니다.
또는 코드 프로파일러에서 비관리 코드로 호출되는 관리되는 각 함수의 MSIL 본문에 네이티브 후크를 삽입할 수 있습니다. 이 기술은 계측 및 검사에 사용될 수 있습니다. 예를 들어 코드 프로파일러에서 각 MSIL 블록 다음에 계측 후크를 삽입하여 해당 블록이 실행되었는지 확인할 수 있습니다. 메서드의 MSIL 본문을 수정하는 일은 매우 정교한 작업이며 고려해야 하는 요소가 많습니다.