처음 프로그램을 실행하면..

쓰레드를 생성하게 됍니다.

그 부분에서

First-chance exception이 나오는데요...

디버그 랩에서 보고 브레이크 포인터 까지 거는것 까지 했습니다.

하지마나 어디서 그 부분이 나오는지를 찾지 못하겠더군요..

쓰레드 생성 부분을 제거 하고 프로젝트를 실행하면 나오지는 않는데요..

왜 이런 현상이 나오는지 모르겠습니다.

여러 쓰레드를 생성하지만 특별히 몇개의 쓰레드에서만 나오는거 같은데요..

특별한 원인이 없는거 같은데..잘 모르겠더군요..

해결의 실마리가 있을런지 해서 이렇게 조언을 구합니다.

조언 부탁드리겠습니다.

안녕하세요. 좋은 질문이네요..

우선 First-Chance Exception에 대해서 Microsoft의 KB에서 다음과 같이 소개하고 있습니다.

http://support.microsoft.com/default.aspx?kbid=105675

It is a common practice to use SEH as a signaling mechanism. Some application programming interfaces (APIs) register an exception handler in anticipation of a failure condition that is expected to occur in a lower layer.

When an exception is raised, the handler may correct or ignore the condition rather than allow a failure to propagate up through intervening layers. This is very useful in complex environments such as networks where partial failures are expected and it is not desirable to fail an entire operation just because one of several optional parts failed. In this case, the exception can be handled so that the application does not recognize that an exception has occurred.

However, if the application is being debugged, the debugger sees all exceptions before the program does. This is the distinction between the first and second chance exception: the debugger gets the first chance to see the exception (hence the name). If the debugger allows the program execution to continue and does not handle the exception, the program will see the exception as usual. If the program does not handle the exception, the debugger gets a second chance to see the exception. In this latter case, the program normally would crash if the debugger were not present.

해석 : 하지만 만약 응용 프로그램이 디버깅되고 있는 중이라면, 디버거는 프로그램이 예외를 확인하기 전에 먼저 모든 예외를 감시한다. 이것이 바로 첫번째(first-chance)와 두번째(second-chance) 예외의 차이점이다. 디버거는 프로그램에서 발생하는 모든 예외를 살펴볼 수 있는 가장 첫번째 기회(first-chance라고 하는 이유)를 갖게된다. 만약 디버거가 프로그램 실행을 계속 허용하고 해당 예외를 처리하지 않는다면, 프로그램은 평상시와 마찬가지로 예외를 확인하게 될 것이다. 만약 프로그램이 그 예외를 처리하지 않는다면, 디버거는 프로그램이 처리하지 않은 예외를 최종적으로 다시 한번 확인할 수 있는 두번째 기회(second-chance)를 갖게된다. 후자의 경우에는 일반적으로 디버거가 존재하지 않을 경우에 프로그램이 곧바로 충돌할 것이다.

* 보충 설명 ---------------

일반적으로 first-chance exception이 발생했다는 메시지를 확인했음에도 불구하고 프로그램이 충돌하지 않는 이유는 내부 코드에서 이 예외를 처리하고 있기 때문이라고 보시면 됩니다. 따라서 API를 호출하는 대부분의 경우에는 first-chance exception이 발생했다고 하더라도 무시하면 됩니다(내부적으로 처리가 되고 있기 때문이죠). 물론, first-chance exception을 확인하고 난 후, second-chance exception이 발생하여 프로그램이 충돌하면 당연히 오류를 잡아주어야 겠죠.

If you do not want to see the first chance exception in the debugger, you should disable first chance exception handling for the specific exception code. Otherwise, when the first chance exception occurs, you may need to instruct the debugger to pass on the exception to the program to be handled as usual.

만약 Visual Studio 6.0을 사용하고 계시다면, 이 툴로 first-chance exception을 잡을 방법이 없습니다. 다음 링크에서 WinDBG를 다운로드 하시면 간단하게 잡을 수 있죠. VS.NET에서는 원하는 exception을 선택할 수 있기 때문에 더욱 간단하구요. 물론 BoundsChecker와 같은 프로그램을 사용하셔도 잡으실 수 있을 것입니다. 결국 이 메세지를 디버깅 시에 확인하더라도 API 단에서 발생하는 경우라면 크게 걱정하지 않아도 건강에는 지장이 없다라는 것입니다. ^^

http://www.microsoft.com/ddk/debugging/

 이런 경우에는 Debug -> exception -> 다이알로그 창에서 맨 밑의 항목 Microsoft C++ Exception을 stop always로 설정하셔도 많은 부분을 잡아낼 수 있습니다. 이렇게 해두면 예를 들어 DB exception이 발생하여 보통때는 "~ 테이블을 찾을 수 없습니다.." 정도로 메시지를 뿌려주고 지나가는 경우에도 먼저 브레이크가 걸린 다음에 메시지 박스가 나타나는 것에서부터 쓰레드 관련 오류 메모리 관련 오류( Access Violation을 stop always로 설정)등등 많은 부분이 미리 캐치됩니다. visual studio 6.0에서 사용하는 내용이고 Debug -> exception 메뉴는 프로그램 실행 중에만 활성화됩니다. F5 누르고 프로그램 시작하셔서 설정하시면 됩니다.

좋은 답변 감사합니다. ^^