分割して征服する

Question

解決法: 最初から RAM 設定の問題でした :-| 標準 RAM を搭載した標準ボードの標準設定が、システムを不安定にするほど大きく外れているとは思いもよりませんでした。オーバークロックをしたことがなく、それらの設定を詳しく調べたことはありませんでした。RAM に一致する DOCP プロファイルを選択すると、すべてが解決し、さらに少し高速になりました。プロセス ガイドを提供してくれた Twisty Impersonator と、設定を確認するよう促してくれた magicandre1981 に感謝します。これで、他の誰かが 2 年間のフラストレーションから解放されることを願っています。

編集: 原因は明らかになったと思います。すべてのハードウェアを交換した後、まだ問題が見られるため、ハードウェアの考えに戻ることにしました。要するに、RAM スティックを 2 本使用すれば、すべて問題ありません。どの 2 本かは関係ありません。4 本すべてを挿入すると、問題が発生し始めます。これは、マザーボードの不良を示すかなり明確な兆候のようです。

症状:

ここ数年、私のマシンは全体的に不安定で、オンとオフを繰り返す状態です。通常は、さまざまな停止コードを伴う BSOD として現れます。

• RAM をアップグレードすると、しばらくの間、安定性が向上しました。
• マザーボードをアップグレードすると、しばらくの間、安定性が向上しました。
• ドライブを交換すると、C:しばらくの間、安定性が向上しました。
• OS の更新または再インストールが時々必要になりますが、通常はしばらくは安定性が向上します。

CPUとブルーレイドライブを除く、システム内の機能部品をすべて交換しました。CPU を除外したわけではありませんが、依然として、ソフトウェアの「もの」が多数存在し、それらも問題の原因となっている可能性があります。

毎回、数か月後には問題が再発します。

---

最近、症状が少し変化しました。これは全く関係のない問題である可能性もあるのですが、私がずっと闘ってきた問題とあまりにも似ているため、単なる偶然とは思えません。

数週間後、アップデートするためにコンピュータを再起動しましたが、再起動しませんでしたPOST。しばらくいじってみて（接続、MemOK!ボタン、電源の切断、TPUオン/オフ、EPUオン/オフなどを確認）、再起動しましたPOSTが、OS が読み込まれませんでした。症状の正確な内容は忘れましたが、記憶が正しければ、ただ座って回転しているだけでした。

OS を再インストールし、1 週間ほどは何も起こらなかったのですが、アプリがクラッシュし始めました。最初は、クラッシュするアプリはすべて同じ SSD にインストールされているようでした。移動したりテストしたりする余裕がなかったので、新しい Samsung ドライブにアップグレードしました。しかし、アプリはまだクラッシュします。

• 最新の BIOS アップデートをフラッシュしました。変化はありません。
  • 結局、BIOS をフラッシュするときに CMOS をリセットする必要があることがわかりました。潜在的な症状は私の場合とよく似ています。CMOS をリセットしました。変化はありません。
• クラッシュするのは通常、需要の高いアプリケーションです (Dishonored 2、Diablo III、ESO など)。ただし、クラッシュは CPU と GPU の温度が 35°C ～ 45°C の間で発生するため、温度の問題ではないと考えられます。
• RAMが不足していません。
• MemTestこれまで何の問題もありませんでした。何十回も実行しました。
• 高温時を除き、CPU テストではこれまで問題は発生していません。
• 高温時を除き、GPU テストではこれまで問題は発生していません。
• ビデオドライバーを数十回再インストールしました。
• 昨日視聴中にタスク マネージャーがクラッシュしました。
• Windows ストア アプリをインストールしようとしました。バックグラウンド プロセスがクラッシュしました。再試行する必要がありました。問題なく動作しました。
• イベントビューアにはAppCrashイベントのみが表示されます

AppCrashイベントは、さまざまなアプリケーションによって生成されます。サイズ、場所、要求などが異なります。通常は 1 日に 1 回、それより少ない場合もあります。ただし、リソースを大量に消費するアプリケーションは、30 分程度以内に確実にクラッシュします。

これらは AppHang イベントではないことを明確にしておきますWindows is looking for a solution。アプリケーションは、閉じたかのように消え、Windows はイベント ビューアーの AppCrash イベント以外何も表示しません。頻度は低いですが、BSOD もあります。最近、、IRQ not less than or equalその他、思い出せないイベントが発生しました... (メモリ ダンプがなくなったのはなぜですか? おかしいですね...)。

システム仕様:

• OS:Windows 10 Pro（無料アップグレード期間中にWin7からアップグレード）
• CPU：AMD Phenom II 1090 (オーバークロックなし)
• 冷却：CoolerMaster 150mm CPUファン、ケースファン数個
• メインボード:ASUS M4A99X EVO R2.0
• ラム：G.Skill 16GB(4x4) DDR3-1333
• グラフィック:MSI GTX 970 (オーバークロックなし)
• 電源ユニット:コルセア CX750M
• システムドライブ:サムスン 850 EVO 500GB
• その他のドライブ:Samsung 850 EVO 500GB、その他の従来型ドライブ、光学ドライブ
• オーディオ/ビデオ:Windows Defender、他の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分頃まで、約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: 

---

CPU にこれほど長い間この問題がありながら、コンピュータがまだ機能しているとは信じられません。ソフトウェア/構成の問題を調査してもあまり成功しませんでした。

何か案は？

---

ほぼ 3 週間後.... 大変な苦労の末、ようやく新しい CPU を入手しました (Phenom II から FX-8350 にアップグレード)。交換は簡単でした。その後、一般的な問題領域を調べましたが、アプリはまだクラッシュしています。

「sad-face」を投稿するとすぐに、Windows から「デバイス ヘルス レポート」についての説明が届きました。ドライバーに問題があることが報告されています。残念ながら、予想どおり、トラブルシューティング ツールでは問題を検出できませんでした。デバイス マネージャーから、エラー状態にある 2 つの「USB ルート ハブ」デバイスをアンインストールしました。

これによって何か追加の手がかりが得られますか? 今は本当に困惑しています...

---

ドライバー情報の一覧はこちらになります。 https://docs.google.com/spreadsheets/d/1xAliAOt1s8rQ_ePX5OwTRVFPB3kFYgc3-1HRUznMpR0/edit?usp=sharing

Answer 1

分割して征服する

まず、これがハードウェアの問題なのかソフトウェアの問題なのかを判断する必要があります。両方に関係している場合もありますが、最初はそうではないと想定するのが最善です。

私の経験では、どちらが問題を抱えているかを判断する最も効果的な方法は、2番目の完全に異なるOSを起動して（ハードウェアを変更せずに）、問題を再現してみることです。どれでも疑わしい OS と同じコードを使用します。たとえば、疑わしいシステムが Windows を実行している場合は、テスト OS として Ubuntu を使用できます。この場合、ライブ CD が適しています。

断続的に発生する問題の場合、これは困難な場合がありますが、どのような方法で対処するにしても、次の点について知っておく必要があります。

• 両方のOSが影響を受けているため、ハードウェアに問題があるか、

• 影響を受けるのは疑わしい OS のみであり、次のいずれかである可能性があります。

  • ソフトウェアの問題、または
  • ハードウェア コンポーネントと特定のソフトウェア (ほとんどの場合、サード パーティ ドライバー) 間の非互換性。

ハードウェアだと思ったら

すでに多くのコンポーネントをテストし、交換しています。テスト OS で望ましくない動作が明らかになった場合、まだ交換していないコンポーネントに問題があるという決定的な証拠が得られます。包括的なテストに適さないコンポーネント (マザーボードなど) については、まず他の安価なコンポーネントを交換してみることをお勧めしますが、最終的には高価なコンポーネントも交換せざるを得なくなる可能性があります。

ソフトウェアだと思ったら

テスト OS で障害が発生しない場合は、ターゲット OS のソフトウェアに問題があると確信できます。ただし、障害がこれま​​でオンデマンドで発生しなかったり、断続的にしか発生しなかったりする場合は、テスト OS で発生しなかったハードウェアの問題である可能性が残ります。この点については考えすぎず、暫定的な解決策をテストするときには念頭に置いてください。

どのコードに問題があるのか​​を整理する場合、Windows のバグチェック コード、イベント ログに記録されたエラー、アプリケーション固有のログなど、特定のエラー メッセージを追跡する必要があるのは明らかです。これらの手がかりをすべて調べ尽くし、より一般的なアプローチが必要であるという前提で、これらの手順は省略します。

どのソフトウェアに問題があるか不明な場合、選択する武器はソフトウェアを方程式から除外する問題が発生する可能性がある場合は、システムを十分に長く実行して、問題が発生する機会を与えます。これを行うには、次の操作を実行します。

1. ソフトウェアをアンインストールします。
2. Microsoft AutoRuns などのツールを使用して無効にします。
3. セーフモードで起動して無効にします。
4. 2番目のWindowsインストールを作成するそれなし問題のソフトウェア（日常的にソフトウェアが必要で、「テスト」モードと「本番」モードを簡単に切り替えられるようにしたい場合に便利です）。

これを実行するときは、システムのソフトウェアを次のように分類し、それに応じてトラブルシューティングを行うことをお勧めします。

1. Windows 独自のコードと受信トレイ ドライバー。最も故障の可能性が低い。システムを新品同様のインストール（どれでもサードパーティコード)。
2. サードパーティのドライバー。常に問題を引き起こします。通常、パターンが現れる非ランダムな方法でクラッシュします。異なるドライバー バージョンを使用するか、ハードウェア コンポーネントを交換してテストします。
3. サードパーティのシステムレベルソフトウェア(例: セキュリティ ソフトウェア) 面倒です。これらはシステムの正常な動作にはほとんど必要ないため、その影響をテストするために完全にアンインストールできます。
4. ユーザーアプリケーション。クラッシュの動作は大きく異なります。Windows の最新バージョンでは、クラッシュやシステム全体のロックアップが発生することはほとんどありません。障害はアプリケーションの実行中にのみ発生するため、障害を追跡し、その時点で実行されていたプログラムと関連付けることは簡単です。スタートアップ項目やシステム サービスなどの常時オンのコンポーネントを持つユーザー アプリケーションには注意してください。

ある程度詳細な作業ログを記録する

最後に、遭遇した問題と実行したトラブルシューティング手順を記録しておきます。今回のような難しくて長引く問題では、詳細を忘れがちです。作業中にこれを確認できれば、原因を除外したり、苦労して見落としていたかもしれない事実間のつながりを見つけたりするのに役立つかもしれません。

---

逸話

私は、あなたの状況を思い出させるようなシステムに取り組んでいました。それは、ハードウェアの交換オプションが制限されるラップトップで、ランダムにロックアップしていました。電源投入後 10 秒でロックアップし、その後数日間ロックアップせず、数時間電源を入れた後にロックアップしました。私はすべてを更新し、可能な限りすべてのハードウェア コンポーネントをテストして交換し、Windows を再インストールしました (少なくとも 1 回、場合によっては 2 回)。

結局、原因はマザーボードでした。交換後、ノートパソコンはその後何年も問題なく動作しました。