Торможу жуткко...
Подскажите как может приложение использующее С++ не импортировать функцию UnhandledExceptionFilter. Везде написано, что туда в итоге сваливается необработанное исключение. С++ использует SEH, но кто тогда обрабаьывает необработанные исключения. Просматриваю зависимости exeшника (не мой). Да и не все сиситемные модули экспортируют данную функция. Как такое может быть?

Здравствуйте, AcidTheProgrammer, Вы писали:

ATP>Подскажите как может приложение использующее С++ не импортировать функцию UnhandledExceptionFilter. Везде написано, что туда в итоге сваливается необработанное исключение. С++ использует SEH, но кто тогда обрабаьывает необработанные исключения. Просматриваю зависимости exeшника (не мой). Да и не все сиситемные модули экспортируют данную функция. Как такое может быть?

Код для вызова UnhandledExceptionFilter находится вне приложения, а именно в kernel32. Каждый Win32 поток выглядит примерно таким образом:

// реальная точка входа потока
VOID BaseThreadStart(...)
{
   DWORD dwRet = (DWORD)-1;

   __try
   {
       // вызов точки входа, указанной в CreateThread
       dwRet = ((*pUserThread)(pParam));
   }
   __except (UnhandledExceptionFilter(GetExceptionInformation())
   {
   }
   
   ExitThread(dwRet);
}

Здравствуйте, AcidTheProgrammer, Вы писали:

ATP>Торможу жуткко...
ATP>Подскажите как может приложение использующее С++ не импортировать функцию UnhandledExceptionFilter. Везде написано, что туда в итоге сваливается необработанное исключение. С++ использует SEH, но кто тогда обрабаьывает необработанные исключения. Просматриваю зависимости exeшника (не мой). Да и не все сиситемные модули экспортируют данную функция. Как такое может быть?

MSDN:

The UnhandledExceptionFilter function is an application-defined function that passes unhandled exceptions to the debugger, if the process is being debugged. Otherwise, it optionally displays an Application Error message box and causes the exception handler to be executed.

Устанавливается она с помощью SetUnhandledExceptionFilter.

Здравствуйте, Alex Fedotov, Вы писали:

Я и пишу — прочитайте внимателтней.

ATP>>Подскажите как может приложение использующее С++ не импортировать функцию UnhandledExceptionFilter. Везде написано, что туда в итоге сваливается необработанное исключение. С++ использует SEH, но кто тогда обрабаьывает необработанные исключения. Просматриваю зависимости exeшника (не мой). Да и не все сиситемные модули экспортируют данную функция. Как такое может быть?

AF>Код для вызова UnhandledExceptionFilter находится вне приложения, а именно в kernel32. Каждый Win32 поток выглядит примерно таким образом:

Это-то меня как раз и поражает. Код в CRT устроен именно таким образом, а функция в исследуемом exeшнике точно написанном на c++ не импортируется, да и во многих системных модулях

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, AcidTheProgrammer, Вы писали:

ATP>>Торможу жуткко...
ATP>>Подскажите как может приложение использующее С++ не импортировать функцию UnhandledExceptionFilter. Везде написано, что туда в итоге сваливается необработанное исключение. С++ использует SEH, но кто тогда обрабаьывает необработанные исключения. Просматриваю зависимости exeшника (не мой). Да и не все сиситемные модули экспортируют данную функция. Как такое может быть?

GN>MSDN:

GN>The UnhandledExceptionFilter function is an application-defined function that passes unhandled exceptions to the debugger, if the process is being debugged. Otherwise, it optionally displays an Application Error message box and causes the exception handler to be executed.

GN>Устанавливается она с помощью SetUnhandledExceptionFilter.

Странный у вас MSDN:
Вот что у меня написано:

UnhandledExceptionFilter

The UnhandledExceptionFilter function passes unhandled exceptions to the debugger, if the process is being debugged. Otherwise, it optionally displays an Application Error message box and causes the exception handler to be executed. This function can be called only from within the filter expression of an exception handler.


LONG UnhandledExceptionFilter(
STRUCT _EXCEPTION_POINTERS* ExceptionInfo
);

Parameters
ExceptionInfo
[in] Pointer to an EXCEPTION_POINTERS structure that specifies a description of the exception and the processor context at the time of the exception. This pointer is the return value of a call to the GetExceptionInformation function.

Я эту функцию могу вызвать, и она не application-defined. Это дефолтный обработчик исключений. Она есть в Kernal32 — можете убедиться.

Здравствуйте, AcidTheProgrammer, Вы писали:

ATP>Здравствуйте, gear nuke, Вы писали:

GN>>Здравствуйте, AcidTheProgrammer, Вы писали:

GN>>MSDN:

GN>>The UnhandledExceptionFilter function is an application-defined function that passes unhandled exceptions to the debugger, if the process is being debugged. Otherwise, it optionally displays an Application Error message box and causes the exception handler to be executed.

GN>>Устанавливается она с помощью SetUnhandledExceptionFilter.

ATP>Странный у вас MSDN:
Если посмотреть линк, то видно, что MSDN всё-таки у MS

ATP>Я эту функцию могу вызвать, и она не application-defined. Это дефолтный обработчик исключений. Она есть в Kernal32 — можете убедиться.
Вызывать её не нужно — это в некотором смысле callback функция, вызывается из

Вопрос был:

как может приложение использующее С++ не импортировать функцию UnhandledExceptionFilter

Вот пример такого приложения:

#pragma comment(linker, "/entry:start")

long __stdcall filter(EXCEPTION_POINTERS * p)
{
   // stuff
     return EXCEPTION_EXECUTE_HANDLER;//EXCEPTION_CONTINUE_SEARCH//
}

void start()
{
    SetErrorMode(SEM_FAILCRITICALERRORS);
    SetUnhandledExceptionFilter(filter);
    ExitProcess( Main() );
}

PS
а ещё существует delay import, GetProcAddress...

Здравствуйте, AcidTheProgrammer, Вы писали:

AF>>Код для вызова UnhandledExceptionFilter находится вне приложения, а именно в kernel32. Каждый Win32 поток выглядит примерно таким образом:

ATP>Это-то меня как раз и поражает. Код в CRT устроен именно таким образом, а функция в исследуемом exeшнике точно написанном на c++ не импортируется, да и во многих системных модулях

Тот псевдокод, который я привел, находится не в приложении, а в kernel32.dll. Реальной точкой входа всех Win32-потоков является внутренняя функция под названием BaseThreadStart, которая и вызывает UnhandledExceptionFilter для всех необработанных исключений.

В Visual C++ код CRT устроен похожим образом (см. crtexe.c), но он вызывает другую функцию:

int WinMainCRTStartup(
{
    ...
    __try
    {
        ...
    }
    __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) )
    {
        ...
    }
}

_XcptFilter действительно вызывает UnhandledExceptionFilter, однако, если CRT линкуется как DLL, то этот вызов будет находиться внутри msvcrt.dll, а не в самой программе. Если CRT слинкована статически, то деваться некуда, должен быть вызов UnhandledExceptionFilter (если только авторы программы не избавились от CRT совсем, что было популярно одно время).

Здравствуйте, Alex Fedotov, Вы писали:

AF>Здравствуйте, AcidTheProgrammer, Вы писали:

AF>>>Код для вызова UnhandledExceptionFilter находится вне приложения, а именно в kernel32. Каждый Win32 поток выглядит примерно таким образом:

ATP>>Это-то меня как раз и поражает. Код в CRT устроен именно таким образом, а функция в исследуемом exeшнике точно написанном на c++ не импортируется, да и во многих системных модулях

AF>Тот псевдокод, который я привел, находится не в приложении, а в kernel32.dll. Реальной точкой входа всех Win32-потоков является внутренняя функция под названием BaseThreadStart, которая и вызывает UnhandledExceptionFilter для всех необработанных исключений.

AF>В Visual C++ код CRT устроен похожим образом (см. crtexe.c), но он вызывает другую функцию:

AF>

AF>int WinMainCRTStartup(
AF>{
AF>    ...
AF>    __try
AF>    {
AF>        ...
AF>    }
AF>    __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) )
AF>    {
AF>        ...
AF>    }
AF>}
AF>

Этот код я видел, собственно поэтому и возник вопрос.

AF>_XcptFilter действительно вызывает UnhandledExceptionFilter, однако, если CRT линкуется как DLL, то этот вызов будет находиться внутри msvcrt.dll, а не в самой программе. Если CRT слинкована статически, то деваться некуда, должен быть вызов UnhandledExceptionFilter (если только авторы программы не избавились от CRT совсем, что было популярно одно время).

— гениально. Об этом-то я и не подумал. Пока не смотрел, но думаю что так и есть, вызов скорее всего находится в msvcrt.dll и эта программа слинкована с CRT как с DLL. Программа гарантированно использует MFC42, вы не знаете как тогда в этои случае обрабатываются исключения? На мой взгляд также, но исходники на предмет изучения необработанных исключений я пока не спотрел.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, AcidTheProgrammer, Вы писали:

ATP>>Здравствуйте, gear nuke, Вы писали:

GN>>>Здравствуйте, AcidTheProgrammer, Вы писали:

GN>>>MSDN:

GN>>>The UnhandledExceptionFilter function is an application-defined function that passes unhandled exceptions to the debugger, if the process is being debugged. Otherwise, it optionally displays an Application Error message box and causes the exception handler to be executed.

GN>>>Устанавливается она с помощью SetUnhandledExceptionFilter.

ATP>>Странный у вас MSDN:
GN>Если посмотреть линк, то видно, что MSDN всё-таки у MS

ATP>>Я эту функцию могу вызвать, и она не application-defined. Это дефолтный обработчик исключений. Она есть в Kernal32 — можете убедиться.
GN>Вызывать её не нужно — это в некотором смысле callback функция, вызывается из

GN>Вопрос был:

как может приложение использующее С++ не импортировать функцию UnhandledExceptionFilter

Вот пример такого приложения:
GN>

GN>#pragma comment(linker, "/entry:start")

GN>long __stdcall filter(EXCEPTION_POINTERS * p)
GN>{
GN>   // stuff
GN>     return EXCEPTION_EXECUTE_HANDLER;//EXCEPTION_CONTINUE_SEARCH//
GN>}

GN>void start()
GN>{
GN>    SetErrorMode(SEM_FAILCRITICALERRORS);
GN>    SetUnhandledExceptionFilter(filter);
GN>    ExitProcess( Main() );
GN>}
GN>

GN>PS
GN>а ещё существует delay import, GetProcAddress...

Ну это выражденный случай, своего рода хак. Программа скорее всего так не делает и использует MFC42. В общем точки входа там все стандартные и CRT используется в обычном режиме.

Задача моя, подменить стандартный обработчик, на свой, что бы приложение в случае падения вызывало мой код. Пока внедряюсь в чужой процесс, пытаюсь подменить таблицу импорта функций из kernel32, но с удивлением ображиваю что этот exe-шник сабж не импортирует. От сюда и возник этот вопрос.

Здравствуйте, AcidTheProgrammer, Вы писали:

AF>>_XcptFilter действительно вызывает UnhandledExceptionFilter, однако, если CRT линкуется как DLL, то этот вызов будет находиться внутри msvcrt.dll, а не в самой программе. Если CRT слинкована статически, то деваться некуда, должен быть вызов UnhandledExceptionFilter (если только авторы программы не избавились от CRT совсем, что было популярно одно время).

ATP> — гениально. Об этом-то я и не подумал. Пока не смотрел, но думаю что так и есть, вызов скорее всего находится в msvcrt.dll и эта программа слинкована с CRT как с DLL. Программа гарантированно использует MFC42, вы не знаете как тогда в этои случае обрабатываются исключения? На мой взгляд также, но исходники на предмет изучения необработанных исключений я пока не спотрел.

Если программа линкуется с mfc42.dll, то однозначно она должна линковаться с msvcrt.dll, по-другому не бывает. Вы правы, MFC целиком полагается на CRT для отлова необработанных исключений.

Здравствуйте, AcidTheProgrammer, Вы писали:

ATP>Задача моя, подменить стандартный обработчик, на свой, что бы приложение в случае падения вызывало мой код. Пока внедряюсь в чужой процесс, пытаюсь подменить таблицу импорта функций из kernel32, но с удивлением ображиваю что этот exe-шник сабж не импортирует. От сюда и возник этот вопрос.
Ok, ситуация проясняется . UnhandledExceptionFilter импортируется как минимум модулями mfc42.dll и msvcrt.dll. Раз уж дело дошло до мордобоя, то почему бы просто не пропадчить нужное место в kernel32.dll?

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, AcidTheProgrammer, Вы писали:

ATP>>Задача моя, подменить стандартный обработчик, на свой, что бы приложение в случае падения вызывало мой код. Пока внедряюсь в чужой процесс, пытаюсь подменить таблицу импорта функций из kernel32, но с удивлением ображиваю что этот exe-шник сабж не импортирует. От сюда и возник этот вопрос.
GN>Ok, ситуация проясняется . UnhandledExceptionFilter импортируется как минимум модулями mfc42.dll и msvcrt.dll. Раз уж дело дошло до мордобоя, то почему бы просто не пропадчить нужное место в kernel32.dll?

А 98-ой?

Здравствуйте, Alex Fedotov, Вы писали:

AF>Здравствуйте, AcidTheProgrammer, Вы писали:

AF>>>_XcptFilter действительно вызывает UnhandledExceptionFilter, однако, если CRT линкуется как DLL, то этот вызов будет находиться внутри msvcrt.dll, а не в самой программе. Если CRT слинкована статически, то деваться некуда, должен быть вызов UnhandledExceptionFilter (если только авторы программы не избавились от CRT совсем, что было популярно одно время).

ATP>> — гениально. Об этом-то я и не подумал. Пока не смотрел, но думаю что так и есть, вызов скорее всего находится в msvcrt.dll и эта программа слинкована с CRT как с DLL. Программа гарантированно использует MFC42, вы не знаете как тогда в этои случае обрабатываются исключения? На мой взгляд также, но исходники на предмет изучения необработанных исключений я пока не спотрел.

AF>Если программа линкуется с mfc42.dll, то однозначно она должна линковаться с msvcrt.dll, по-другому не бывает. Вы правы, MFC целиком полагается на CRT для отлова необработанных исключений.

Моя внедренная DLL показывает что она подменила адрес на UnhandledExceptionFilter в таблице импорта, но программа падая по прежнему вызывает стандартныйобработчик. С чем это может быть связано?

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

1. Можно подменить таблицу экспорта — не будет работать на 98м и не знаю поможет ли.
2. Изменить само тело функции — не будет работать на 98м
3. Есть ли еще какие-нибудь методы, если учеть что процесс для внедрения запуская я сам?

А какие проблемы?

Здравствуйте, gear nuke, Вы писали:

GN>А какие проблемы?

Насколько я знаю в 98-х системные DLL разделяются между всеми процессами, и если что-то в нихпоменять, то эти изменения будут во всех процессах в отличии от 2000-х.

Здравствуйте, AcidTheProgrammer, Вы писали:

ATP>Моя внедренная DLL показывает что она подменила адрес на UnhandledExceptionFilter в таблице импорта, но программа падая по прежнему вызывает стандартныйобработчик. С чем это может быть связано?

ATP>Я думаю, что программа уже запомнила где-то указатель на правильный обработчик, до вызова моего хука. Такое может быть и как это исправить?

Я бы поставил breakpoint на UnhandledExceptionFilter и посмотрел откуда и как она вызывается.

Здравствуйте, AcidTheProgrammer, Вы писали:

ATP>Здравствуйте, gear nuke, Вы писали:

GN>>А какие проблемы?

ATP>Насколько я знаю в 98-х системные DLL разделяются между всеми процессами, и если что-то в нихпоменять, то эти изменения будут во всех процессах в отличии от 2000-х.
Значит нужно проверять из какого процесса произошёл вызов и передавать управление оригинальному обработчику, если процесс чужой.

Здравствуйте, AcidTheProgrammer, Вы писали:

AF>>Если программа линкуется с mfc42.dll, то однозначно она должна линковаться с msvcrt.dll, по-другому не бывает. Вы правы, MFC целиком полагается на CRT для отлова необработанных исключений.

ATP>Моя внедренная DLL показывает что она подменила адрес на UnhandledExceptionFilter в таблице импорта, но программа падая по прежнему вызывает стандартныйобработчик. С чем это может быть связано?

ATP>Я думаю, что программа уже запомнила где-то указатель на правильный обработчик, до вызова моего хука. Такое может быть и как это исправить?

вызов внутри dll происходит напрямую, без таблицы импорта. Поскольку UnhandledExceptionFilter и базовая функция старта потока лежать в kernel32.dll, такой хук тут бесполезен.

ATP>1. Можно подменить таблицу экспорта — не будет работать на 98м и не знаю поможет ли.
ATP>2. Изменить само тело функции — не будет работать на 98м
ATP>3. Есть ли еще какие-нибудь методы, если учеть что процесс для внедрения запуская я сам?

Здравствуйте, SergH, Вы писали:

SH>Здравствуйте, AcidTheProgrammer, Вы писали:

SH>вызов внутри dll происходит напрямую, без таблицы импорта. Поскольку UnhandledExceptionFilter и базовая функция старта потока лежать в kernel32.dll, такой хук тут бесполезен.

UnhandledExceptionFilter и базовая функция старта потока то лежат, но UnhandledExceptionFilter завется из CRT.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, AcidTheProgrammer, Вы писали:

ATP>>Здравствуйте, gear nuke, Вы писали:

GN>>>А какие проблемы?

ATP>>Насколько я знаю в 98-х системные DLL разделяются между всеми процессами, и если что-то в нихпоменять, то эти изменения будут во всех процессах в отличии от 2000-х.
GN>Значит нужно проверять из какого процесса произошёл вызов и передавать управление оригинальному обработчику, если процесс чужой.

Если хорошо подумать, то вы поймете что этого сделать практически невозможно.
Начало функции испорчено, значит чтобы вызвать старую нужно обратно скопировать старый заголовок и держать какой-нибудь мьютех пока поток от туда не выйдет и не заменить начало обратно. Короче дальше даже думать не хочется — слишком сложно и тормозно.