Вот ссылка на мою папку Dropbox, где я добавляю дампы памяти по мере их создания. Это так же, как ссылка, представленная ниже. Кроме того, самые новые правки находятся в верхней части этого поста. https://www.dropbox.com/sh/vw7zkiwbq7hh05p/AABxLOaKIc8V5djSgyy3sUWja?dl=0

РЕДАКТИРОВАТЬ: еще один BSOD, а смотреть Netflix в Chrome. Добавлено в ссылку Dropbox.

РЕДАКТИРОВАТЬ: Наконец-то получил еще один BSOD, и этот на самом деле произвел полный дамп памяти (1,07 ГБ). Он должен быть доступен по той же ссылке ниже после завершения загрузки. Я сжал его до 181MB с 7zip, так что это поможет некоторым. Этот последний сбой произошел во время просмотра Vimeo в новом браузере Edge, но это также произошло во время просмотра YouTube в Chrome. Если кто-нибудь может дать какое-либо понимание, я был бы благодарен. Напомним, что это с новым блоком питания и всеми 16 ГБ оперативной памяти. Единственное электронное оборудование, которое я не полностью заменил, это процессор, жесткие диски и, возможно, графические процессоры (это продолжалось достаточно долго, чтобы эта конкретная проблема могла быть новее, чем у моих графических процессоров). Большое спасибо!

РЕДАКТИРОВАТЬ: Таким образом, я RMA сделал мой блок питания, получил новый, установил его два дня назад, и все было хорошо до сих пор. Получил IRQL_not_less_or_equal BSOD. Худшая новость в том, что, похоже, Windows тоже не сохранила дамп памяти :-( Единственный дамп, который у меня есть, - это недавно. Это может быть из-за малого дискового пространства на этом диске, поэтому я постараюсь прояснить некоторые. ЕДИНСТВЕННЫЕ оставшиеся компоненты, которые не были полностью заменены, - это жесткие диски и процессор.

РЕДАКТИРОВАТЬ: Вот ссылка на мой дамп памяти. Полный дамп 800 МБ, поэтому он все еще загружается. Я добавлю больше здесь, поскольку они генерируются. Это будет в обозримом будущем. https://www.dropbox.com/sh/vw7zkiwbq7hh05p/AABxLOaKIc8V5djSgyy3sUWja?dl=0

Похоже на эту проблему: частые BSoD относительно повреждения памяти ... но при запуске SFC никогда не обнаруживались плохие файлы.

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

У меня были периодические сбои BSOD в течение последних 2 лет, или около того. Ошибки включали:

  • IRQL_NOT_LESS_OR_EQUAL
  • УПРАВЛЕНИЕ ПАМЯТЬЮ
  • PAGE_FAULT_IN_NONPAGED_AREA
  • BAD_POOL_HEADER
  • и другие.

  • ОС Это началось с Windows 7 и продолжилось с Windows 10. Один такой сбой даже потребовал чистой установки Windows 7, чтобы я мог выполнить обновление до Windows 10, поэтому я полностью переустановил ОС как минимум 4 раза с момента возникновения этих проблем.

  • GPU Проблема началась с одной пары графических процессоров NVIDIA без SLI и осталась с другой парой графических процессоров NVIDIA без SLI.

  • Mobo Эта проблема началась с одной материнской платы ASUS и продолжилась с материнской платой ASUS более новой модели.

  • ОЗУ Эта проблема началась с одного набора ОЗУ и сохранилась с совершенно новым набором ОЗУ. В то же время я обновил материнскую плату, я также обновил мою оперативную память с 16 ГБ DDR3 1066 до 16 ГБ DDR3 1333, оба G.Skill. (Обновление GPU было за год до обновления mobo)

  • Дисков у меня четыре HDD, два из которых SSD. Один SSD - мой загрузочный диск, остальные три - хранилище. Я запустил файл подкачки на всех четырех дисках, файла подкачки вообще нет, только на твердотельных накопителях, только на обычных дисках и во всем, что есть между ними, причем BSOD встречаются в каждой конфигурации. Диск ОС был отформатирован несколько раз в процессе установки, но остальные диски практически не изменились. Я думаю, что эта проблема началась, когда у меня все еще была ОС на обычном диске, но я точно не помню.

  • Мощность У меня есть блок питания на 750 ватт, которому 3-4 года, и никогда не было проблем ... но это может быть так. У меня также есть источник бесперебойного питания, но не сообщается о переходе на питание от батареи, так как я установил его пару месяцев назад.

Я запускал MemTest полдюжины раз, вообще без сбоев, а только на первом наборе оперативной памяти. Совсем недавно я запустил диагностику памяти Windows на всех четырех модулях и обнаружил некоторые неисправности. Затем я запустил его только на двух, без сбоев, затем на двух других, без сбоев. Каждый тест состоял из 3 проходов "Расширенного" набора тестов.

Я запустил verifyier.exe, но он довольно непрозрачный, поэтому я не знаю, дал ли он мне какую-либо полезную информацию.

Я использовал домашнюю версию WhoCrashed для просмотра мини-дампов, но недавно я обнаружил WinDBG (ПОЧЕМУ ЭТО НЕ СТАНДАРТНАЯ ОСОБЕННОСТЬ ОС?!?!?!), Но я создал только два дампа с момента его обнаружения, поэтому не много новой информации. Один дамп указал на «memory_corruption», что побудило запустить WMD.

У меня есть два мини-дампа и memory.dmp, которыми я могу поделиться через Dropbox, если они кому-нибудь пригодятся, но они только из последних двух дней.

Спасибо за любые предложения.

1 ответ1

2

Хорошо, я посмотрел на ваш файл memory.dmp. Похоже, что поток, принадлежащий одному из процессов Chrome, был близок к "конечным этапам" завершения записи в объект "именованный канал", реализованный npfs.sys, драйвером "файловой системы именованного канала".

Вот что важно для именованных каналов /npfs.sys: Это механизм межпроцессного взаимодействия, реализованный в виде псевдоустройства. Это очень устоявшийся стабильный код. Это было в Windows навсегда. Он используется многими внутренними процессами Windows. Не удивительно, что Chrome использует его (для связи между различными процессами Chrome).

И, как псевдоустройство, оно не является специфичным для какого-либо оборудования. Таким образом, на каждой машине Windows, на которой установлена одна и та же версия ОС, используется один и тот же двоичный файл npfs.sys. Это не похоже на беспроводную карту или видеокарту, где есть много разных драйверов "WiFi" или "видео".

Таким образом, мы можем быть достаточно уверены, что проблема не в npfs.sys. И это, конечно, не в IopCompleteRequest (подпрограмма, которая вызвала необработанное исключение, пытаясь записать на неопределенный адрес, который был последней "причиной" сбоя). Оба из них - очень напряженный и надежный код. Другими подпрограммами режима ядра в стеке являются NtWriteFile и KiSystemServiceCopyEnd - также совсем не подозреваемые. (NtWriteFile вызывается для каждой функции записи в каждый файл или устройство; KiSystemServiceCopyEnd для подавляющего большинства вызовов от пользователя к режиму ядра - и, между прочим, он не имеет никакого отношения к сервисным процессам.)

Как я сказал в комментарии выше - я бы заменил блок питания. Я видел, как блоки питания вызывали похожие шквалы "широко варьируемых" BSOD. Убедитесь, что вы получаете один с одной большой 12-вольтовой шиной, а не несколькими рельсами - это обеспечивает лучшую защиту от кратковременных провисаний и пиков. Это особенно важно, учитывая, что у вас есть два графических процессора.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .