Какое собственно Windows дело кратен или не кратен указатель стека 8 в программе, раз обработчик все равно уже найден и стек дальше исследовать не надо?

Думаю дело такое, что компилятор рассчитывает на определенное выравнивание стека при вызове функций. И рассчитывает он на это не просто так, а для того чтобы можно было использовать инструкции SSE при работе со стековыми переменными. Впрочем конечно можно было бы насильно подравнять стек, запомнив в нем же оригинальное "неровное" значение.

Диспетчер берет следующие 8 байт «вглубь» стека, надеясь, что это очередной адрес возврата, и пытается по ним все же определить, какая из известных, т.е. зарегистрированных подпрограмм выполнялась. Но это очень шаткая и сомнительная технология.

Технология конечно ужас-ужас в имплементации, зато имеет нулевой оверхед в рантайме. Самый интересный момент в статье не рассмотрен: а именно то что может быть в RtlAddFunctionTable(..RUNTIME_FUNCTION..) — UNWIND_INFO, которая является в том числе подсказчикам для того дизассемблера-симулятора. Прологи/эпилоги функций соотстветственно должны быть не абы-какими, а соответствовать возможностям симулятора, это как бы часть соглашения. Вобщем х64 стал еще немного дальше от любителей завернуть чтонить на асме.

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

Технология придумана для "санкционированных" исключений, то есть брошенных руками. Работоспособность программы после какого нить illegal instruction или поломанной памяти на самом деле никому не интересна.

Какое собственно Windows дело кратен или не кратен указатель стека 8 в программе, раз обработчик все равно уже найден и стек дальше исследовать не надо?

Думаю дело такое, что компилятор рассчитывает на определенное выравнивание стека при вызове функций. И рассчитывает он на это не просто так, а для того чтобы можно было использовать инструкции SSE при работе со стековыми переменными. Впрочем конечно можно было бы насильно подравнять стек, запомнив в нем же оригинальное "неровное" значение.

Диспетчер берет следующие 8 байт «вглубь» стека, надеясь, что это очередной адрес возврата, и пытается по ним все же определить, какая из известных, т.е. зарегистрированных подпрограмм выполнялась. Но это очень шаткая и сомнительная технология.

Технология конечно ужас-ужас в имплементации, зато имеет нулевой оверхед в рантайме. Самый интересный момент в статье не рассмотрен: а именно то что может быть в RtlAddFunctionTable(..RUNTIME_FUNCTION..) — UNWIND_INFO, которая является в том числе подсказчиком для того дизассемблера-симулятора. Прологи/эпилоги функций соотстветственно должны быть не абы-какими, а соответствовать возможностям симулятора, это как бы часть соглашения. Вобщем х64 стал еще немного дальше от любителей завернуть чтонить на асме.

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

Технология придумана для "санкционированных" исключений, то есть брошенных руками. Работоспособность программы после какого нить illegal instruction или поломанной памяти на самом деле никому не интересна.