При получении "синего экрана смерти" BSOD
 

Привет, друзья!
Если у вас в процессе работы возникает "синий экран смерти"
Вложение 414949
или компьютер сам по себе перезагружается, то значит, это инструкция дальнейших действий для вас.
В первую очередь вам нужно убедиться, что у вас включена опция записи дампа памяти. Для этого нужно:
Win+R --> control sysdm.cpl --> ОК --> Дополнительно --> Загрузка и Восстановление --> Параметры
Вложение 414950
Убедитесь, что у вас все галочки выставлены как на скриншоте.
(Если вы пришли на форум с этой проблемой, то выложите файл дампа в вашей теме — он может заметно ускорить решение вашей проблемы, либо попробуйте разобраться самостоятельно. Если решили самостоятельно, то дальнейшая инструкция — для ВАС).
Для анализа дампа будем использовать Windows Debugging Tools (скачать его можно отсюда), а также сценарий (kdfe.cmd), который написал Александр Суховей и опубликовал на ресурсе sysadmins.ru (поскольку живую ссылку мне там найти не удалось, выложил здесь).
Примечание.
В случае нестандартного расположения в папке Program Files папки Debugging Tools for Windows (а начиная с версии Windows 8 так и будет), вам может потребоваться указать в kdfe.cmd путь к папке, в которую установлены средства Debugging Tools for Windows. Используйте переменную dbgpath в строке 41 (для этого вам нужно открыть любым тестовым редактором этот файл).

Теперь всё сводится к выполнению одной команды. Откройте командную строку и перейдите в папку, в которую вы распаковали kdfe.cmd. Запустите файл, указав в качестве параметра путь к файлу дампа памяти ( в конкретном примере файл дампа находится в стандартной папке Minidump и называется 1.dmp)
Вложение 414951
Драйвер, послуживший причиной ошибки, а также процесс, вызвавший её, определен! Соответственно, для решения проблемы его обновляем/переустанавливаем, либо, если он не нужен, то удаляем.

Для более детального анализа можите воспользоваться этой и затем этой статьями.

P.S.
Для анализа дампа не рекомендую использовать BlueScreenView, т.к. она не всегда корректно отрабатывает и может ввести пользователя в заблуждение насчет источника ошибки (на моей памяти было раза 3).

P.P.S.
Если причиной ошибки указывается ядро системы (файлы win32k.sys или ntoskrnl.exe), то, если у вас не сборка, а оригинальная Windows, в 99.9% случаев это "железная" проблема. И, соответственно, нужно тестировать железо.