AddVectoredExceptionHandler и OutputDebugString

[el-]

r0 как то имел проблемы с этой парой и у меня сегодня возникли такие же проблемы смысл в том что вот такой вот код не работает

LONG CALLBACK
exc_handler( PEXCEPTION_POINTERS pep ) {
	OutputDebugStringA("handler");
}

	OutputDebugStringA("111");
	AddVectoredExceptionHandler( TRUE, exc_handler );
	OutputDebugStringA("222");

'222' или 'handler' не будет выведено никогда, а процесс повиснет и все закончиться плохо, причем в отладчиках все отлично работает, собственно почему ?

ответ:

оказывается, заглядывая в кишки OutputDebugStringA ( W функция ссылается на нее же ), видим следующие

; ... skipped
75282AC7   . 50             PUSH EAX                                ; /pArguments
75282AC8   . 6A 02          PUSH 2                                  ; |nArguments = 2
75282ACA   . 6A 00          PUSH 0                                  ; |ExceptionFlags = EXCEPTION_CONTINUABLE
75282ACC   . 68 06000140    PUSH 40010006                           ; |ExceptionCode = 40010006
75282AD1   . E8 8E8EFFFF    CALL KERNELBA.RaiseException            ; \RaiseException
; ... skipped

т.е. опять же дергается исключение ( в параметры помещается строка которую надо вывести ) и получается что устанавливая вех с неправильных обработчиком, и дергая после него OutputDebugString, порождаем исключение, которое не умеет правильно обрабатывается в handler или хуже того дергает внутри него еще один OutputDebugString, что приводит к зацикливанию.

а надо то добавить в самое начало обработчика вот это

	if (pep->ExceptionRecord->ExceptionCode == DBG_PRINTEXCEPTION_C)
  return EXCEPTION_CONTINUE_SEARCH;

да и вообще надо иметь ввиду что в вех будет сыпаться все и это все надо уметь правильно обработать.

 

[Barack]

согласен у меня тоже в свое время бывали траблы с OutputDebugStringA , кажись ставил вывод лога в обработчике исключений, апишка ахтунговая конечно, и использовать нужно осторожно,а лучше сделать свою какую-то версию вывода лога.