Vanguard sülüğünden kurtulduktan sonra rahat nefes aldıran bir dosyaya benziyor.
Rich (BB code):
CRITICAL_PROCESS_DIED (ef)
A critical system process died
Arguments:
Arg1: ffffe68afd79c140, Process object or thread object
Arg2: 0000000000000000, If this is 0, a process died. If this is 1, a thread died.
Arg3: ffffe68afd79c140, The process object that initiated the termination.
Arg4: 0000000000000000
0xEF hatası 3 sebepten olur, ya kötü bir RAM - Disk ya kötü bir Antivirüs programı ya da Windows'un kendisi.
Bu dosyada gölge yığınının uygulanması ve Shadow Stack ile çağrı yığını arasında bir tutarsızlık tespit edilmesi durumunda Windows'un çalışan süreci nasıl sonlandıracağı ve Stop 0xEF hata kontrolüne nasıl yol açacağı olan üçüncü nedene odaklanacağım. Bu nedenle, kötü programlanmış bir sürücü veya RAM'den kaynaklanma olasılığı daha yüksek olsa da, bunun nedeninin Windows'un kendisi de olabilir hala.
Donanım tabanlı yığın korumasında, işlemci yığının iki kopyasını tutacak ve ikincil kopya shadow stack olarak bilinecek oluyor. Bu yığın, çalışan iş parçacığının kontrol akışı için tasarlanmıştır ve yığınlardan herhangi birindeki dönüş adresleri arasında bir uyumsuzluk varsa, işlemin Windows tarafından sonlandırılmasına neden olan özel bir donanım istisnası atılıyor...
Daha fazlası için :
Developer Guidance for Hardware-enforced Stack Protection | Microsoft Community Hub
Rich (BB code):
12: kd> k
# Child-SP RetAddr Call Site
00 ffff948f`d2b56c28 fffff802`c2353700 nt!KeBugCheckEx
01 ffff948f`d2b56c30 fffff802`c2554aef nt!PspCatchCriticalBreak+0x128
02 ffff948f`d2b56cd0 fffff802`c2554487 nt!PspTerminateAllThreads+0x27b
03 ffff948f`d2b56d50 fffff802`c2552461 nt!PspTerminateProcess+0xf7
04 ffff948f`d2b56d90 fffff802`c228c555 nt!NtTerminateProcess+0xd1 << services.exe işlemini sonlandır ve sistemi mavi ekrana geçir
05 ffff948f`d2b56e10 fffff802`c227a9b0 nt!KiSystemServiceCopyEnd+0x25
06 ffff948f`d2b56fa8 fffff802`c1f9c324 nt!KiServiceLinkage
07 ffff948f`d2b56fb0 fffff802`c228d506 nt!KiDispatchException+0xcc4 << İstisna sırası
08 ffff948f`d2b57840 fffff802`c228aa1f nt!KiFastFailDispatch+0xc6 << 0xc0000409 istisna kodu
09 ffff948f`d2b57a20 00007ff6`3aa01944 nt!KiControlProtectionFault+0x3df << Kontrol Koruması istisnası atıyor
0a 00000026`3b97eab8 00000000`00000000 0x00007ff6`3aa01944
Rich (BB code):
12: kd> .exr ffff948fd2b57978
ExceptionAddress: 00007ff63aa01944
ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
ExceptionFlags: 00000001
NumberParameters: 3
Parameter[0]: 0000000000000039
Parameter[1]: 000000263b9fef80
Parameter[2]: 0000000040024000
Subcode: 0x39 FAST_FAIL_CONTROL_INVALID_RETURN_ADDRESS Shadow stack violation
CET etkinleştirildiğinde veya bir çağrı komutu yürütüldüğünde, iki dönüş adresi olur: biri çağrı yığınına ve diğeri shadow stack'e. Bu iki dönüş adresi daha sonra ret komutu yürütüldüğünde karşılaştırılır, ikisi arasında bir uyumsuzluk varsa, daha önce belirttiğim gibi CP istisnası atılıyor. Bununla birlikte, CET'in yalnızca çağrı talimatlarıyla çalışacağını belirtmem gerekiyor. Ancak bir push talimatı kullanarak bir dönüş adresini yığına iterken, dönüş adresi shadow stack üzerinde bulunmayacağından CET'e uyulmayacak bu durumda. Bunu akılda tutarak, bunun yerine CFG korumalı jmp talimatlarının kullanılması öneriliyor. CFG benzer şekilde davranacaktır, bir ihlal bulunursa, ihlal eden süreç sonlandırılır. Eğer bu “kritik” bir süreçse o zaman 0xEF ile mavi ekrana düşersin senin durumundaki gibi.
Learn more about: /CETCOMPAT (CET Shadow Stack compatible)
learn.microsoft.com
Bu noktada senden bu işin sonunda kesinlike sıfırdan Windows kurmanı önerecektim ama bunu zaten galiba yapmış olmalısın. SSD değişiminde. RAM'lerini tek tek takıp sistemi kontrol etmeyi denedin mi?
