Aldığın hatalardan biriyle alakalı gerçekten söylenebilecek şeyler çok kısıtlı. Neyse ki 1 tanesinde hatayı kaydetmiş diyelim.
Rich (BB code):
KERNEL_THREAD_PRIORITY_FLOOR_VIOLATION (157)
An illegal operation was attempted on the priority floor of a particular
thread.
Arguments:
Arg1: ffffe38604631040, The address of the thread
Arg2: 00000000000a0020, The target priority value
Arg3: 0000000000000002, The priority counter for the target priority underflowed
Arg4: 0000000000000000, Reserved
Şimdi, Bu hata ile ilgili olarak Windows 10/11'in kendi uzak bağlantı özelliklerini saymazsak genel olarak sunucu tabanlı OS'larda oluştuğunu belirtmem gerekiyor. Sunucu bilgisayarında mı bu hatayı alıyorsunuz acaba?
Rich (BB code):
Windows 10 Kernel Version 26100 MP (12 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Kernel base = 0xfffff804`f0800000 PsLoadedModuleList = 0xfffff804`f16f4aa0
Debug session time: Mon Jun 23 15:57:37.317 2025 (UTC + 3:00)
System Uptime: 0 days 0:04:10.142
Sistem TS olarak görünüyor. Kullanıcı istemi olarak değil.
Bu hata hakkında da işlem
zamanlayıcının belirli bir iş parçacığının öncelik düzeyini düzgün bir şekilde işlemediğiyle ilgili olması dışında özellikle söylenecek çok bir şey de yok.
Bu hatayı da ancak üç farklı durum tetikleyebilir: priority floor sayısı ya alt tabandan düşük bir değere düşmüştür, ya üst tabandan yüksek bir değere çıkmıştır ya da bu sayı geçersizdir.
Rich (BB code):
0: kd> dt _KTHREAD -y Priority ffffe38604631040
nt!_KTHREAD
+0x0c3 Priority : 12 ''
+0x206 PriorityDecrement : 0n0
+0x338 PriorityFloorCounts : [32] ""
+0x358 PriorityFloorSummary : 0
Buradaki her şeyin tam olarak neye karşılık geldiği hakkında bir bilgim yok ancak ilgili priority dizisinin 0 ile 31 arasında değişen kullanılabilir öncelik düzeylerinin sayısı ile tam olarak aynı uzunlukta olduğu dikkatimi çekiyor.
Rich (BB code):
0: kd> k
# Child-SP RetAddr Call Site
00 fffff804`833ff5a8 fffff804`f0b3fcc0 nt!KeBugCheckEx
01 fffff804`833ff5b0 fffff804`f0b3ed14 nt!KiAdjustRealtimePriorityFloor+0x4c // çökme
02 fffff804`833ff5f0 fffff804`f0a2e153 nt!KiWakePriQueueWaiter+0x134
03 fffff804`833ff650 fffff804`96b1eb4d nt!ExQueueWorkItem+0x2d3 // Zamanlayıcı bir iş parçacığı kuyruğu ekliyor
04 fffff804`833ff6d0 fffff804`f0b96fa2 dxgmms2!VidMmRangeCurationDpc+0x2d // DirectX birimine ait bellek aralığı düzenleme zamanlayıcısı çağrılıyor
05 fffff804`833ff700 fffff804`f0b97885 nt!KiProcessExpiredTimerList+0x502
06 fffff804`833ff830 fffff804`f0ae6a86 nt!KiTimerExpiration+0x2b5
07 fffff804`833ff970 fffff804`f0ea563e nt!KiRetireDpcList+0xc46 // DPC kuyruğunu başlatır, işlemciyi uyandırır
08 fffff804`833ffc00 00000000`00000000 nt!KiIdleLoop+0x9e // Sistem boşta, işlemci boşta
Çağrı yığınını incelersek,
DirectX sürücüsünün bir DPC zamanlayıcı işleminde ExQueueWorkItem ile bir işi kuyruklamak isterken bu iş kuyruktaki başka bir thread’i uyandırmak zorunda kaldığını görüyoruz (Ne olduğu bu dosyada belli değil.) Uyandırılacak thread’in öncelik zeminini güncellemesi gerekirken muhtemelen çökme sırasında da gördüğümüz gibi priority değerinde yukarıda bahsettiğim 3 ihtimalden biri ortaya çıkıyor ve sistem mavi ekranla duruyor. Sorun ekran kartı alt biriminde ortaya çıkıyor.
Bu noktada çalışan işlemin değerlerini de kontrol edebiliriz ayrıca.
Rich (BB code):
0: kd> dt _EPROCESS -y Priority ffffe385f04b0040
nt!_EPROCESS
+0x347 PriorityClass : 0x2 ''
Gördüğün gibi, işlem NORMAL_PRIORITY_CLASS ayarına sahip ve iş parçacığı da 12 öncelik seviyesine sahip. bu nedenle temel öncelik seviyesinin 12 olduğu sonucuna varabiliyoruz. Yani bizim bu noktada düşebileceğimiz tek nokta 12. Altı overflow'a girecektir.
Rich (BB code):
0: kd> dt _KTHREAD -y Base ffffe38604631040
nt!_KTHREAD
+0x233 BasePriority : 12 ''
Bunu aynı şekilde Microsoft'un
ilgili makalesinde de görebiliyoruz...
Base Priority
The process priority class and thread priority level are combined to form the base priority of each thread.
| ABOVE_NORMAL_PRIORITY_CLASS | THREAD_PRIORITY_IDLE | 1 |
| THREAD_PRIORITY_LOWEST | 8 |
| THREAD_PRIORITY_BELOW_NORMAL | 9 |
| THREAD_PRIORITY_NORMAL | 10 |
| THREAD_PRIORITY_ABOVE_NORMAL | 11 |
| THREAD_PRIORITY_HIGHEST | 12 |
| THREAD_PRIORITY_TIME_CRITICAL | 15 |
Şöyle bir ihtimal düşünübiliyorum sadece toplamdan çıkardığım sonuç ile:
Ekran kartı sürücüsünde bu ilerleyiş saçma bir programatik ile
SetThreadPriority()'i çağırıyor ve çok yüksek bir değerden iş parçacığına giriyor. Zaten halihazırda sistem boştayken çalışan DPC işlemleri için bu kadar büyük bir öncelik durumuna ihtiyaç duyulduğunu sanmıyorum. Bu dosya sistem boştayken oluyor ve yapılan işlemde belli bellek aralıklarını düzenleme işlemi.
Sonrasında kuyruğa eklediği
WorkItem ile çalışan İP başka bir İP'i uyandırıyor. Uyandırılan İP'in önceliği bu kadar yüksek olmadığı için çökme sırasında muhtemelen bu öncelik değeri 12'den daha düşük bir değere indirilmeye çalışılıyor ve sistem çöküyor. Bunda ben sürücü sorunu olduğunu varsayıyorum....
Rich (BB code):
0: kd> lmDvmnvlddmkm
Browse full module list
start end module name
fffff804`8f9e0000 fffff804`96651000 nvlddmkm (deferred)
Image path: nvlddmkm.sys
Image name: nvlddmkm.sys
Browse all global symbols functions data
Timestamp: Thu Jun 12 03:49:31 2025 (684A241B)
CheckSum: 06A840AA
ImageSize: 06C71000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:
Ekran kartı sürücün güncel gözüküyor. Bu hata ne süredir yaşanıyor?
Bir diğer hatan da
Rich (BB code):
MEMORY_MANAGEMENT (1a)
# Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000061941, // Çökmüş PTE tablosu.
Arg2: 000002882e1f8000
Arg3: 000000000000000d
Arg4: ffffe1028cebfaa0 // TRAP.
Hatası. Bu hata ile ilgili söyleyebileceğim çok bir şey yok çünkü tüm dosya bozuk halde. Bunu bir donanım hatasına yorabilirim ama.
Rich (BB code):
0: kd> .trap ffffe1028cebfaa0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000288df551000 rbx=0000000000000000 rcx=0000000000018000
rdx=000002882e1f0000 rsi=0000000000000000 rdi=0000000000000000
rip=00007ff9c4e112db rsp=000000c0ab61f7d8 rbp=0000000000000000
r8=0000000000020000 r9=000002882e210000 r10=00007ff9c4e10000
r11=ffffffffffffffff r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
0033:00007ff9`c4e112db ?? ???
İlgili hata sabit olarak aşağıdaki gibidir...
Rich (BB code):
FAILURE_BUCKET_ID: 0x1a_61941_PAGE_TABLE_RESERVED_BITS_SET_IMAGE_hardware_ram
Bu, sistemin RAM'de geçersiz bir sayfa tablosu girişi tespit ettiği anlamına geliyor. Buna hem gerçekten hardware_ram ile belirtildiği gibi RAM, ya da gerçekten bu yapıyı bozabilecek bir sürücü de sebep olabiliyor.
Öncelik olarak sürücü doğrulayıcı çalıştırıp sistemi kontrol etmeni istiyorum. Eğer direkt olarak hata vermezse 48 saat arkada açık halde kullanın bilgisayarı.
Driver Verifier aracı, Windows 2000'den bu yana her Windows sürümüne dahil edilen ve sistem bozulmasına, arızalara veya diğer öngörülemeyen davranışlara neden olan birçok sürücü sorununu tespit etmek ve gidermek için kullanılan bir araçtır. Bu konuda, sistemdeki bir sürücüyü tespit etmek ve sorunlarını gidermek için Sürücü Doğrulayıcı'nın nasıl kullanılacağını anlatmaya çalışacağım.
Başlamadan önce; Verifier kullanımı öncesi sistem yedeği almanız, Geri yükleme noktası oluşturmanız elzem bir konudur. Zira konunun ilerisinde kısa olarak değindiğim boot sırasında sürekli mavi ekran stuck...
Bu süre zarfında hata yaşarsanız ve doğrulayıcı hatalarından bağımsız olursa RAM'leri tek tek kullanmanı isteyeceğim.
