COM-dll 구성 요소를 호출 한 후 C# 예외가 디버거에서 catch되지 않습니다.

Question

타사 소프트웨어 회사에서 제공 한 COM DLL을 사용하고 있습니다 (소스 코드가 없음). 나는 그들의 객체가 'JvmVersion'과 같은 속성 이름을 포함하기 때문에 Java를 사용하여 구현했는지 확실히 알고 있습니다.

제공된 COM dll에 의해 도입 된 개체를 인스턴스화 한 후 내 C# 프로그램의 모든 예외를 VS 디버거에서 catch 할 수 없으며 예외가 발생할 때마다 기본 Windows 디버거 선택 대화 상자가 나타납니다. 전체 VisualStudio 디버깅 환경에서 디버그 모드에서). (1) VS에 의해 체포됩니다

throw new Exception("exception 1"); 
m_moo = new moo(); // Component taken from the COM-dll 
throw new Exception("exception 2"); 

예외하고 "노란색 예외 창을"보여

는 설명합니다.

예외 2는 "처리되지 않은 win32 예외가 myfile.vshost.exe [1348]에서 발생했습니다."라는 텍스트가 포함 된 "Visual Studio Just-In-Time Debugger"대화 상자를 엽니 다. 내 시스템에서 기존 VS 인스턴스 목록을 선택합니다.

"moo"개체의 인스턴스화가 C#의 예외 처리기 또는 그와 비슷한 것을 대체한다고 생각합니다. 내가 맞습니까? C#의 예외 처리기를 유지할 수있는 방법이 있습니까?

Answer 1

음, 좋지 않습니다. 그러나 아직 CLR의 예외 처리 논리가 완벽하게 검증되지 않았 음을 입증하지 못했습니다. 당신이 설명하는 것은 또한 디버거를 분리함으로써 설명 될 수 있습니다. Java JVM이 확실히 후보자가 될 것입니다. 이 COM 서버를 사용할 기회가 아직 남아 있다면 시도가 여전히 작동하는지 확인하십시오.

그러나 디버깅은 고통 스러울 것입니다. 운이 좋으면 분리는 단 한 번 발생합니다. 서버에 처음 호출 한 후 System.Diagnostics.Debugger.Break()를 작성하고 대화 상자에서 "디버그"를 클릭하십시오.

null 참조 예외가 여전히 작동하는지 테스트하십시오. Windows 'SetUnhandledExceptionFilter()를 호출하는 VM에서 리디렉션되기 쉬운 하드웨어 예외입니다. 그런 다음이 COM 서버를 그대로 사용하면 안됩니다. 프로세스를 너무 많이 불안정하게 만듭니다. 별도의 프로세스로 실행하고 WCF 또는 Remoting을 사용하여 문제를 해결하는 것은 절실히 필요합니다.

물론이 구성 요소 공급 업체는 COM 서버 계약을 잘못 위반합니다. 당신은 그걸 참지 않아야합니다. 에서 (첫 번째 줄)을 다음 줄을 추가

Answer 2

내 주요() (Program.cs 파일에) 만든 예외가 다시 작동 :

Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException); 

위의 라인 (내 생각) 자동 처리기를 우선 적용 어떤 이유로 COM 구성 요소를 사용한 후에 작동을 멈췄습니다.