4

РЕШЕНИЕ: Это были настройки ОЗУ все время: - | Мне никогда не приходило в голову, что стандартные настройки на стандартной плате со стандартной оперативной памятью будут настолько далеки, что это вызовет нестабильность системы. Я никогда не занимался разгоном, поэтому я не очень внимательно смотрел на эти настройки. Как только я выбрал профиль DOCP, который соответствовал моей оперативной памяти, все прояснилось, и это даже немного быстрее. Спасибо Twisty Impersonator за руководство по процессу и magicandre1981 за предложение, которое побудило меня проверить настройки. Надеюсь, это спасет кого-то еще 2 года разочарования.

РЕДАКТИРОВАТЬ: Ну, я думаю, причина стала ясной. После замены ВСЕГО оборудования и ЕЩЕ ВИДЯ проблемы, я решил вернуться к идее аппаратного обеспечения. Короче: если я бегу с двумя флешками ОЗУ, все нормально. Неважно, какие две палки. Если я вставлю все четыре, у меня начнутся проблемы. Это кажется довольно четким признаком плохой материнской платы.

Симптомы:

Последние несколько лет моя машина в целом была нестабильной, выключалась и включалась. Обычно проявляется как BSOD с различными кодами остановки.

  • Обновление ОЗУ улучшило стабильность на некоторое время.
  • Обновление материнской платы улучшило стабильность на некоторое время.
  • Замена диска C: на некоторое время улучшила стабильность.
  • Обновление или переустановка ОС иногда была необходима, и обычно на некоторое время повышает стабильность.

Я заменил буквально все функциональные компоненты в системе, кроме процессора и привода Blu-ray. Я не исключил возможности процессора, но все еще существует множество программных "вещей", которые тоже могут быть виноваты.

Каждый раз проблема возвращалась через несколько месяцев.


Совсем недавно симптомы немного изменились. Я открыт для возможности, что это совершенно не связанная проблема, но она кажется слишком похожей на проблемы, с которыми я боролся все время, чтобы быть простым совпадением.

Несколько недель я перезагружал свой компьютер для обновления, и он не будет POST . Я некоторое время возился с этим (проверял соединения, MemOK! кнопку, отключите питание, TPU / выкл, EPU / выкл и т. д.) и получил его в POST , но ОС не будет загружаться. Я забыл точное представление симптомов, но IIRC это будет просто сидеть и вращаться.

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

  • Прошло последнее обновление BIOS. Без изменений.
    • Оказывается, вы должны сбросить CMOS при прошивке BIOS. Потенциальные симптомы очень похожи на мои. Я сбросил CMOS. Без изменений.
  • Обычно это были приложения с высоким спросом, которые могли аварийно завершить работу (Dishonored 2, Diablo III, ESO и т.д.). Но происходит сбой между 35 ° C-45 ° C для процессора и графического процессора - так что, вероятно, не температура.
  • Это не заканчивается ОЗУ.
  • MemTest никогда не показывал никаких проблем. Я запускал его десятки раз.
  • Ни один тест процессора не показал каких-либо проблем, кроме как при высоких температурах.
  • Ни один тест GPU никогда не показал никаких проблем, кроме как при высоких температурах.
  • Я переустанавливал свои видеодрайверы несколько десятков раз.
  • У меня был сбой Task Manger, когда я смотрел вчера.
  • Попытался установить приложение для Магазина Windows. Произошел сбой некоторого фонового процесса. Пришлось попробовать еще раз. Работал нормально.
  • Event Viewer имеет только события AppCrash

События AppCrash создаются широким спектром приложений. Различных размеров, мест, потребностей и т.д. Обычно это раз в день, может быть, меньше. Но приложения с высокими ресурсами аварийно завершают работу в течение 30 минут или около того.

Я должен уточнить, что это не Windows is looking for a solution событий AppHang. Приложение просто исчезает, как будто я закрыл его, и Windows ничего не может сказать об этом, кроме события AppCrash в Event Viewer. Реже есть BSOD. В последнее время я видел IRQ not less than or equal , и другие, которые я не могу вспомнить ... (У меня больше нет дампов памяти? Это странно...).

Системные характеристики:

  • ОС: Windows 10 Pro (обновлена с Win7 во время бесплатного обновления)
  • Процессор: AMD Phenom II 1090 (без разгона)
  • Охлаждение: вентиляторы CPU CoolerMaster 150 мм, несколько корпусных вентиляторов
  • Материнская плата : ASUS M4A99X EVO R2.0
  • Оперативная память: G.Skill 16GB (4x4) DDR3-1333
  • GPU: MSI GTX 970 (без разгона)
  • Блок питания: Corsair CX750M
  • Системный диск: Samsung 850 EVO 500GB
  • Другие накопители: Samsung 850 EVO 500GB, другие обычные накопители, оптический привод
  • A/V: Защитник Windows, нет другого AV

Аварийная свалка:

По этому сообщению: https://superuser.com/questions/1281659/possible-to-determine-which-core-a-faulting-application-was-on-when-it-crashed

Ударьте новый BSOD, пока он простаивал прошлой ночью. Подробности от WhoCrashed ниже:

Crash dump directory: C:\WINDOWS\Minidump
Crash dumps are enabled on your computer.

On Wed 1/3/2018 9:00:13 AM GMT your computer crashed
crash dump file: C:\WINDOWS\Minidump\010318-12546-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x1640E0)
Bugcheck code: 0x1E (0xFFFFFFFFC0000005, 0xFFFFF8019CED183E, 0xFFFF968442FBEB68, 0xFFFF968442FBE3B0)
Error: KMODE_EXCEPTION_NOT_HANDLED
file path: C:\WINDOWS\system32\ntoskrnl.exe
product: Microsoft® Windows®
Operating System company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that a kernel-mode program generated an exception
which the error handler did not catch. This appears to be a typical software driver bug
and is not likely to be caused by a hardware problem.  The crash took place in the Windows
kernel. Possibly this problem is caused by another driver that cannot be identified at this time. 

On Wed 1/3/2018 9:00:13 AM GMT your computer crashed
crash dump file: C:\WINDOWS\memory.dmp
This was probably caused by the following module: ntdll.sys (ntdll!ZwFlushBuffersFile+0x14)
Bugcheck code: 0x1E (0xFFFFFFFFC0000005, 0xFFFFF8019CED183E, 0xFFFF968442FBEB68, 0xFFFF968442FBE3B0)
Error: KMODE_EXCEPTION_NOT_HANDLED
Bug check description: This indicates that a kernel-mode program generated an exception
which the error handler did not catch. This appears to be a typical software driver bug
and is not likely to be caused by a hardware problem.  A third party driver was identified
as the probable root cause of this system error. It is suggested you look for an update for
the following driver: ntdll.sys.G
Google query: ntdll.sys KMODE_EXCEPTION_NOT_HANDLED

Дампы памяти (полный и мини) будут здесь, так как они доступны: https://1drv.ms/f/s!AhSzRvnavkrXhPpNy8Qjhaj6LbbTwQ


@ magicandre1981 рекомендовал chkdsk /f на основе результатов моего дампа памяти. C: единственный диск, для которого включен файл подкачки (он управляется системой), поэтому я запустил его. Вот результаты:

Проверка файловой системы на C: Тип файловой системы - NTFS.

A disk check has been scheduled.
Windows will now check the disk.                         

Stage 1: Examining basic file system structure ...
  605184 file records processed.                                                         File verification completed.
Deleting orphan file record segment 699DD.
  10717 large file records processed.                                      0 bad file records processed.                                      
Stage 2: Examining file name linkage ...
  14846 reparse records processed.                                         704776 index entries processed.                                                        Index verification completed.
  0 unindexed files scanned.                                           0 unindexed files recovered to lost and found.                       14846 reparse records processed.                                       
Stage 3: Examining security descriptors ...
Cleaning up 1426 unused index entries from index $SII of file 0x9.
Cleaning up 1426 unused index entries from index $SDH of file 0x9.
Cleaning up 1426 unused security descriptors.
Security descriptor verification completed.
  49797 data files processed.                                            CHKDSK is verifying Usn Journal...
  37651904 USN bytes processed.                                                            Usn Journal verification completed.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
CHKDSK discovered free space marked as allocated in the volume bitmap.

Windows has made corrections to the file system.
No further action is required.

 487284001 KB total disk space.
 209659436 KB in 259738 files.
    162276 KB in 49798 indexes.
         0 KB in bad sectors.
    729085 KB in use by the system.
     65536 KB occupied by the log file.
 276733204 KB available on disk.

      4096 bytes in each allocation unit.
 121821000 total allocation units on disk.
  69183301 allocation units available on disk.

Internal Info:
00 3c 09 00 f0 b8 04 00 7e 93 08 00 00 00 00 00  .<......~.......
98 05 00 00 66 34 00 00 00 00 00 00 00 00 00 00  ....f4..........

Windows has finished checking your disk.
Please wait while your computer restarts.

Неудачно. Даже после того, как chkdsk исправил эти проблемы, у меня все еще возникают те же сбои, хотя новых BSOD еще нет.


Другой BSOD, когда я открывал браузер, чтобы обновить этот вопрос. Memdumps доступны после завершения загрузки.

Но первоначальная причина, по которой я пришел, чтобы обновить информацию, заключается в том, что я нашел целый колпак (точнее 51) событий, которые выглядят абсолютно одинаково. Похоже, они происходили примерно каждые полчаса, начиная сразу после того, как я ушел на работу (7:30 утра) до 8:30 вечера. Они все еще могут происходить. Все они выглядят именно так:

Fault bucket 0x1E_c0000005_fltmgr!FltpPreFsFilterOperation, type 0
Event Name: BlueScreen
Response: Not available
Cab Id: 0

Problem signature:
P1: 1e
P2: ffffffffc0000005
P3: fffff8019ced183e
P4: ffff968442fbeb68
P5: ffff968442fbe3b0
P6: 10_0_16299
P7: 0_0
P8: 256_1
P9: 
P10: 

Attached files:
\\?\C:\WINDOWS\Minidump\010318-12546-01.dmp
\\?\C:\WINDOWS\TEMP\WER-18531-0.sysdata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER5795.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER57A5.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER57B6.tmp.txt
\\?\C:\Windows\Temp\WER8F12.tmp.WERDataCollectionStatus.txt

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Kernel_1e_b49232881f44bde28acca17f0ad8bac3b4fbb67_00000000_cab_031c57c4

Analysis symbol: 
Rechecking for solution: 0
Report Id: 3c2abe43-d7d6-4561-9b0d-2adf1f40c745
Report Status: 388
Hashed bucket: 

Мне трудно поверить, что процессор будет иметь эту проблему так долго, и компьютер все еще будет функционировать. У меня не было большого успеха, исследуя проблемы программного обеспечения / конфигурации.

Есть идеи?


Почти 3 недели спустя .... После многих махинаций я наконец-то приобрел новый процессор (обновленный с Phenom II до FX-8350). Замена была достаточно легкой. Затем исследуйте общие проблемные области, и приложения по-прежнему не работают.

Как только я опубликовал "грустное лицо", Windows рассказала мне что-то о "Отчете о работоспособности устройства". Сообщает о проблемах с водителем. К сожалению, но неудивительно, что Средство устранения неполадок не смогло обнаружить какую-либо проблему. Я удалил два устройства "USB Root Hub" в состоянии ошибки из диспетчера устройств.

Рифмуется с бассейном

Предоставляет ли это какие-либо дополнительные подсказки? Я действительно в растерянности, сейчас ...


Вот список информации о драйвере ...? https://docs.google.com/spreadsheets/d/1xAliAOt1s8rQ_ePX5OwTRVFPB3kFYgc3-1HRUznMpR0/edit?usp=sharing

1 ответ1

1

Разделяй и властвуй

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

По моему опыту, наиболее эффективный способ определить, какой лагерь виноват, - это загрузить вторую, совершенно другую ОС (не обращая внимания на какое-либо оборудование) и попытаться воспроизвести проблему. Лучше всего использовать ОС , которая не использует какой - либо из того же кода , как подозреваемый OS. Например, если ваша подозрительная система работает под управлением Windows, вы можете использовать Ubuntu для своей тестовой ОС. Живые компакт-диски хороши для этого.

С периодически возникающими проблемами это может быть непросто, но как бы вы это ни делали, вам нужно знать, если:

  • Обе операционные системы затронуты, что означает, что у вас есть проблемы с оборудованием, или
  • Это касается только вашей подозрительной ОС, то есть у вас может быть:

    • Проблема с программным обеспечением или
    • Несовместимость между аппаратным компонентом и конкретным программным обеспечением (которое почти всегда является драйвером стороннего производителя).

Если вы думаете, что это аппаратное обеспечение

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

Если вы думаете, что это программное обеспечение

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

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

Когда неясно, какое программное обеспечение является ошибочным, ваше оружие выбора - удалить программное обеспечение из уравнения и запустить систему достаточно долго, чтобы дать возможность проблеме возникнуть, если она возникнет. Вы можете сделать это:

  1. Удалите программное обеспечение.
  2. Отключите его с помощью такого инструмента, как Microsoft AutoRuns.
  3. Отключите его, загрузившись в безопасном режиме.
  4. Создайте вторую установку Windows без соответствующего программного обеспечения (полезно, если вам действительно нужно программное обеспечение для повседневного использования и вы хотите легко переключаться между режимами "тестирования" и "производства").

При этом мне нравится классифицировать программное обеспечение системы следующим образом и устранять неполадки соответственно:

  1. Собственный код Windows и входящие драйверы. Очень вряд ли виноват. Легко подтверждается тестирование системы с помощью нетронутых установок (один без 3 - го коды партии).
  2. Сторонние драйверы. Всегда вызывает проблемы. Обычно происходит сбой неслучайным образом, так что возникает шаблон. Протестируйте, используя разные версии драйверов или меняя аппаратные компоненты.
  3. Стороннее программное обеспечение системного уровня (например, программное обеспечение безопасности). Неудобные. Они редко требуются для правильной работы системы и могут быть полностью удалены для проверки их влияния.
  4. Пользовательские приложения. Сильно изменчивое поведение при сбое. В современных версиях Windows они редко дают сбой или блокируют всю систему. Сбои возникают только во время работы приложения, поэтому легко отслеживать сбои и соотносить их с программами, которые выполнялись в то время. Следите за пользовательскими приложениями, которые имеют постоянно включенный компонент, например, элементы автозагрузки или системные службы.

Ведите полу-подробный журнал работ

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


Анекдотическая история

Я работал над системой, которая напоминает мне о вашей ситуации. Это был ноутбук (который ограничивал мои возможности замены оборудования), который зависал случайным образом. Он будет делать это через 10 секунд после включения, затем не в течение нескольких дней, а затем после нескольких часов. Я обновил все, протестировал и заменил каждый аппаратный компонент, который мог, и переустановил Windows (по крайней мере, один раз, если не дважды).

Это оказалось материнской платой. После замены ноутбук работал без проблем в течение многих лет.

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