Çözüldü ASUS TUF A15 laptopta sürücü yüklerken mavi ekran hatası

Aldığın hata çok genel bir hata. Mavi ile işaretlediğim bilgiye bakarak Microsoft'un açıklaması dahilinde şunu söyleyebiliyoruz:

Bu hata için birkaç farklı sebep olabiliyor: LARGE PAGE olan bir belleğe başvurulmuş olabilir, null pointer kullanılmış olabilir veya geçerli ancak sayfalanmamış bir havuz adresi kullanılmış da olabilir ki bunların kendi içinde her zaman ayrı açıklamaları vardır.


Şimdi yeşil ile işaretlediğim ilk parametredeki PageFault'a neden olan adresi !pte komutunu kullanarak dökelim.


Gördüğün gibi, adres geçerli değil. (not valid) Bu da fiziksel bellekteki bir sayfayla eşleşmediği anlamına geliyor, bu nedenle bu adres için bir PageFault oluşturulmuş oluyor. Sistemin bunu çözebilmek için yeterli işleycisi varken neden bunu çözemediğini anlamaya çalıştım bu noktada. Bunun için ek olarak bu adresin pointer'ını döktüm.


Bu aslında ilgili belleğin freed bir bölgesine işaret ediyor. Bundan dolayı da sistemin işleyicileri tarafından bu geçersizlik durumunun çözülememesinin nedeni de bu oluyor. Buna kimin neden olduğunu da kırmızı ile işaretlediğim spn parametrede verilen adres ile ln komutunu kullanabiliyoruz.


Aslında burada karşımıza çıkan fonksiyon Windows'a ait bir sembol sunucusuna dahil olduğu için ln komutunu başarıyla çalıştırdı. İlk parametredeki adrese erişmeye çalışan NT API'sine dahil fonksiyon da bu'dur.

Bu fonksiyonlar Microsoft tarafından listelenmiyorlar ve ne oldukları hiçbir zaman açıklanmıyor çünkü Windows'un iç yapısında dahillerdir ama isminden gidersek ne olduğuna dair aşağı yukarı LFH yapısına dahil bir bellek ayırma işleminde eğer ki boşta bir blok yoksa bu fonksiyon devreye girerek boş blokları farklı bir veri yapısına (Kullanılmış olanlar örneğin.) taşıyarak bellek parçalanmasının önüne geçiyor gibi bir yorum yapabiliriz.


Yığının genel olarak LFH üzerinden ilerlediğini görebiliyoruz, kısaca LFH'nin de Segment Heap yapısında dahil bir Stack yönetimi mekanizması olduğunu söyleyebiliriz. Ve genel olarak da svchost.exe ve diğer sistem işlemleri gibi belirli işlemlerde kullanıldığını ekleyebiliriz.


Bizim bu noktada, ilk olarak, _SEGMENT_HEAP'te +0x340 ofsetinde olan ve _HEAP_LFH_CONTEXT'te 0x448 ofsetinde bir Bucket Tablosu saklayan bir anahtar olan _HEAP_LFH_CONTEXT'i anlamamız lazım. 0x448 ofsetindeki yapı, aşağıdaki yapısal ilişkilere sahip bir bucket tutuyor.


Farklı boyutlardaki Bucket Manager Pointer'ları bu BucketTable'da saklanıyor, aslında LFH en başta tahsis edilecek durumda değil. Daha sonra SegmentHeap yapısı incelenip doğrulandıktan sonra Nt!Rtlph... ile bu yapıyı başlatıyor.

Dosyada başladığını ve ilerleyişini görmüyoruz çünkü alt process'lerin hiçbir ntdll! yapısı minidump üzerinden tutulmuyor. Bundan dolayı elimizde olana direkt geçelim diyorum.

Bu konu hakkındaki elde edindiğim tüm bilgileri de aşağıdaki makaleden bulabilirsin. Devamına burdan ulaşabiliyorsun direkt olarak:



Senin yığınındaki nt!RtlpHpLfhOwnerCompact, nt!RtlpHpLfhOwnerRunMaintenance RtlpHpLfhOwnerFreeListProcess gibi işlevlerden de gördüğümüz gibi sistem belli bir bellek aralığında LFH kullanımı ile bir boşluk yaratmaya çalışıyor. Şöyle ki LFH etkinleştirildiğinde bir Bucket Manager oluşturuyor ve bu manager pointer da en başta bahsettiğim BucketTable'ın ilgili Boyut İndeksinin konumuna yerleştiriliyor ve o an çalışan process yığınının bloklarının tahsisini incelemek için ancak bu noktadan başlamamız gerekiyor ki bu imkansız.

Dosyada bir process yok, Olsa bile bu process benim sistemime dahil değil ki o bile olsa Bu process'in çalıştığı bellek aralıklarını bulmak için de benim kodlamam gerekirdi. Bu da nerdeyse 3 imkansız koyuyor önümüze ama yine de yapılarını inceleyebiliyoruz.

Bu manger _HEAP_LFH_BUCKET adlı yukarıda gösterdiğim yapı aslında, bu yapı da önemli bir üye değişken yapısı _HEAP_LFH_SUBSEGMENT_OWNER'ı içeriyor.


AvailableSubsegmentList Serbest durumda bulunan herhangi bir bloğun bucket listesini ve FullSubsegmentList de zaten dolu olan Bucket listesini ifade ediyorlar.

Bu iki liste her Bucket'ı depoluyorlar. Eğer ki LFH bir Bloğu tahsis ederse (Dosyada bu var.) Bucket Manager'daki AvailableSubsegementCount değerini kontrol ediyor, değeri 0'dan küçük veya 0'a eşitse, AvailableSubsegementList'i değerlendirmeye devam ediyor eğer ki AvailableSubsegmentList'te kullanılabilir bir liste yoksa değeri kendisine eşit oluyor. Buraya kadar anladığını düşünüyorum. Peki çöktüğümüz yer?

Dahası için de: https://github.com/k0keoyo/SegmentHeapExt/blob/master/segmentheap/segmentheap.cpp

Sisteminin çöktüğü nt!RtlpHpLfhOwnerMoveSubsegment fonksiyonu da bu yapıdaki bir bloğun boşaldığını tespit ederse bir alt segmenti (belirli bir boyuttaki blok grubu) bir listeden diğerine, örneğin bir FullSubsegmentList'ten AvailableSubsegmentList'e geri taşıyor. En başta kısaca söylediğim gibi.

Ek olarak basitçe anlatmak gerekiyorsa; Kovanın verecek hazır bellek bloğu yoksa, Windows: Önce “dolu” bir listeden bir tanesini geri dönüştürmeye çalışıyor (belki de artık gerçekten dolu değildir). Eğer yapamazsa, yeni bir tane yaratıyor. Bu fonksiyon bunu yapıyor.


En başta RAM sormamın sebebi de belkide bu yapıdaki bir bozukluğu bir RAM ya da spesifik olarak CPU hatası olarak yorumlamak istememdi. Şöyle ki hala bu olabilir ama fark ettiğim şey sistemin bu LFH biriminde bir error vermemesi oldu.

Ya gerçekten boş bir bellek alanına gitti bu yapıdaki işleyiş ya da bir sürücü gerçekten de işleyen bir dizinin sonunu veya bunu çevreleyen yapıdaki bağlantı pointer'larına bir şekilde zarar verdi. Veya bir object'i double free durumuna düşürdü.

Hatta başka bir ihtimal olarak sürücünün LIST_ENTRY yapısındaki bir şey heap yerine stack üzerinde ayrıldı ki bu olursa o an gönderilen fonksiyon geri döndüğünde sistem çökecektir.

Bunları tam detaylı anlamak bu dump üzerinden de imkansız. Bundan dolayı tek önerim eğer sistem tekrar mavi ekrana düşmediyse olduğu gibi kullanmaya devam etmen olacak. Tekrarlarsa sürücülerini kontrol etmekle başlayacağız.