첫 번째 예외는 : 내 C# 응용 프로그램을 개발하는 동안 RPC 서버가 어떤 점에서

Question

사용할 수 없습니다, 다음은 내가 OpenFileDialog를 만들 때마다 VS 출력 창에 표시하기 시작했다 : 나는 유지했습니다

First-chance exception at 0x75A6C42D (KernelBase.dll) in (myapp).exe: 0x000006BA: The RPC server is unavailable. 

이 응용 프로그램을 몇 년 동안, 그리고 확실히 전에 이것을 본 적이 없기 때문에, 나는 SVN에서 언제 시작되었는지 결정하기 위해 롤백하기 시작했습니다.

어색하게도 수정이 발생합니다. &은 일치하지 않는 것처럼 보입니다. 내가 충분히 멀리 되돌아 간다면 결코 일어날 수 없지만 개정판을 확인할 수있을 때 "영역"이 생기면 그것은 일어나지 않을 것입니다. 다른 개정판을 검사 할 것이고, 그러면 처음으로 돌아갈 것입니다. 갑자기 그럴 시간. 다른 말로하면, 나는 그것이 언제 시작되었는지 정확하게 신뢰할 수있는 것처럼 보일 수 없다.

설명의 편의를 위해 여기에 내 테스트의 발췌 부분이 있습니다. 숫자는 수정입니다. 각 테스트마다 "개정판으로 업데이트"하고 전체 재 작성을 수행합니다.

 3977: Exception. This is the most-recent revision. 
3839: OK. Since it didn't happen, I'll start working my way back up to see when it starts 
    3843: OK 
    3852: OK 
    3890: Exception. So it started between 3852 & 3890. 
    3852: Exception. Huh?? I JUST tried 3852, and last time it didn't happen! 
3778: OK. Going back this far, I've never seen it happen. 
    3852: Exception. I guess I'll start working my way BACK to see when it stops. 
    3828: Exception 
    3810: OK 
    3828: Exception. Just making sure. 
    3810: OK. Just making sure again. 
    3828: OK. What?? 3828 showed the exception last time I tried! 
    3852: OK. (but previously it showed the exception) 
    3890: Exception 

나는 이러한 유형의 예외를 깨뜨리지 말고 VS를 무시할 수 있다는 것을 알고 있습니다. 그러나 언급 한 바와 같이 수년간이 소프트웨어에 대한 작업을 한 번도 본 적이 없으므로 정확히 을 확인하고 싶습니다.과 이 왜으로 시작했는지는 눈을 멀게하는 것이 아닙니다.

Answer 1

이것은 프로젝트와 관련이 없습니다. OpenFileDialog와 같은 쉘 대화 상자를 사용하면 탐색기가 프로세스에로드됩니다. 수하물이 많을 때, 도로드 된 모든 셸 확장을 가져옵니다. 익스플로러를 사용자 정의하는 종류의 대화 상자에서 제대로 작동합니다.

오작동은 매우 일반적입니다. 프로그래머는 기발한 종류를 사용하는 경향이 있습니다. 이러한 셸 확장의 사고는 이제 사용자에게 표시되며 디버거에서 알려줍니다.

아무 것도 실제로 잘못되지 않았습니다. 예외가 발견되어 처리되었습니다. Explorer는 나쁜 셸 확장에 대한 대응책을 구현하여이를 불안정하게 만들고 자동으로이를 비활성화합니다. 그래서 당신은 단지 lame-duck shell extension을 사용할 수 없으며, 잠시 동안 작동하지 않을 것이므로 낮은 확률로 알 수 있습니다.

디버거가 잘못된 것을 알려줍니다. 관리되지 않는 디버깅을 활성화하고 Debug + Exception 대화 상자에서 Thrown 확인란을 선택하십시오. 예외가 발생하면 디버거가 중지됩니다. 소스 코드는 보이지 않지만 힌트를 보려면 호출 스택 디버거 창을 살펴보십시오. Windows DLL 함수 아래에 스택의 어딘가에 나쁜 코드가 들어있는 DLL의 이름을 표시합니다. 그 이름은 괴롭히는 사람이 어떤 힌트를 주어야합니다. SysInternals의 AutoRuns 유틸리티는이를 사용하지 않도록 설정하는 것이 좋습니다.