OSDev

сейчас пробую наладить работу с исключениями,

вот как обходить ошибки в коде и останавливать процессы, если там ошибка произошла,

вот некоторые ошибки ещё можно обойти перелистнув EIP но многие другие так просто не обойдёшь,
а процесс остановить не получается?

Что-то как-то слишком не конкретно - какие исключения, какой код, и как это он не останавливается при возникновении исключения.

Существует 3 возможности обработки исключения.
1) Писать код без исключений.
2) Обрабатывать исключения.
3) Не обрабатывать исключения.

Первый пункт решается проверкой входных параметров.
Третий пункт решается передачей управления на следующую команду.
Второй пункт решается передачей номера ошибки исключения по стеку обработчиков исключений.

Третий пункт не предсказуем. А первый слишком сложен. Поэтому обычно решается кобинацией первого и второго.

При исключении процесс сам собой останавливается. Поэтому вопрос не понятен.

при возникновении ошибки в коде, вызывается прерывание (0-1F), после обработки прерывания(ошибки) програмный код продолжает работать, если ошибка фатальная всё останавлиивается,

может подскажите как эту обработку ошибок наладить.

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

а если вызывается апаратное прерывание и во время обработки произошла ошибка,
планировщик я могу остановит а вот апаратуру не получится.

Кажется, вопрос про обработку процессорных исключений. Они все разные, и очень по-разному обрабатываются. В общем-то механизм обработки схож с прерываниями процессора. В момент исключения нужно сохранить текущие регистры, выполнить ядерную процедуру обработки и сделать возврат обратно в пользовательскую программу. При нормальной работе программы, ни каких исключений не происходит, если не считать исключения "Page fault" для функционирования виртуальной памяти.

Аппаратура приостанавливает свою активность на время обработки прерывания, до тех пор пока не поступит "EOI" - сигнал окончания обработки прерывания. Обработчик выдаёт этот сигнал в самом конце своей работы.

Не стоит бояться обработка исключения займёт несколько мк секунд. Когда как до следующего прерывания от железа есть несколько мс. Разница в 3 десятичных порядка - 1000 раз. Даже если не успеете, то ничего страшного не произойдет.

Никто, никакое железо не приостанавливается, хотя в критическом случае конечно остановиться, но как правило это не так. И вообще оно работает параллельно. Как правило есть резерв. В видео картах тройной буфер. Пока по прерыванию идёт переключение первого и второго вернее вывод, то растеризация и построение идёт в третий буфер. В UART буфер 16, а порог на 10 байтах. В сетевых картах тоже запас в 10% процентов. Жёсткий тупо подождет следующей команды. Таймеру пофиг он отчёт сбросит и дальше будет молотить пока сторожевой таймер не сработает(1-60 секунд). В контроллере клавиатуры 8042 есть буфер на прием и есть буфер на выдачу. Пока вы обрабатываете прерывания и возитесь с буфером на выдачу, клавиатура просто запишет данные во входной буфер.

Но вообще-то совет делать маленькие, короткие, быстрые обработчике прерываний(исключений, сообщений) ещё никто не отменял. Им же ведь надо всего ничего, а именно проверить статус да сменить буферы. А вот планирование нагрузки и порядок буферов это уже отложенная обработка.

Это не так, почитайте про контроллер прерывания. Останавливались только шины PCI и ISA, на время посылки вектора прерывания. Сейчас в этом нет надобности,так как нет таких шин.
Даже в контролёре прерываний есть буфер для детактивирования срабатывания прерывания и буфер для выдачи команды на обработку. Поэтому при желании можно отследить приход следующего прерывания во время обработки прерывания. Правда это не требуется так как контролёр прерываний сделает это за вас.