Son kullanma tarihi geçmiş, bayatlamış bir tarayıcı kullanıyorsanız, Mercedes kullanmak yerine tosbağaya binmek gibi... Web sitelerini düzgün görüntüleyemiyorsanız eh, bi' zahmet tarayıcınızı güncelleyiniz. Modern Web standartlarını karşılayan bir tarayıcı alternatifine göz atın.
Arkadaşlar yeni sistem topladım sorum şu sistem OCCT de test yapıyorum güç testini geçiyor CPU testide sıkıntı yok. Cinebench de sıkıntı yok. Fakat dün Blender benchmark açtım yaparken 2. testte PC kapandı mavi ekran verip. Unreal enginde shader renderlarken ve light buildlerken bazen yapıyor bazen kapanıyor. CLOCK_WATCHDOG_TIMEOUT (101) veriyor. Minidump baktım. İlk mavi ekran hatalarında ekran kartında sorun vardı onu garantiye yolladım onu zaten değiştirecektim gittim yeni kart aldım. Fakat sorun bu sefer farklı sebepten oluyor.
Sistem şu:
Kasa: NZXT H9 Elite(3 tane NZXT Duo + 3 tane SilverStone fan + 1 tane egzoz fan var. Hava akışı çok iyi.)
İşlemci soğutucu: DeepCool LT720 360mm.
PSU: FSP Hydro G PRO ATX3.0 (PCI-e5.0) 1000W 80Plus Gold.
64 GB RAM, 10-12 saat civarı sürer. Yukarıdaki videoda da zaten 64 GB RAM'in 11 saatte bittiği görünüyor. Memtest trial ile test edeceksen XMP tarzı hız aşırtma ayarlarını kapatıp kontrol et.
Rich (BB code):
CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 0000000000000006, Clock interrupt time out interval in nominal clock ticks. << İşlemcinin kesmelere yanıt vermediği tik süresi.
Arg2: 0000000000000000, 0.
Arg3: ffff9881575d1180, The PRCB address of the hung processor.
Arg4: 000000000000000e, The index of the hung processor. << Sorunun sebebi olan işlemci çekirdeği.
Aslında burda !prcb 0,1,2 diye tüm işlemci kontrol bloklarını kontrol edip arg3 adresini eşlememiz ve o işlemci kontrol bloğunun çökme anında ne yaptığına dair stack kısmındaki çağrıları kontrol etmemiz lazımdı. Zannımca dosya minidump olduğu için ve bu hata kontrolünün de (0x101) minidump dosyalarında incelenememesinden dolayı bu kodlar çalışmıyor.
Hata kontrolünü hazırlayan işlemcinin çağrı yığınına bakacak olursak :
İşlemci, önbelleğini temizliyor klasik bir işlem olarak ama bu sırada kesmelere yanıt vermeyerek mavi ekrana düşüyor.
12: kd> !thread
THREAD ffffd481c8cf6040 Cid 0004.0240 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor c
Not impersonating
GetUlongFromAddress: unable to read from fffff8050ba0be4c
Owning Process ffffd481c86f5040 Image: System
Attached Process N/A Image: N/A
fffff78000000000: Unable to get shared data
Wait Start TickCount 15323
Context Switch Count 11447 IdealProcessor: 12
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address nt!ExpWorkerThread (0xfffff8050b034e30)
Stack Init fffff3064985fbb0 Current fffff3064985f520
Base fffff30649860000 Limit fffff30649859000 Call 0000000000000000
Priority 13 BasePriority 13 PriorityDecrement 0 IoPriority 2
Bu noktada base ve limit adresleri bağlamında bir çağrı yığını oluşturup da bakabiliriz aslında ama ya ben adresleri karıştırdım ya da yanlış yazdım ya da programımdaki bir sorundan dolayı oluşturamadığım için bakamadım artık bilmiyorum ama yapamadım. Yapacak biri bakar ve bilgilendirirse iyi olur benim için de.
Rich (BB code):
12: kd> !irql
Debugger saved IRQL for processor 0xc -- 13
12: kd> r if
if=1
İşlemcinin IRQL değeri 13, x64 sistemler için normal bir sayı. Aynı şekilde bayrak kaydı da 1'e ayarlı. Bu da işlemcinin önüne gelen tüm kesmelere yanıt vereceği anlamına geliyor. Yani her şey çok normal gözüküyor.
Her şey çok normal gözükürken böyle bir hata kontrolü oluşmuşsa işlemcini kontrol etmeni öneririm.
Dipnot: Şimdi fark ettim, bu bayrak kaydı değerleri falan hata kontrolünü oluştan işlemci çekirdeği için normal değerler. IRQL seviyesi için bir şey diyemem ama asıl hatanın sebebi olan işlemci çekirdeğine bakmak istediğimde de hata verdi dosya. Bayrak kaydı orda 0 ise eğer işlemcinin her kesmeye yanıt vermeyeceği anlamına geliyor. Ama bilmiyorum.
64 GB RAM, 10-12 saat civarı sürer. Yukarıdaki videoda da zaten 64 GB RAM'in 11 saatte bittiği görünüyor. Memtest trial ile test edeceksen XMP tarzı hız aşırtma ayarlarını kapatıp kontrol et.
Rich (BB code):
CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 0000000000000006, Clock interrupt time out interval in nominal clock ticks. << İşlemcinin kesmelere yanıt vermediği tik süresi.
Arg2: 0000000000000000, 0.
Arg3: ffff9881575d1180, The PRCB address of the hung processor.
Arg4: 000000000000000e, The index of the hung processor. << Sorunun sebebi olan işlemci çekirdeği.
Aslında burda !prcb 0,1,2 diye tüm işlemci kontrol bloklarını kontrol edip arg3 adresini eşlememiz ve o işlemci kontrol bloğunun çökme anında ne yaptığına dair stack kısmındaki çağrıları kontrol etmemiz lazımdı. Zannımca dosya minidump olduğu için ve bu hata kontrolünün de (0x101) minidump dosyalarında incelenememesinden dolayı bu kodlar çalışmıyor.
Hata kontrolünü hazırlayan işlemcinin çağrı yığınına bakacak olursak :
İşlemci, önbelleğini temizliyor klasik bir işlem olarak ama bu sırada kesmelere yanıt vermeyerek mavi ekrana düşüyor.
12: kd> !thread
THREAD ffffd481c8cf6040 Cid 0004.0240 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor c
Not impersonating
GetUlongFromAddress: unable to read from fffff8050ba0be4c
Owning Process ffffd481c86f5040 Image: System
Attached Process N/A Image: N/A
fffff78000000000: Unable to get shared data
Wait Start TickCount 15323
Context Switch Count 11447 IdealProcessor: 12
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address nt!ExpWorkerThread (0xfffff8050b034e30)
Stack Init fffff3064985fbb0 Current fffff3064985f520
Base fffff30649860000 Limit fffff30649859000 Call 0000000000000000
Priority 13 BasePriority 13 PriorityDecrement 0 IoPriority 2
Bu noktada base ve limit adresleri bağlamında bir çağrı yığını oluşturup da bakabiliriz aslında ama ya ben adresleri karıştırdım ya da yanlış yazdım ya da programımdaki bir sorundan dolayı oluşturamadığım için bakamadım artık bilmiyorum ama yapamadım. Yapacak biri bakar ve bilgilendirirse iyi olur benim için de.
Rich (BB code):
12: kd> !irql
Debugger saved IRQL for processor 0xc -- 13
12: kd> r if
if=1
İşlemcinin IRQL değeri 13, x64 sistemler için normal bir sayı. Aynı şekilde bayrak kaydı da 1'e ayarlı. Bu da işlemcinin önüne gelen tüm kesmelere yanıt vereceği anlamına geliyor. Yani her şey çok normal gözüküyor.
Her şey çok normal gözükürken böyle bir hata kontrolü oluşmuşsa işlemcini kontrol etmeni öneririm.
Dipnot: Şimdi fark ettim, bu bayrak kaydı değerleri falan hata kontrolünü oluştan işlemci çekirdeği için normal değerler. IRQL seviyesi için bir şey diyemem ama asıl hatanın sebebi olan işlemci çekirdeğine bakmak istediğimde de hata verdi dosya. Bayrak kaydı orda 0 ise eğer işlemcinin her kesmeye yanıt vermeyeceği anlamına geliyor. Ama bilmiyorum.
64 GB RAM, 10-12 saat civarı sürer. Yukarıdaki videoda da zaten 64 GB RAM'in 11 saatte bittiği görünüyor. Memtest trial ile test edeceksen XMP tarzı hız aşırtma ayarlarını kapatıp kontrol et.
Rich (BB code):
CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 0000000000000006, Clock interrupt time out interval in nominal clock ticks. << İşlemcinin kesmelere yanıt vermediği tik süresi.
Arg2: 0000000000000000, 0.
Arg3: ffff9881575d1180, The PRCB address of the hung processor.
Arg4: 000000000000000e, The index of the hung processor. << Sorunun sebebi olan işlemci çekirdeği.
Aslında burda !prcb 0,1,2 diye tüm işlemci kontrol bloklarını kontrol edip arg3 adresini eşlememiz ve o işlemci kontrol bloğunun çökme anındaki stack kısmındaki çağrıları kontrol etmemiz lazımdı. Zannımca dosya minidump olduğu için ve bu hata kontrolünün de (0x101) minidump dosyalarında incelenememesinden dolayı bu kodlar çalışmıyor.
Hata kontrolünü hazırlayan işlemcinin çağrı yığınına bakacak olursak :
İşlemci, önbelleğini temizliyor klasik bir işlem olarak ama bu sırada kesmelere yanıt vermeyerek mavi ekrana düşüyor.
12: kd> !thread
THREAD ffffd481c8cf6040 Cid 0004.0240 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor c
Not impersonating
GetUlongFromAddress: unable to read from fffff8050ba0be4c
Owning Process ffffd481c86f5040 Image: System
Attached Process N/A Image: N/A
fffff78000000000: Unable to get shared data
Wait Start TickCount 15323
Context Switch Count 11447 IdealProcessor: 12
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address nt!ExpWorkerThread (0xfffff8050b034e30)
Stack Init fffff3064985fbb0 Current fffff3064985f520
Base fffff30649860000 Limit fffff30649859000 Call 0000000000000000
Priority 13 BasePriority 13 PriorityDecrement 0 IoPriority 2
Bu noktada base ve limit adresleri bağlamında bir çağrı yığını oluşturup da bakabiliriz aslında ama ya ben adresleri karıştırdım ya da yanlış yazdım ya da programımdaki bir sorundan dolayı oluşturamadığım için bakamadım artık bilmiyorum ama yapamadım. Yapacak biri bakar ve bilgilendirirse iyi olur benim için de.
Rich (BB code):
12: kd> !irql
Debugger saved IRQL for processor 0xc -- 13
12: kd> r if
if=1
İşlemci kesme sayısı 13, x64 sistemler için normal bir sayı. Aynı şekilde bayrak kaydı da 1'e ayarlı. Bu da işlemcinin önüne gelen tüm kesmelere yanıt vereceği anlamına geliyor. Yani her şey çok normal gözüküyor.
Her şey çok normal gözükürken böyle bir hata kontrolü oluşmuşsa işlemcini kontrol etmeni öneririm.
Dipnot: Şimdi fark ettim, bu bayrak kaydı değerleri falan hata kontrolünü oluştan işlemci çekirdeği için normal değerler. IRQL seviyesi için bir şey diyemem ama asıl hatanın sebebi olan işlemci çekirdeğine bakmak istediğimde de hata verdi dosya. Bayrak kaydı orda 0 ise eğer işlemcinin her kesmeye yanıt vermeyeceği anlamına geliyor. Ama bilmiyorum.
O tip bir durumda görüntü alamazsın bile ama yine de açıp kontrol edebilirsin, elinde bu sistemi açabilecek herhangi farklı bir işlemci varsa onu takıp kontrol etmeni öneririm.
Bu oluşan hata kodu, CLOCK_WATCHDOG_TIMEOUT (101) işlemci temelli bir hata kodudur ki eğer attığım mesajdaki ilk kırmızı ile işaretlediğim mesajı okursan:
This indicates that the specified processor is hung and not processing interrupts. // işlemci askıda ve kesmeleri işlemiyor.
Bu hata kontrolü işlemci temelli oluşuyor kısaca. %100 donanımsal mı dersen değil.
O tip bir durumda görüntü alamazsın bile ama yine de açıp kontrol edebilirsin, elinde bu sistemi açabilecek herhangi farklı bir işlemci varsa onu takıp kontrol etmeni öneririm.
Bu oluşan hata kodu, CLOCK_WATCHDOG_TIMEOUT (101) işlemci temelli bir hata kodudur ki eğer attığım mesajdaki ilk kırmızı ile işaretlediğim mesajı okursan:
This indicates that the specified processor is hung and not processing interrupts. // işlemci askıda ve kesmeleri işlemiyor.
Bu hata kontrolü işlemci temelli oluşuyor kısaca. %100 donanımsal mı dersen değil.
Aynı işlemciden bir tane daha var. Eşimle aynı sistemi topladık onun ki tıkırtıkır çalışıyor hiç hata almadı benim ki yük altında BSOD atıyor. Anlamadım gitti. Hep bana oluyor zaten. Farklı sistemde şu yüzden deneyemem aslında termal macunum yok. Bitti de. Alıcam ondan sonra deneyebilirim.
Üstün Performanslı Kryonaut Extreme Üstün Performanslı Kryonaut Extreme Termal Macun Kryonaut Extreme, çok sevilen Kryonaut termal macun temel alınarak geliştirilen ve ekstrem soğutma uygulamaları için muazzam bir termal macundur. Kryonaut Extreme, maksimum ısı iletimi performansı için...
www.teknobiyotik.com
Şundan alacaktım da test için kullansam pahalıya patlar sanırım. İdareten ne alabilirim? Nasıl test edebilirim başka CPU hatası olması RAM ile bağlantısı olamaz mı demek?
@181951 Intel Processor Diagnostic Tool ile test yaptım fakat hiç sorunsuz geçti. Bazı stress testinde çöküyor bazısı sıkıntısız geçiyor. Elektrik ile alakalı olabilir mi? Uzatma kablosu yetersiz gelip bir anlık güç kaybı yaşayıp yada PSU besleyemeyip kapanma ihtimali var mı? Eşimin PC ile benimki arasındaki tek fark uzatma kabloları ve kullandığımız prizler.
Undan alacaktım da test için kullansam pahalıya patlar sanırım. İdareten ne alabilirim? Nasıl test edebilirim başka CPU hatası olması RAM ile bağlantısı olamaz mı demek?
Bu test sırasında işlemci çok ısınacaktır, HWiNFO ile de eş zamanlı sıcaklık kontrolü yapın. 30 dakika ya da 1 saat arasında açık tutmaya çalışın sistem bu süre zarfı dolmadan kilitlenmeler veya kapanmalar ya da mavi ekrana atmalar yaşamazsa tabii ki.
Large ayarda da test edebilirsin, RAM'i de sınamış olursun.
@181951 Intel Processor Diagnostic Tool ile test yaptım fakat hiç sorunsuz geçti. Bazı stress testinde çöküyor bazısı sıkıntısız geçiyor. Elektrik ile alakalı olabilir mi? Uzatma kablosu yetersiz gelip bir anlık güç kaybı yaşayıp ya da PSU besleyemeyip kapanma ihtimali var mı? Eşimin PC ile benimki arasındaki tek fark uzatma kabloları ve kullandığımız prizler.
Hangisinde çöküyor? O önemli. Elektrik, PSU tarafından beslenmeme durumu varsa ve eğer dediğiniz gibi PSU yetersiz kalıyorsa sistemin yük altında direkt kapanması gibi sorunları da en azından yaşamış olmanız lazım. Yaşadınız mı?
Bu test sırasında işlemci çok ısınacaktır, HWiNFO ile de eş zamanlı sıcaklık kontrolü yapın. 30 dakika ya da 1 saat arasında açık tutmaya çalışın sistem bu süre zarfı dolmadan kilitlenmeler veya kapanmalar ya da mavi ekrana atmalar yaşamazsa tabii ki.
Large ayarda da test edebilirsin, RAM'i de sınamış olursun.
Bu test sırasında işlemci çok ısınacaktır, HWiNFO ile de eş zamanlı sıcaklık kontrolü yapın. 30 dakika ya da 1 saat arasında açık tutmaya çalışın sistem bu süre zarfı dolmadan kilitlenmeler veya kapanmalar ya da mavi ekrana atmalar yaşamazsa tabii ki.
Large ayarda da test edebilirsin, RAM'i de sınamış olursun.
Hangisinde çöküyor? O önemli. Elektrik, PSU tarafından beslenmeme durumu varsa ve eğer dediğiniz gibi PSU yetersiz kalıyorsa sistemin yük altında direkt kapanması gibi sorunları da en azından yaşamış olmanız lazım. Yaşadınız mı?
Sıcaklık, ki eğer sadece stres testi özelinde bu durumlara geliyorsa ve normal şartlarda yahut oyunlarda normalse endişelenecek bir şey yok. Sıcaklığın direkt olarak sebep olduğu bir mavi ekran olamaz.
Sıcaklık, ki eğer sadece stres testi özelinde bu durumlara geliyorsa ve normal şartlarda yahut oyunlarda normalse endişelenecek bir şey yok. Sıcaklığın direkt olarak sebep olduğu bir mavi ekran olamaz.
drive.google.com
