나는 아주 이상한 상황에 처해있다. C++에서 Visual Studio 2010에서 프로그래밍 한 IOCP 서버 프로그램을 실행하고 있습니다.Visual C++ 프로그램이 중단되었지만 덤프 파일이 생성되지 않았습니다. 왜?
'minidump'를 사용하므로 포인터 오용과 같은 논리적 버그가있을 때 프로그램이 덤프 파일과 충돌하여 코드의 충돌 지점이 어디인지 확인할 수 있습니다.
간혹 (아주 드물게) 프로그램이 충돌하고 덤프 파일이 없습니다.
SetUnhandledExceptionFilter()은 어떤 상황에서 작동하지 않습니까? 누구든지이 문제를 알고 있습니까? 나는 알아낼 수 없다.
물론 미니 dump가 없기 때문에 당신은 모른다. SetUnhandledExceptionFilter 콜백이 발생하면 절대 최소값을 지정해야합니다. 이 과정은 위험한 상태에 있습니다. 그것은 추락했다. 자물쇠가 잡힐 수도 있고, 힙 잠금 장치는 특히 까다 롭습니다. MiniDumpWriteDump()가 성공할 것으로 기대할 수 없습니다.
이름이 지정된 이벤트를 기다리는 약간의 보호 프로세스가 필요합니다. main() 함수에서 가능한 한 빨리 시작하고 프로세스 ID를 전달하십시오. 가드 프로세스는 해당 이벤트와 프로세스 핸들을 기다립니다. 예외 콜백에서 이벤트를 신호로 보내고 오랫동안 잠을 자면됩니다. 그것은 가드 프로세스를 깨우고, MiniDumpWriteDump()와 충돌에 대해 알려주는 데 필요한 다른 것을 추가로 호출합니다. 그리고 주 프로그램을 죽입니다.
어떻게'MiniDumpWriteDump'가 더 많은 기회를 가지는지 이해할 수 없습니다. 다른 프로세스에서 실행할 때 성공합니다. 자물쇠가 보유되면 해당 자물쇠가 보유됩니다. 어떤 프로세스가 잠긴 자원에 액세스하려고하는지는 중요하지 않습니다. 또한,'MiniDumpWriteDump'는 스레드로부터 안전하지 않으므로 어느 쪽이라도 운명을 같이합니다. 모든 스레드를 동기화 할 수 없다면 (프로그램이 불확정 상태에 있기 때문에 할 수는 없지만) 성공을 보장 할 수는 없습니다. 당신이 말하는 것은 그럴듯 하긴하지만, 왜 가드 프로세스가 성공할 가능성이 더 큰지에 대한 이론적 근거는 제공하지 않습니다. – IInspectable
스레드 안전성은 문제가되지 않으며 MiniDumpWriteDump()를 호출하는 스레드는 하나뿐입니다. 프로세스가 너무 손상되어 MDWD가 작업을 완료하는 데 필요한 CreateFile() 및 HeapAlloc()과 같은 기본 호출이 가장 확실하게 실패 할 수 있는지 여부가 우려됩니다. 그것은 일종의 필터입니다. 만약 당신이 in-process를한다면 디버깅이 불가능한 정말 나쁜 크래쉬를 결코 볼 수 없을 것입니다. 아마도 좋은 일일 것입니다. –
응답 해 주셔서 감사합니다. 아직도 확실하지 않다. 프로세스가 너무 썩어서'CreateFile'이 실패하면 (커널 메모리가 손상되지 않으면 실패 할 수 있는가?),'SetEvent'가 될 것이라고 주장 할 수도있다. 기본적으로 'HeapAlloc'은 OOM에 실패하지 않는 한 동일하게 적용됩니다. MDWD가 '사전 할당 된'정적 데이터에서 작동한다고 가정합니다. 이는 스레드로부터 안전하지 않은 이유를 설명합니다. 덜 기술적인 메모에서, 온 - 프로세스 (in-process) 솔루션이 가지고 있지 않은 상황에서 생성 된 미니 덤프를 가지고 있습니까? – IInspectable
http://msdn.microsoft.com/en-us/library/windows/desktop/ee416349%28v=vs.85%29.aspx – DumbCoder