Dediğim gibi bu küçük dökümler herhangi bir bilgi içermezler. Çok nadir de olsa ilgili repolarla alakalı bilgi tuttuklarından ve user klasörünün sahipliğinden dolayı kişisel isminizi ya da belirlediğiniz ismi görme şansımız oluyor ama o durumlarda ben de çok paylaşan biri değilim. İlla paylaşmam gerekiyorsa da ismi sansürleyip atıyorum. Bugünlerde bir tık yoğun olduğum için dump dosyalarını forum ahalisine bırakmıştım ama kimse görmemiş olsa gerek ki yine kısa bir bakınmam gerekti. Kısa diyorum çünkü uzun uzun anlatamam ve zaten dosyalar da uzun uzun bir şeyleri anlatmaya müsaade edecek dosyalar değiller.
Verdiğin dosyalara baktım, anlattıklarına baktım. Bir tık kafam karıştı. "güvenli modda sorunsuz çalışıyor." gibi bir beyanın var ama aynı zamanda sistemin günlük kullanımda da 5-6 saate kadar normal çalıştığını fark etmişsin. Güvenli modda sıkıntısız çalışıyor cümlesini güvenli modda 5-6 saati geçkin süreler kullanarak mı söylüyorsun?
Tüm dosyalar sistem işlevlerinde non-canonical bellek erişiminden dolayı çökme meydana gelmesinden ortaya çıkıyor neredeyse. 1 dosyan farklı ama o da çok iç açıcı olmasa gerek ki ilgili stack pointer corrupt durumu ve iş parçacığı değiştirme eylemlerini barındırıyor. Swapthread işine 1-2 farklı dosyanda daha denk geldim. Normal şartlarda buna donanımsal hata demek gerekebilir belki de. Bu kişisel bir ifadedir.
Dökümlerinde genelde hem NTFS hem de fltmgr çağrılmasına rağmen, görünen bi' üçüncü taraf sürücü göremedim. Yok da. Bu, kullanıcı kısmına dayanan ya da filtre sürücüleri olarak yüklenmiş bazı üçüncü taraf sürücülerin olduğunu gösteriyor da olabilir.
Random bir dökümden seçtim, NTFS'ya da fltmgr ile ilgili çağrılar atılmasına rağmen ardından stackqueuedspinlock çağrısı geliyor -ki bu daha çok 3.taraf geliştiriciler için oluşturulan bir spinlock türüdür- daha sonra ise sorun bir Windows işlevinde ortaya çıkıyor ve non-canoncial bir bellek adresine (yani geçerli X64 adres alanında olmayan bir adrese) başvurma işi var.
Bu adres Rdx'e bağlıdır ve eğer bu geçersiz Pointer'ı buraya yerleştiren üçüncü taraf bir sürücü değilse o zaman bu bir donanım (one_bit) sorunu olabilir düşüncesini çağrıştırıyor. Bu adresin ikili değerine bakarsak...
Kod:
CONTEXT: ffffc9816a6d9920 -- (.cxr 0xffffc9816a6d9920)
rax=0000000000000000 rbx=ffffdb8a8c7e8e50 rcx=ffffdb8a8c7e8e50
rdx=0120000000000000 rsi=ffffdc8fab53c100 rdi=ffffdc8fab53c608
rip=fffff800342572ce rsp=ffffdb8a8c7e8dc0 rbp=ffffdc8fb744c080
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=ffffdb8a8c7e8c40 r12=0000000000000000 r13=fffff80037354000
r14=0000000000000001 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc.
cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00010286
nt!KxWaitForLockOwnerShip+0xe:
fffff800`342572ce 48890a mov qword ptr [rdx],rcx ds:002b:01200000`00000000=????????????????
Resetting default scope.
One_bıt normal şartlarda RAM proble midir ama bunun böyle olduğuna tam emin değilim. İlgili Pointer'ı bozan 3.taraf bir sürücü olup olmadığından emin olmak gerek ama bu dosyalarla mümkün değil.
Eki Görüntüle 69065
Sürücü doğrulayıcı açıkçası işimize yarardı bu durumda...