Merhaba,
Sadece 1 dosya üzerinden 2 çıkarım yapacağım. Attığın dosyalar incelemesi bakımından normalden 1 tık daha zor sayılabilecek dosyalar.
Kod:
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000000, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000008, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff8056a13dd8c, address which referenced memory
Kod:
7: kd> k
# Child-SP RetAddr Call Site
00 ffff870b`1d8a6998 fffff805`6a02de69 nt!KeBugCheckEx
01 ffff870b`1d8a69a0 fffff805`6a029305 nt!KiBugCheckDispatch+0x69
02 ffff870b`1d8a6ae0 fffff805`6a13dd8c nt!KiPageFault+0x485
03 ffff870b`1d8a6c70 ffff870b`1d8a6e20 nt!HvlpAcquireHypercallPage+0xbc
04 ffff870b`1d8a6cc0 00000000`0000001f 0xffff870b`1d8a6e20
05 ffff870b`1d8a6cc8 00000000`00000000 0x1f
Sistem
nt!HvlpAcquireHypercallPage+0xbc çağrısında çökmüş olup AuthenticAMD.sys modülü başlığında oluşan bir dosya kaydetmiş. Bu, işlemciye işaret eden bir modül ve aynı şekilde Hyper-V mekanizmasındaki bir işleyiş anında oluşan çökmeye işaret eden bir çağrıya denk geliyor. Bu bağlamda ilk akla gelen ihtimalin de işlemci/sanallaştırma/anakart hatası olma durumu olması da normal. Şuna bakılıp sanallaştırma ve Hyper-V mekanizmalarını kapat denilebilir.Bunlar bu noktada çözüm içerikli öneriler sayılabilir. Şöyle devam edelim:
- Bu çağrı nedir?
- Daha farklı şekillerde ilişkilendirilebilecek bir çağrı olabilir mi?
nt!HvlpAcquireHypercallPage+0xbc işlevini, nt!Hvlp Acquire
Hypercall Page şeklinde bölebiliriz ki tam olarak anlamak için.
- Hvlp: Bu muhtemelen işlevin bağlamına özgü bir kısaltmaya denk geliyor.
- Acquire: Bu kısım, işlevin bir şeyi elde etmekten veya edinmekten sorumlu olduğunu gösteriyor.
- Hypercall: Bu kısım, işlevin sanallaştırılmış bir ortamda sanal makine ile hypervisior arasındaki iletişim için kullanılan özel işlev olduğunu gösteriyor.
- Page: Bu kısım, işlevin özellikle sayfalarla ilgili olduğunu gösterir; bu sayfalar, hipervizör bağlamında bellek sayfalarına veya diğer sayfa türleri de olabilir.
Buraya kadar en azından bir tık anlaşıldığını düşünüyorum. Şöyle ya da böyle demeden bu işlevin tam olarak neyi işarettiğini öğrenmek gerek. Öncelikle bu işlevden önceki belirsiz 2 adrese bakalım:
Kod:
7: kd> 0xffff870b`1d8a6e20
ffff870b`1d8a6d18 fffff805`6a1658da nt!KeBugCheck2+0xca
7: kd> 0x1f
ffff870b`1d8a6d18 fffff805`6a1658da nt!KeBugCheck2+0xca
Çok bir bilgi edinilmiyor açıkçası. 2 mavi ekran görüyorum sadece.
Bu unsurlar bir araya getirildiğinde, “HvlpAcquireHypercallPage” muhtemelen hiper yönetici kod tabanı içinde bir hiper çağrı sayfasının edinilmesinden veya elde edilmesinden sorumlu bir işlev veya komutu ifade eder. Bu işlev muhtemelen hiper çağrı sayfası için bellek ayırır ve konuk işletim sistemi ile hiper yönetici arasında hiper çağrı iletişimini kolaylaştırmak için gerekli veri yapılarını kurar.
Esasen bu işlev, sanallaştırılmış konuk işletim sistemi ile altta yatan hiper yönetici arasında iletişim ve etkileşim sağlanmasında çok önemli bir rol oynar ve konuk işletim sisteminin hiper çağrılar aracılığıyla hizmet talep etmesine veya ayrıcalıklı işlemler gerçekleştirmesine olanak tanır.
Bu unsurlar bir araya getirildiğinde, “nt!HvlpAcquireHypercallPage” çağrısından sonraki sistem çökmesini iki ihtimale bölebilirim:
“nt!HvlpAcquireHypercallPage - Bellek Ayırma Hatası Nedeniyle Sistem Çökmesi”
veya
“nt!HvlpAcquireHypercallPage -IRQL_NOT_LESS_OR_EQUAL”
Ya da TRAP yığını ve Hata açıklamasına göre NULL bir adresmiş.
2 ihtimale bölünen kısım burası da denebilir, İlkinden az buz bahsettim, ikinciye bakmak lazım:
Kod:
TRAP_FRAME: ffff870b1d8a6ae0 -- (.trap 0xffff870b1d8a6ae0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000baad5000 rbx=0000000000000000 rcx=ffffbf015bce3000
rdx=ffffbf015bce2000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8056a13dd8c rsp=ffff870b1d8a6c70 rbp=0000000000000001
r8=ffffbf015bce2000 r9=0000000000000008 r10=ffffbf015bcaa840
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
nt!HvlpAcquireHypercallPage+0xbc:
fffff805`6a13dd8c 488bf8 mov rdi,rax
Resetting default scope
Verdiğin dosyanın açıklamasında, ilk (Arg1) çökme sırasında başvurulan bellek adresini içerir. Bu durumda Arg1, 0x0000000000000000 adresindeki belleğe erişilmeye çalışıldığını gösteren 0000000000000000 değerini içeriyor.
Bu adres boştur, bu da bellek erişiminin boş veya geçersiz bir adrese yapılmaya çalışıldığını gösteriyor. Bu durum,
null işaretçinin derefer edilmesi, başlatılmamış belleğe erişim ya da ayrılmış veya serbest bırakılmış belleğe erişim gibi çeşitli nedenlerle ortaya çıkabilir tabii ki de.
Ancak, Arg1'de referans verilen null adresin, çökme anında komut tarafından erişilen adrese doğrudan karşılık gelmeyebileceğini unutmamak da lazım.
Bu komutun eriştiği çağrıya bakalım. nt!HvlpCompareActiveLpcbs imiş.
Kod:
7: kd> ln fffff8056a13dd8c
Browse module
Set bu breakpoint
(fffff805`6a13dcd0) nt!HvlpAcquireHypercallPage+0xbc | (fffff805`6a13def0) nt!HvlpCompareActiveLpcbs
Aslında sürekli sanallaştırma üzerinden yürüyor dosya. Yine de bir bellek kontrolü yapmanı isteyeceğim:
Sanallaştırmayı da kapat. Belleklerin temiz çıktığı bir durumda sanallaştırma kapalıyken sistem hala mavi ekrana düşüyorsa servise götürmek gerekebilir.