Ryzen 5 3400G Sistemde Mavi Ekran Hatası

P

Pain00

Kilopat
Katılım
21 Ocak 2017
Mesajlar
435
Çözümler
1
Daha fazla  
Cinsiyet
Erkek
Yeni sipariş ettiğim sistemde mavi ekran hatası almaktayım. Counter Strike Global Offensive oynarken oluyor. Mavi Ekran Dosyası bu linkte. Minidump Dosyasına bakıp yardım edecek varsa sevinirim.

Bilgisayar Özellikleri:
  • AMD Ryzen 5 3400G
  • Asrock A-320M HDVR4
  • G.Skill Ripjaws 2x8 GB RAM (3000 MHz çalışıyor.)
  • Toshiba OCZ 240 GB SSD
  • High Power 500W 80+ PSU

BIOS son sürümde güncel. Ekran Kartı yazılımını bir önceki sürüme getirdim. Önceden mavi ekran aldığım yerde şuanda almıyorum. Bu dosyalar GPU yazılımı bir eskiye çevirmeden önceye aittir. Telefondan açıyorum konuyu yazım yanlışım olduysa affola.
 
Son düzenleyen: Moderatör:
Tarihe göre sırala Puana göre sırala
Dahili GPU cevap vermeyi kesiyor. XMP'yi kapatıp dener misiniz? Bir de BIOS güncel mi?

Kod: 
THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: ffff8f0bce0d2080, Pointer to a stuck thread object.  Do .thread then kb on it to find
    the hung location.
Arg2: 0000000000000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 0000000000000000, Pointer to offending driver name.
Arg4: 0000000000000000, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

Debugging Details:
------------------


KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.Sec
    Value: 4

    Key  : Analysis.DebugAnalysisProvider.CPP
    Value: Create: 8007007e on DESKTOP-1IBQR0U

    Key  : Analysis.DebugData
    Value: CreateObject

    Key  : Analysis.DebugModel
    Value: CreateObject

    Key  : Analysis.Elapsed.Sec
    Value: 71

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 74

    Key  : Analysis.System
    Value: CreateObject


ADDITIONAL_XML: 1

BUGCHECK_CODE:  ea

BUGCHECK_P1: ffff8f0bce0d2080

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FAULTING_THREAD:  ffff8f0bce0d2080

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  RadeonSoftware.exe

STACK_TEXT: 
fffff60a`9f875a88 fffff805`7fa60db5 : 00000000`000000ea ffff8f0b`ce0d2080 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff60a`9f875a90 fffff805`7fa60e8e : fffff60a`9f875b70 fffff805`7fa3beab fffff60a`9f875b70 fffff805`85c32094 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
fffff60a`9f875b00 fffff805`85b88b90 : 00000006`0a63712c fffff805`85c32094 00000000`00000000 ffff8f0b`c6437000 : dxgkrnl!TdrTimedOperationDelay+0xce
fffff60a`9f875b40 00000006`0a63712c : fffff805`85c32094 00000000`00000000 ffff8f0b`c6437000 00000000`00989680 : atikmdag+0x68b90
fffff60a`9f875b48 fffff805`85c32094 : 00000000`00000000 ffff8f0b`c6437000 00000000`00989680 00000000`00000001 : 0x00000006`0a63712c
fffff60a`9f875b50 00000000`00000000 : ffff8f0b`c6437000 00000000`00989680 00000000`00000001 00000000`00000028 : atikmdag+0x112094


STACK_COMMAND:  .thread 0xffff8f0bce0d2080 ; kb

SYMBOL_NAME:  dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45

MODULE_NAME: dxgkrnl

IMAGE_NAME:  dxgkrnl.sys

IMAGE_VERSION:  10.0.18362.1053

FAILURE_BUCKET_ID:  0xEA_IMAGE_dxgkrnl.sys

OS_VERSION:  10.0.18362.1

BUILDLAB_STR:  19h1_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {ea458ad2-d5ab-aa6c-7a11-54653c70dfb8}

Followup:     MachineOwner
---------

THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: ffff950303e1b080, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 0000000000000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 0000000000000000, Pointer to offending driver name.
Arg4: 0000000000000000, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

Debugging Details:
------------------


KEY_VALUES_STRING: 1

Key : Analysis.CPU.Sec
Value: 3

Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on DESKTOP-1IBQR0U

Key : Analysis.DebugData
Value: CreateObject

Key : Analysis.DebugModel
Value: CreateObject

Key : Analysis.Elapsed.Sec
Value: 69

Key : Analysis.Memory.CommitPeak.Mb
Value: 74

Key : Analysis.System
Value: CreateObject


ADDITIONAL_XML: 1

BUGCHECK_CODE: ea

BUGCHECK_P1: ffff950303e1b080

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FAULTING_THREAD: ffff950303e1b080

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: RadeonSoftware.exe

STACK_TEXT:
fffffd8c`b2ec2a88 fffff802`7f620ca5 : 00000000`000000ea ffff9503`03e1b080 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffffd8c`b2ec2a90 fffff802`7f620d7e : fffffd8c`b2ec2b70 fffff802`7f5fbdeb fffffd8c`b2ec2b70 fffff802`86242094 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
fffffd8c`b2ec2b00 fffff802`86198b90 : 00000003`235d2f03 fffff802`86242094 00000000`00000000 ffff9503`05818000 : dxgkrnl!TdrTimedOperationDelay+0xce
fffffd8c`b2ec2b40 00000003`235d2f03 : fffff802`86242094 00000000`00000000 ffff9503`05818000 00000000`00989680 : atikmdag+0x68b90
fffffd8c`b2ec2b48 fffff802`86242094 : 00000000`00000000 ffff9503`05818000 00000000`00989680 00000000`00000001 : 0x00000003`235d2f03
fffffd8c`b2ec2b50 00000000`00000000 : ffff9503`05818000 00000000`00989680 00000000`00000001 00000000`00000028 : atikmdag+0x112094


STACK_COMMAND: .thread 0xffff950303e1b080 ; kb

SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45

MODULE_NAME: dxgkrnl

IMAGE_NAME:  dxgkrnl.sys

IMAGE_VERSION: 10.0.18362.10050

FAILURE_BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys

OS_VERSION: 10.0.18362.1

BUILDLAB_STR: 19h1_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {ea458ad2-d5ab-aa6c-7a11-54653c70dfb8}

Followup: MachineOwner
---------

THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: ffff8d8524a47080, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 0000000000000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 0000000000000000, Pointer to offending driver name.
Arg4: 0000000000000000, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

Debugging Details:
------------------

*** WARNING: Unable to verify checksum for win32k.sys

KEY_VALUES_STRING: 1

Key : Analysis.CPU.Sec
Value: 3

Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on DESKTOP-1IBQR0U

Key : Analysis.DebugData
Value: CreateObject

Key : Analysis.DebugModel
Value: CreateObject

Key : Analysis.Elapsed.Sec
Value: 71

Key : Analysis.Memory.CommitPeak.Mb
Value: 74

Key : Analysis.System
Value: CreateObject


ADDITIONAL_XML: 1

BUGCHECK_CODE: ea

BUGCHECK_P1: ffff8d8524a47080

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FAULTING_THREAD: ffff8d8524a47080

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: RadeonSoftware.exe

STACK_TEXT:
fffff60c`53298a88 fffff803`8e040ca5 : 00000000`000000ea ffff8d85`24a47080 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff60c`53298a90 fffff803`8e040d7e : fffff60c`53298b70 fffff803`8e01bdeb fffff60c`53298b70 fffff803`93cf2094 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
fffff60c`53298b00 fffff803`93c48b90 : 00000006`80dffff6 fffff803`93cf2094 00000000`00000000 ffff8d85`1c94e000 : dxgkrnl!TdrTimedOperationDelay+0xce
fffff60c`53298b40 00000006`80dffff6 : fffff803`93cf2094 00000000`00000000 ffff8d85`1c94e000 00000000`00989680 : atikmdag+0x68b90
fffff60c`53298b48 fffff803`93cf2094 : 00000000`00000000 ffff8d85`1c94e000 00000000`00989680 00000000`00000001 : 0x00000006`80dffff6
fffff60c`53298b50 00000000`00000000 : ffff8d85`1c94e000 00000000`00989680 00000000`00000001 00000000`00000028 : atikmdag+0x112094


STACK_COMMAND: .thread 0xffff8d8524a47080 ; kb

SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45

MODULE_NAME: dxgkrnl

IMAGE_NAME:  dxgkrnl.sys

IMAGE_VERSION: 10.0.18362.10050

FAILURE_BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys

OS_VERSION: 10.0.18362.1

BUILDLAB_STR: 19h1_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {ea458ad2-d5ab-aa6c-7a11-54653c70dfb8}

Followup: MachineOwner
---------

THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: ffffc10fb0a98480, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 0000000000000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 0000000000000000, Pointer to offending driver name.
Arg4: 0000000000000000, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

Debugging Details:
------------------


KEY_VALUES_STRING: 1

Key : Analysis.CPU.Sec
Value: 3

Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on DESKTOP-1IBQR0U

Key : Analysis.DebugData
Value: CreateObject

Key : Analysis.DebugModel
Value: CreateObject

Key : Analysis.Elapsed.Sec
Value: 77

Key : Analysis.Memory.CommitPeak.Mb
Value: 74

Key : Analysis.System
Value: CreateObject


ADDITIONAL_XML: 1

BUGCHECK_CODE: ea

BUGCHECK_P1: ffffc10fb0a98480

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FAULTING_THREAD: ffffc10fb0a98480

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: RadeonSoftware.exe

STACK_TEXT:
fffffa0b`da116a88 fffff803`3a730ca5 : 00000000`000000ea ffffc10f`b0a98480 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffffa0b`da116a90 fffff803`3a730d7e : fffffa0b`da116b70 fffff803`3a70bdeb fffffa0b`da116b70 fffff803`40292094 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
fffffa0b`da116b00 fffff803`401e8b90 : 00000000`4d0857a9 fffff803`40292094 00000000`00000000 ffffc10f`a934a000 : dxgkrnl!TdrTimedOperationDelay+0xce
fffffa0b`da116b40 00000000`4d0857a9 : fffff803`40292094 00000000`00000000 ffffc10f`a934a000 00000000`00989680 : atikmdag+0x68b90
fffffa0b`da116b48 fffff803`40292094 : 00000000`00000000 ffffc10f`a934a000 00000000`00989680 00000000`00000001 : 0x4d0857a9
fffffa0b`da116b50 00000000`00000000 : ffffc10f`a934a000 00000000`00989680 00000000`00000001 00000000`00000028 : atikmdag+0x112094


STACK_COMMAND: .thread 0xffffc10fb0a98480 ; kb

SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45

MODULE_NAME: dxgkrnl

IMAGE_NAME:  dxgkrnl.sys

IMAGE_VERSION: 10.0.18362.10050

FAILURE_BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys

OS_VERSION: 10.0.18362.1

BUILDLAB_STR: 19h1_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {ea458ad2-d5ab-aa6c-7a11-54653c70dfb8}

Followup: MachineOwner
---------

THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: ffff8803bdb440c0, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 0000000000000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 0000000000000000, Pointer to offending driver name.
Arg4: 0000000000000000, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

Debugging Details:
------------------


KEY_VALUES_STRING: 1

Key : Analysis.CPU.Sec
Value: 3

Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on DESKTOP-1IBQR0U

Key : Analysis.DebugData
Value: CreateObject

Key : Analysis.DebugModel
Value: CreateObject

Key : Analysis.Elapsed.Sec
Value: 77

Key : Analysis.Memory.CommitPeak.Mb
Value: 74

Key : Analysis.System
Value: CreateObject


ADDITIONAL_XML: 1

BUGCHECK_CODE: ea

BUGCHECK_P1: ffff8803bdb440c0

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FAULTING_THREAD: ffff8803bdb440c0

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: RadeonSoftware.exe

STACK_TEXT:
ffff9883`fc80ca88 fffff806`46f80ca5 : 00000000`000000ea ffff8803`bdb440c0 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffff9883`fc80ca90 fffff806`46f80d7e : ffff9883`fc80cb70 fffff806`46f5bdeb ffff9883`fc80cb70 fffff806`4c432094 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
ffff9883`fc80cb00 fffff806`4c388b90 : 00000000`6f95413b fffff806`4c432094 00000000`00000000 ffff8803`bb71a000 : dxgkrnl!TdrTimedOperationDelay+0xce
ffff9883`fc80cb40 00000000`6f95413b : fffff806`4c432094 00000000`00000000 ffff8803`bb71a000 00000000`00989680 : atikmdag+0x68b90
ffff9883`fc80cb48 fffff806`4c432094 : 00000000`00000000 ffff8803`bb71a000 00000000`00989680 00000000`00000001 : 0x6f95413b
ffff9883`fc80cb50 00000000`00000000 : ffff8803`bb71a000 00000000`00989680 00000000`00000001 00000000`00000028 : atikmdag+0x112094


STACK_COMMAND: .thread 0xffff8803bdb440c0 ; kb

SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45

MODULE_NAME: dxgkrnl

IMAGE_NAME:  dxgkrnl.sys

IMAGE_VERSION: 10.0.18362.10050

FAILURE_BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys

OS_VERSION: 10.0.18362.1

BUILDLAB_STR: 19h1_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {ea458ad2-d5ab-aa6c-7a11-54653c70dfb8}

Followup: MachineOwner
---------
 
Artı 0 Eksi
Hocam BIOS son sürümde. Ekran kartı yazılımını bir eski sürüme aldık. Sabahtan beri bir sıkıntı çıkmadı. Bilgisayar geldiğinde XMP otomatik açıktı diye hatırlıyorum. Mavi Ekranı driver yüzünden yapar mı? Eğer yazılımdan yapmıyor ise kapattırayım XMP'yi.
 
Artı 0 Eksi
Recep Baltaş dedi:
Sürücü yüzünden de yapabilir. Eski sürümde sorun yoksa ise yeni sürüm çıkana kadar bu şekilde kullanmaya devam edin.
Genişletmek için tıkla...

Tamamdır bakayım kardeşime test ettiriyorum. Eğer bir sorun çıkarsa XMP'yi kapatmayı denerim. Olmadı yeni Minidump dosyalarını bu konu üzerinden paylaşırım. Teşekkürler yardımınız için.
Hocam bugün de bu hatayı aldık. @claus @Recep Baltaş
 
Son düzenleme:
Artı 0 Eksi
Bu bariz bir bellek sorunu. Belleklerin arızalı da olabilir, anakartın yüksek frekansı kaldırmıyor da olabilir.

Bellek testi de yapabilirsin:

Memtest86 USB'den Çalışan RAM Test Programı

RAM'lerinizi test etmek için kullanabileceğiniz en kapsamlı yazılım Memtest86'dır. Aracı USB belleğe yazmak için: Bu video rehberde Memtest86 ile belleklerinizi nasıl test edeceğinizi öğrenebilirsiniz: Adım adım: Öncelikle yazılımı buradan indirin. UEFI desteği olmayan eski sistemler...
www.technopat.net www.technopat.net

Kod: 
UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: ffffbe81d350b0b0
Arg3: 0000000000000000
Arg4: fffff8054e9d3094

Debugging Details:
------------------


KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.Sec
    Value: 5

    Key  : Analysis.DebugAnalysisProvider.CPP
    Value: Create: 8007007e on DESKTOP-NG9H4F5

    Key  : Analysis.DebugData
    Value: CreateObject

    Key  : Analysis.DebugModel
    Value: CreateObject

    Key  : Analysis.Elapsed.Sec
    Value: 34

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 69

    Key  : Analysis.System
    Value: CreateObject


ADDITIONAL_XML: 1

BUGCHECK_CODE:  7f

BUGCHECK_P1: 8

BUGCHECK_P2: ffffbe81d350b0b0

BUGCHECK_P3: 0

BUGCHECK_P4: fffff8054e9d3094

TRAP_FRAME:  ffffbe81d350b0b0 -- (.trap 0xffffbe81d350b0b0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=8670bcc134f80000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8054e9d3094 rsp=0000000000000000 rbp=0000000000000000
 r8=0000000000000000  r9=0000000000000000 r10=0000fffff8054e8d
r11=ffff810b0d908080 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!KiSystemServiceExit+0x274:
fffff805`4e9d3094 c3              ret
Resetting default scope

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  MsMpEng.exe

STACK_TEXT: 
ffffbe81`d350af68 fffff805`4e9d33e9 : 00000000`0000007f 00000000`00000008 ffffbe81`d350b0b0 00000000`00000000 : nt!KeBugCheckEx
ffffbe81`d350af70 fffff805`4e9ce245 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
ffffbe81`d350b0b0 fffff805`4e9d3094 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0x2c5
00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0x274


SYMBOL_NAME:  nt!KiDoubleFaultAbort+2c5

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

IMAGE_VERSION:  10.0.18362.657

STACK_COMMAND:  .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET:  2c5

FAILURE_BUCKET_ID:  0x7f_8_nt!KiDoubleFaultAbort

OS_VERSION:  10.0.18362.1

BUILDLAB_STR:  19h1_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {d1f8395a-8c58-45da-6ebf-e8bb4aad2fc5}

Followup:     MachineOwner
 
Artı 0 Eksi

Benzer konular

recep007
  • Soru
Ryzen 5 Pro 3400G sistemde mavi ekran
Mesaj
0
Görüntüleme
143
recep007
recep007
K
  • Soru
Ryzen 5 Pro 3400G mavi ekran hatası
Mesaj
1
Görüntüleme
279
wertyq
W
T
  • Soru
3400G sistemde mavi ekran hatası
Mesaj
1
Görüntüleme
73
Dümdüz
Dümdüz
E
  • Soru
Ryzen 5 Pro 3400G sistemde mavi ekran
2
Mesaj
10
Görüntüleme
580
Emre_2005
E
F
  • Soru
Ryzen 5 Pro 3400G PFN_LIST_CORRUPT mavi ekran hatası
Mesaj
3
Görüntüleme
470
Er73748
E

Yeni konular

Yeni mesajlar

Geri
Yukarı