Могу ли я удалить BSOD?

BSOD это просто визуальное сообщение об ошибке для того, что Windows называет bugcheck. Bugchecks (или, как их называет *nix, паника ядра) происходит потому, что OS Не могу "deal with it".

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

какие именно данные вы предоставить код, который должен в результате операции чтения, так что она может "идти"?

эти ошибки обычно возникают, потому что эта инструкция обращается не по адресу. На какой адрес вы бы изменили его при повторной попытке? Откуда ты знаешь, что это должно было быть?

конечно, эти ошибки могут возникать и при записи в память. Хорошо, ты можешь просто не писать и продолжать. Но код не просто записывает в память, потому что ему это нравится. Позже понадобится другой код информация, которая должна была быть записана в память, а потом it будет иметь те же проблемы с "просто продолжай."Подробнее об этом через мгновение.

возможный обходной путь - большая изоляция компонентов. Предположим, эта ошибка произошла в драйвере вашей звуковой карты-довольно несущественном устройстве для многих вещей, которые мы делаем на наших машинах. Вы можете сказать :"давайте просто сообщим об ошибке и перестанем использовать звуковую карту до следующей перезагрузки, возможно, пользователь обновит драйвер или замените звуковую карту."

беда в том, что весь код и данные в режиме ядра одинаково доверяют. Ошибка, возникшая в режиме ядра, означает, что весь код и данные в режиме ядра, по свидетельству только что видели,не надежным. И нет никакого способа узнать, что он не сделал более тонкого повреждения, прежде чем поднять ошибку, замеченную ОС. (Это приводит к мантре " жертва не всегда является виновником."Очень часто обнаруживается, что код, вызвавший ошибку это произошло потому, что другой компонент в режиме ядра повредил содержимое памяти. Часто бывает довольно сложно найти другой компонент.)

еще один аспект подхода проверки ошибок: эти ошибки "сообщаются" (путем сбоя), как только они замечены (обычно потому, что они вызывают необратимое исключение). В нескольких причинах проверки ошибок на самом деле можно было бы сделать что-то вроде разумного и продолжить. Однако это затеняет тот факт, что произошла ошибка или. Ошибки в режим ядра, вероятно, в конечном итоге приведет к " I действительно не может пойти на" условие.

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

сбой при первом признаке ошибки в режиме ядра, даже своего рода восстанавливаемый, получает дамп памяти так близко к проблеме, как вероятный. Многолетний опыт (с OSs, которые уходят за десятилетия до того, как NT впервые отправлен; как BSD, так и VMS относятся к концу 70-х/началу 80-х годов) показал, что даже если вам удастся разобраться в исправлении и продолжить, а система выйдет из строя позже, будет намного сложнее найти проблему.

проблема не в том, что вы "испортите хорошее оборудование". Это то, что просто нет никакого способа пожать плечами и продолжать идти, что, вероятно, будет иметь счастливый результат. Это похоже на достижение развилка на дороге, но ваш GPS говорит вам идти прямо вперед, путь, который не существует. Нет никакого способа следовать в этом направлении, и нет никакого намека на то, какую вилку взять. Вы можете выбрать путь наугад... это вряд ли приведет к тому, куда вы хотите пойти. (Или стабильной ОС.)

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

на самом деле, да! Проблема теперь в том, что вы не описываете архитектуру x86/x64 или способ ее использования OSs.

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

получается, что для устройств, для которых скорость не слишком важна, вы можете! Это то, что Windows' "пользователь Инфраструктура драйверов режима" - это про.

но вызов этих драйверов пользовательского режима включает в себя очень длинный путь кода со многими кольцевыми переходами и переключениями контекста процесс-процесс. (Ну, долго по сравнению с вызовом драйвера режима ядра.) Вы не хотите использовать UMDF для дисков или видеокарты. Вы могли бы переместить свои драйверы HID там, но драйверы HID в значительной степени решены проблемы.

все еще, некоторые приборы которые могут допустить задержки (особенно на сегодняшнем быстрые процессоры), и в будущем вы увидите все больше и больше драйверов, переходящих в пользовательский режим. Для устройства, которое действительно нуждается в скорости USB 3 драйвер umdf с, вероятно, будет слишком медленно, но устройство, которое может работать на USB 1.1 (как последовательный порт адаптер), наверное, не против использования драйвера umdf с функцией. С улучшениями в архитектуре UMDF, которые пришли с Win 8.1 вы увидите все больше и больше устройств, использующих UMDF.

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

что приводит к следующему: для основной ОС и драйверов режима ядра они должны оставаться в режиме ядра, чтобы иметь возможность делать некоторые вещи, которые они должны делать-используя привилегированные инструкции, отвечая на прерывания и handleable исключения, доступ к оборудованию ввода-вывода... все, что находится в "системном программировании" части x86/x64 набор инструкций ссылки. И для необработанных исключений в коде режима ядра я боюсь, что ответ на "просто продолжайте" все еще " и что именно?"

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