AppCrashおよびBSODイベント、一般的な不安定性の原因は何ですか？

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
toskrnl.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。アップロードが完了すると、Memdumpが利用可能になります。

しかし、私が更新するようになった最初の理由は、まったく同じように見えるイベントの全体（正確には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にアップグレードされました）。交換は簡単でした。次に、一般的な問題領域を調べますが、アプリはまだクラッシュしています。

「悲しい顔」を投稿するとすぐに、Windowsは「デバイスヘルスレポート」について何かを教えてくれました。ドライバーのトラブルを報告します。残念ながら、当然のことながら、トラブルシューターはいかなる種類の問題も検出できませんでした。エラー状態の2つの「USBルートハブ」デバイスをデバイスマネージャーからアンインストールしました。

これは追加の手がかりを提供しますか？私は本当に途方に暮れています、今...

これがドライバー情報のリストです...？ https://docs.google.com/spreadsheets/d/1xAliAOt1s8rQ_ePX5OwTRVFPB3kFYgc3-1HRUznMpR0/edit?usp=sharing

I say Reinstate Monica · Accepted Answer

分割統治

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

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

断続的に発生する問題では、これは困難な場合がありますが、どのように対処しても、次のことを知る必要があります。

両方のOSが影響を受けます。つまり、ハードウェアに問題があるか、または
疑わしいOSのみが影響を受けます。つまり、次のいずれかが発生している可能性があります。
- ソフトウェアの問題、または
- ハードウェアコンポーネントと特定のソフトウェア（ほとんどの場合、サードパーティのドライバー）間の非互換性。

あなたがそれがハードウェアだと思うなら

すでに多くのコンポーネントをテストして交換しました。望ましくない動作がテストOSに現れた場合は、まだ置き換えていないものに問題があるという決定的な証拠があります。包括的なテストに適さないコンポーネント（マザーボードなど）の場合は、最初に他の安価なコンポーネントを交換してみることをお勧めしますが、最終的には、より高価なコンポーネントも交換するしかありません。

あなたがそれがソフトウェアだと思うなら

テストOSが障害を引き起こさない場合は、ターゲットOSのソフトウェアに問題があることを確信できます。ただし、これまで障害をオンデマンドで生成できなかった場合、または断続的にしか発生しなかった場合は、テストOSでトリガーされなかったハードウェアの問題である可能性があります。これにこだわるな。暫定的なソリューションをテストするときは、この点に注意してください。

障害のあるコードを分類するときは、Windowsのバグチェックコード、イベントログ、またはアプリケーション固有のログに記録されたエラーなど、特定のエラーメッセージをフォローアップする必要があることは明らかです。あなたがそれらのリードを使い果たし、より一般的なアプローチが必要であるという仮定に基づいて、これらのステップをスキップします。

どのソフトウェアに問題があるのかが不明な場合は、方程式からソフトウェアを削除するを選択し、問題が発生する可能性がある場合は、問題が発生するのに十分な時間システムを実行します。これは次の方法で実行できます。

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

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

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

半詳細な作業ログを保持する

ここで最終的な考え。発生した問題と実行したトラブルシューティング手順を尋ねるログを保管してください。このような困難で引き出された問題では、詳細を忘れがちです。作業中にこれを確認できると、原因を除外したり、闘争で失われる可能性のある事実を結び付けたりするのに役立つ場合があります。

逸話

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

結局マザーボードになりました。交換後、ラップトップは何年も問題なく動作しました。