Çözüldü Monster Laptop CRITICAL_STRUCTURE_CORRUPTION (109) hatası

bicy dedi:

Bugcheck kodları KP41 hatalarında decimal olarak kaydediliyorlar. Decimal > Hex dönüşümü yaparak gerçek mavi ekran koduna ulaşabiliyorsun. Bu durumda 265 > 109.

https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x109---critical-structure-corruption

Bu mavi ekran koduyla alakalı minidump ile çok bilgi edinme şansımız da yok ve açıkçası her zaman göründüğü gibi de olmayabiliyor.

Rich (BB code):

CRITICAL_STRUCTURE_CORRUPTION (109)
This BugCheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
 or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
 debugger that was not attached when the system was booted. Normal breakpoints,
 "bp", can only be set if the debugger is attached at boot time. Hardware
 breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a39fc4d94a78b594, Reserved
Arg2: b3b6d15f9cf6fe4c, Reserved
Arg3: fffff802103a2214, Failure type dependent information
Arg4: 0000000000000001, Type of corrupted region, can be

Şimdi mantık basitçe temelinde Windows çekirdeğinin (nt) kritik çekirdek kodu veya veri bozulması tespit etmesi. Tespit ettiği hatayı da 4.parametreye iliştirip dökümü oluşturuyor...

Bu da 1. 1, bozuk bölge türünün bir işlev veya pdata yapısında bir değişiklik olması... Yani açıkçası dediğim gibi bir bilgi vermiyor çünkü tüm havuzlar bozuk dosyadaki. Bir stack de yok, elimizde 1 fonksiyon var sadece.

Rich (BB code):

SYMBOL_NAME:  nt!MdlInvariantPostDriverCompletion+8f

MODULE_NAME: nt

Sorun şu ki bu fonksiyon da belgelenmemiş genel hata gibi. İsim varsayımı yaparak en azından MDL yapısına dahil bir post processing olduğuyla alakalı bir yorum üzerinden ilerleme şansımız olabiliyor.

MDL yapısını daha detaylı anlaman için aşağıya kaynak bırakıyorum...

https://www.osronline.com/article.cfm%5eid=423.htm

Şimdi konuyla ilgili olarak, olarak fiziksel ve gerçek belleğin dağınık yapıya sahip olmasından dolayı MDL’lerin amacının esas olarak (I/O) işlemleri için kullanılmak olduğunu söyleyebiliyoruz. Sanal bellek veri buffer'ı, fiziksel adres aralığına karşı kilitlendiğinde, MDL bu tampon ile fiziksel adres aralığı arasındaki eşleşmeyi ve ilişkiyi tanımlıyor kısaca.

Bu tür bir kilitlenme de Direct IO olarak isimleniyor. Yani IRP yapısının sistem buffer'larına ihtiyaç duymadan iletilmesini sağlıyor. Normal şartlarda sistem istekleri bu buffer'larda toplayıp toplu belleğe yazıp performans artısı sağlıyor... Direct I/O kullanıldığında, programın kullanıcı modundaki sanal adres buffer'ı (0x0000) fiziksel belleğe kilitleniyor ve bu sayede sanal bellek buffer'ı non-paged hale geliyor, kısaca disk'e yazılmıyor, sadece RAM'de tutulmuş oluyor, sürücünüm ilgili programın tüm verisine hızlıca erişimini sağlıyor ve bunları yaparken sistem çökmelerinin de önüne geçiyor zira o an bu bellek sayfalanabilir olup da diskte olursa birden fazla işlemci istisnası fırlama şansı olabiliyor. Daha sonra IRP, ilgili DO ve IRP yığınındaki sürücü DO üzerinden işlenmeyi tamamladıktan sonra, nt!iO... sanal bellek tamponunun kilidini kaldırıyor ve ardından MDL’yi serbest bırakıp ve bellekten temizliyor.

Bunu kısaca anlatma sebebim hatayla ilgili olarak bir ihtimal sürücülerin MDL’leri birden çok kez kilitleyip açtığı durumlarda sorunlar ve mavi ekran hataları yaratma şansı olması.

Rich (BB code):

3: kd> dt nt_IRP
*************************************************************************
***                                                                   ***
***                                                                   ***
***    Either you specified an unqualified symbol, or your debugger   ***
***    doesn't have full symbol information.  Unqualified symbol      ***
***    resolution is turned off by default. Please either specify a   ***
***    fully qualified symbol module!symbolname, or enable resolution ***
***    of unqualified symbols by typing ".symopt- 100". Note that     ***
***    enabling unqualified symbol resolution with network symbol     ***
***    server shares in the symbol path may cause the debugger to     ***
***    appear to hang for long periods of time when an incorrect      ***
***    symbol name is typed or the network symbol server is down.     ***
***                                                                   ***
***    For some commands to work properly, your symbol path           ***
***    must point to .pdb files that have full type information.      ***
***                                                                   ***
***    Certain .pdb files (such as the public OS symbols) do not      ***
***    contain the required information.  Contact the group that      ***
***    provided you with these symbols if you need this command to    ***
***    work.                                                          ***
***                                                                   ***
***    Type referenced: nt_IRP                                        ***
***                                                                   ***
3: kd> dt nt_IRP
*************************************************************************
***                                                                   ***
***                                                                   ***
***    Either you specified an unqualified symbol, or your debugger   ***
***    doesn't have full symbol information.  Unqualified symbol      ***
***    resolution is turned off by default. Please either specify a   ***
***    fully qualified symbol module!symbolname, or enable resolution ***
***    of unqualified symbols by typing ".symopt- 100". Note that     ***
***    enabling unqualified symbol resolution with network symbol     ***
***    server shares in the symbol path may cause the debugger to     ***
***    appear to hang for long periods of time when an incorrect      ***
***    symbol name is typed or the network symbol server is down.     ***
***                                                                   ***
***    For some commands to work properly, your symbol path           ***
***    must point to .pdb files that have full type information.      ***
***                                                                   ***
***    Certain .pdb files (such as the public OS symbols) do not      ***
***    contain the required information.  Contact the group that      ***
***    provided you with these symbols if you need this command to    ***
***    work.                                                          ***
***                                                                   ***
***    Type referenced: nt_IRP                                        ***
***                                                                   ***

Dönüp koda baktığımızda ise post processing ile şunu söylemek istedim, MDL yapılarının sürücü erişiminden sonra buffer kaldırılma sırasında kontrol edildiğini bilmek için alim olmaya gerek yok. Eğer ki senin hatandaki gibi sistem nt!MdlInvariantPostDriverCompletion+8f sırasında bir sürücünün bir şekilde MDL yapısını bozduğunu farkediyor veyahut o sürücü MDL yapısını birden fazla kez kilitleyip açıyor ise bu tip bir mavi ekran olabilir...

Çok başka bir veyahut olarak da

Rich (BB code):

FAILURE_BUCKET_ID:  MEMORY_CORRUPTION_ONE_BIT

Direkt belleğin bozuk olması ve sürücünün belki de suçsuz olması...

İlk önce sürücü kontrolü yapıp sistemin tepkisini kontrol etmeni isteyeceğim. Eğer mavi ekran yersen mutlaka dosyanı paylaş.

Rehber Konu 'Windows 11 için Driver Verifier | Sürücü Doğrulayıcı'

30 Haziran 2024

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...

• bicy
• driver sürücü windows windows 11
• Mesaj: 1
• Forum: Sistem Araçları

Eğer bir sorun olmazsa RAM kontrolü de yapalım. Laptop'larda RAM kontrolü çileli de olabiliyor. Yine de deneyeceğiz.

Genişletmek için tıkla...