Merhaba,
Aslında aklımda 1-2 sonuç oluşturup yazmak istedim. Aldığın
0X7F durdurma koduna sahip bir hata.
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: ffff800078f79e70
Arg3: ffffee87860b4fd0
Arg4: fffff8003ce89fb9
DOUBLE_FAULT içeriğe ait bir durdurma kodu olduğunu ve açıklamasında detaylandırıldığını görüyoruz. Çifte hata denilen bu arkadaşın ne olduğunu bilmek gerek. Bu bağlamda sadece 2 dosyanı inceleyerek bir sonuca gitmeye çalışacağız.
Double Fault diye adlandırılan şey sistemin halihazırda ilk hata için bir hata işleme sürecindeyken (Bu sende Vanguard oluyor) ikinci bir hata ile karşılaştığı bir durumu ifade ediyor. Kısaca, sistem başka bir hatayla başa çıkmaya çalışırken ortaya çıkan bir hatadır.
Tipik bir senaryoda, işlemcide bir hata (genel koruma hatası veya geçersiz bir işlem kodu gibi) oluştuğunda, işletim sisteminin çekirdeği bunu ele almak için müdahale eder. Ancak, çekirdek zaten ilk hatayı ele alırken başka bir hata meydana gelirse, bu bir çift hata durumuna yol açar. Bu durum sistemin çökmesine veya kararsız hale gelmesine neden olabilir çünkü işletim sisteminin böyle bir senaryodan güvenli bir şekilde kurtulma yolu yoktur.
Çift hatalar genellikle ciddi hatalar olarak kabul edilir ve donanım arızaları veya yazılım hataları gibi (Yani bu aslında karışık bir terim.) Hatalardan ortaya çıkabilir.
Yazılım hatalarından kasıt da şu olsa gerek ki:
İki dosya sistemi filtre sürücüsü aynı yığına bağlandığında ve dosya sistemi geri döndüğünde, her iki sürücünün de aynı dosya sistemi işlemini
özyineleme yaparak -yani tekrarlayarak. Aslında bu terimi matematikten biliyor olmak da gerek-. Olarak yakaladığını ve işlediğini gösteriyor. Bu özyinelemeli davranış, her özyinelemeli çağrı yeni bir yığın çerçevesi eklediğinden yığının bellek kullanımında aşamalı bir artışa yol açar. Ancak, yığının sınırlı bir boyutu olduğundan, bu sürekli büyüme sonunda mevcut yığın alanını tüketerek yığın taşmasına neden olur? Böyle bir durum, işletim sisteminin yığın çerçeveleri için ek bellek ayıramaması nedeniyle sistem kararsızlığına veya çökmelerine yol açarak potansiyel olarak veri bozulmasına veya kaybına neden olabilir? Bunun sonrası da bahsettiğimiz mavi ekrana denk geliyor.
Buraya kadar anladıysak ilk yığıta bakalım:
Kod:
0: kd> k
# Child-SP RetAddr Call Site
00 fffff800`49229d28 fffff800`4102d329 nt!KeBugCheckEx
01 fffff800`49229d30 fffff800`4102726f nt!KiBugCheckDispatch+0x69
02 fffff800`49229e70 fffff800`40e89fb9 nt!KiDoubleFaultAbort+0x32f
03 ffffaa00`850adfd0 fffff800`40e892f9 nt!MiGetPage+0x259
04 ffffaa00`850ae100 00000000`00000000 nt!MiGetPageChain+0x1f9
Unable to load image \??\C:\Program Files\Riot Vanguard\vgk.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for vgk.sys
05 ffffaa00`850b06e8 fffff800`410141c0 nt!ZwQuerySystemInformation
İlk hata olarak vanguard hatasını alıyorsun. Daha sonra sistem devam ediyor. Önce nt!MiGetPageChain+0x1f9 sonra da nt!MiGetPage+0x259 fonksiyonları ve sonra hata. Bu fonksiyonlardan sonra neden hata aldığını sorgulamak gerek bu noktada.
nt!MiGetPageChain+0x1f9 sistemin bellek havuzundan bir bellek sayfası zinciri elde etmekten sorumlu diyebiliriz. Bellek zinciri saçma bir açıklama oldu çünkü türkçesi bu. Bellek zinciri dediğimiz şey de
Bir işlem veya sistem bileşeni tek bir sayfanın sağlayabileceğinden daha büyük bir bellek bloğuna ihtiyaç duyduğunda, birden fazla bitişik bellek sayfasının birlikte tahsis edilmesini isteyebiliyor. Bu ardışık sayfalar bir “zincir” olarak adlandırdığımız bitişik bir bellek bloğunu oluşturuyor. Örnek olarak bir sürecin 16 KB belleğe ihtiyacı varsa, her biri 4 KB boyutunda dört ardışık bellek sayfasının bir zincir olarak tahsis edilmesini isteyebilir
Devam edelim; Bir işlem veya sistem bileşeni (Muhtemelen burda hala vanguard) tek bir sayfadan daha büyük bitişik bir bellek bloğuna ihtiyaç duyduğunda zincir dediğimiz fonksiyon kullanılabilir bellek havuzundan bir dizi ardışık bellek sayfası almak için çağrılıyor Bu sayfalar bir zincir oluşturarak isteği yerine getirmek için daha büyük bir bitişik bellek bloğu sağlıyor. İşlev, sayfa ayırma ilkelerini ele alma, bellek parçalanmasını ele alma ve diğer bellek yönetimi işlevleriyle koordinasyon dahil olmak üzere bellek kaynaklarının uygun şekilde yönetilmesini sağlar. Ayrıca, bellek tahsisinin başarısız olduğu durumları yönetmek için hata işleme mekanizmaları içerebilir ve sistem kararlılığını ve güvenilirliğini sağlar.
Aslında, sistem burda çökmüyor da hemen sonraki
nt!MiGetPage+0x259 fonksiyonunda çöküyor. Bu zaten tuzak yığınında belirtildiği için ordan devam edelim:
Kod:
TRAP_FRAME: fffff80049229e70 -- (.trap 0xfffff80049229e70)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=ffffc68000021790
rdx=0000000000000790 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80040e89fb9 rsp=ffffaa00850adfd0 rbp=00000000000000ff
r8=0000000000000002 r9=fffff80040c0ed18 r10=0000000000000079
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
nt!MiGetPage+0x259:
fffff800`40e89fb9 e8a27b1900 call nt!ExpInterlockedPopEntrySList (fffff800`41021b60)
Resetting default scope
Bu çağrı; memory manager dediğimiz birimin içinde ayrı bellek sayfaları tahsis etmekten sorumlu önemli bir işlev. Bir işlem veya sistem bileşeni veri depolamak için ek belleğe ihtiyaç duyduğunda,
nt!MiGetPage sistemin kullanılabilir bellek havuzundan tek bir bellek sayfası talep etmek için çağrılıyor. Bu bellek sayfaları genellikle 4 KB gibi sabit bir boyuta sahiptir ve sistem içinde bellek tahsisinin temel birimi olarak hizmet ediyorlar.
Çağrıldığında
nt!MiGetPage bellek ayırma isteğini yerine getirmek için birkaç görev gerçekleştirir. İlk olarak, tahsis kriterlerini karşılayan boş bir sayfa belirlemek için mevcut bellek havuzunu arar. > Uygun bir sayfa bulunursa, işlev bu sayfayı tahsis edilmiş olarak işaretler. > Dahili veri yapılarını tahsisi yansıtacak şekilde günceller ve tahsis edilen sayfanın işaretçisini talep eden işleme veya bileşene döndürür.
Ancak bellek havuzunda boş sayfa yoksa,
nt!MiGetPage işlevinin tahsis talebini karşılamak için ek adımlar atması gerekebilir. Bu, belleği diğer işlemlerden geri almak için bellek yönetimi ilkelerini ve algoritmalarını çağırmayı veya yeni tahsis için yer açmak üzere bellek sıkıştırma tekniklerini gerçekleştirmeyi içerebilir. Bu çabalar başarısız olursa, işlev yetersiz bellek nedeniyle tahsis isteğinin yerine getirilemediğini belirten bir hata döndürebilir.
Daha sonra görüyorsun "call nt!ExpInterlockedPopEntrySList (fffff800`41021b60)" fffff800`41021b60 adresindeki
nt!ExpInterlockedPopEntrySList işlevini çağırıyor. -Bu adresin az önce zincir bağlamında bahsettiğim içerikle alakalı olabilecek LARGE PAGE kıvamında olduğu da aşikar.-
Kod:
0: kd> !pte fffff800`41021b60
VA fffff80041021b60
PXE at FFFFF67B3D9ECF80 PPE at FFFFF67B3D9F0008 PDE at FFFFF67B3E001040 PTE at FFFFF67C00208108
contains 000000020E20B063 contains 000000020E221063 contains 0A00000117C001A1 contains 0000000000000000
pfn 20e20b ---DA--KWEV pfn 20e221 ---DA--KWEV pfn 117c00 -GL-A--KREV LARGE PAGE pfn 117c21
nt!ExpInterlockedPopEntrySList işlevi,
SList pop işleminin iş parçacığı güvenli bir uygulamasını sağlıyor olarak görünüyor ismen. Çok iş parçacıklı ortamlarda, bağlı listeler gibi paylaşılan veri yapılarına eş zamanlı olarak erişmek yarış koşullarına ve veri bozulmasına yol açabilir. Bu sorunları azaltmak için bu gibi çağrılar bir SList'ten öğeleri kaldırırken
atomikliği ve iş parçacığı güvenliğini sağlar. Donanım destekli atomik talimatlardan veya çekirdek senkronizasyon ilkellerinden yararlanan bu işlev, pop işleminin güvenli bir şekilde gerçekleştirilmesini, yarış koşullarının önlenmesini ve veri bütünlüğünün korunmasını garanti eder.
nt!ExpInterlockedPopEntrySList, çekirdekte bağlı listelere erişmek ve bunları değiştirmek için güvenilir ve verimli bir mekanizma sağlayarak, özellikle birden fazla iş parçacığı veya sistem bileşeni tarafından paylaşılan veri yapılarına eşzamanlı erişim içeren senaryolarda sisteminin kararlılığını ve güvenilirliğini sağlamada kritik bir rol oynuyor.
Kod:
+--------------------------------------+
| Windows Kernel |
| |
| +---------------------+ |
| | Memory Management | |
| | Subsystem | |
| +---------------------+ |
| | | |
| +---------+ +----------+ |
| | nt!MiGetPage | nt!ExpInterlockedPopEntrySList |
| +---------+ +----------+ |
| | | |
| +---------+ +----------+ |
| | Memory Pages | SList |
| +---------+ +----------+ |
| |
+--------------------------------------+
Şu şekilde şemalanabilir.
Bu kadar anlatımın sonunda bağlandığımız nokta: nt!MiGetPage adlı çağrımızın "LARGE PAGE" olarak işaretlenmiş bir adreste "nt!ExpInterlockedPopEntrySList" işlevini çağırması ve ardından sistemin çift hata ile çökmesi. "LARGE PAGE" kullanımı büyük olasılıkla bellek işleminin karmaşıklıklara veya potansiyel zorluklara yol açabilecek büyük bellek tahsislerinin işlenmesini içerdiğini gösterir. Çift hata ile çökme,
nt!ExpInterlockedPopEntrySList işlevinin yürütülmesi sırasında muhtemelen bana göre bellek bozulması gibi senkronizasyon sorunları veya kaynak çekişmesi nedeniyle kritik bir arıza olduğunu gösteriyor.
Bu noktada bir bellek testi ya da kontrolü iyi olabilir.
Bu dosyadaki farklı bir konumda BitLocker ile ilgili çağrıları da gördüm. Açıksa kapatmanı tavsiye ederim.
Bir de şu çağrılara bakalım:
Kod:
5: kd> k
# Child-SP RetAddr Call Site
00 ffffe301`453f9d28 fffff806`1182e269 nt!KeBugCheckEx
01 ffffe301`453f9d30 fffff806`11828040 nt!KiBugCheckDispatch+0x69
02 ffffe301`453f9e70 fffff806`1173dff0 nt!KiDoubleFaultAbort+0x340
03 fffff38c`00092000 fffff806`1173d656 nt!MiCoalesceFreePages+0x10
04 fffff38c`00092010 fffff806`11718cfb nt!MiInsertPageInFreeOrZeroedList+0x976
05 fffff38c`00092160 fffff806`11717daf nt!MiPfnShareCountIsZero+0xdb
06 fffff38c`000921d0 fffff806`117109e5 nt!MiDeleteValidSystemPage+0x23f
07 fffff38c`000922c0 fffff806`1175ae34 nt!MiTerminateWsleCluster+0x4e5
08 fffff38c`00092470 fffff806`1175a11c nt!MiDeleteSystemPagableVm+0x354
09 fffff38c`00092670 fffff806`11759fa2 nt!MmFreePoolMemory+0x148
0a fffff38c`00092700 fffff806`11759f42 nt!RtlpHpEnvFreeVA+0x12
0b fffff38c`00092730 fffff806`1164a1b6 nt!RtlpHpFreeVA+0x3a
0c fffff38c`00092780 fffff806`11649351 nt!RtlpHpSegMgrCommit+0x356
0d fffff38c`00092850 fffff806`11648a9b nt!RtlpHpSegPageRangeCommit+0x281
0e fffff38c`000928f0 fffff806`1169b149 nt!RtlpHpSegAlloc+0x17b
0f fffff38c`00092950 fffff806`1169b0fe nt!RtlpHpSegSubAllocate+0x3d
10 fffff38c`00092990 fffff806`11693d3a nt!RtlpHpSegVsAllocate+0x1e
11 fffff38c`000929d0 fffff806`116451e2 nt!RtlpHpVsSubsegmentCreate+0x8e
12 fffff38c`00092a30 fffff806`1164832e nt!RtlpHpVsContextAllocateInternal+0x352
13 fffff38c`00092aa0 fffff806`1172fafb nt!RtlpHpAllocateHeap+0x12e
14 fffff38c`00092b40 fffff806`1172f51f nt!ExAllocateHeapPool+0x5ab
15 fffff38c`00092c60 fffff806`11eac87d nt!ExpAllocatePoolWithTagFromNode+0x5f
16 fffff38c`00092cb0 fffff806`0d938f12 nt!ExAllocatePool2+0xdd
17 fffff38c`00092d60 fffff806`0d8cf33d CI!MincryptAlloc+0x1e
18 fffff38c`00092d90 fffff806`0d8d2bc8 CI!SymCryptCallbackAlloc+0x11
19 fffff38c`00092dc0 fffff806`0d989465 CI!SymCryptRsaPkcs1Verify+0xb0
1a fffff38c`00092e40 fffff806`0d935312 CI!HashpVerifyPkcs1Signature+0x225
1b fffff38c`00092ef0 00000000`00000000 CI!MinCryptVerifySignedHash2+0x1ba
Vanguard ile başlayıp öyle devam eden bir kernel havuz işlevi, ta ki sanal adresleri kaldırıp çökene kadar. Burda da Vanguard ve bu sanal adres kaldırma işlevleri iki hata olarak duruyorlar. Bu da bana göre hala bellek hatası olabilme ihtimalini gösteriyor.
Eki Görüntüle 39996
Bu bağlamda Windows temelli bir hata oluşu da 2.ihtimalde durabilir.
Sevgilerle.
