3uncubayezit
Uzman
- Katılım
- 13 Mart 2025
- Mesajlar
- 14
- Beğeniler
- 2
Bu konu çözüldü olarak işaretlenmiştir. Çözülmediğini düşünüyorsanız konuyu rapor edebilirsiniz.
Çözüm
Rich (BB code):
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, BugChecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000002000, Code Integrity Issue: The caller specified an executable pool type. (Expected: NonPagedPoolNx)
Arg2: fffff80123989064, The address in the driver's code where the error was detected.
Arg3: 0000000000000000, Pool Type.
Arg4: 00000000474c5452, Pool Tag (if provided).Mavi ile işaretlediğim ilk parametre hatanın türünü açıklıyor. Bu da bir sürücünün yürütülebilir (executable) belleği, NonPagedPoolNx yerine başka bir pool türüyle tahsis etmeye çalıştığını ve bu durumun Verifier tarafından engellendiğini gösteriyor.
Çok daha eski Windows sürümlerinde ExAllocatePool ile yapılan bellek tahsisleri Sayfalanabilen Havuz veya Sayfalanmayan Havuz türleriyle yapılıyordu. Bu türler, okuma/yazma/çalıştırma izinlerine sahip bellek sayfaları tahsis ediyorlar. Windows 8 ile birlikte Microsoft, yalnızca okuma/yazma erişimine sahip ve çalıştırılamayan NonPagedPoolNx türünü ekliyor ve Windows 10 itibariyle artık NonPagedPoolNx kullanmak ZORUNLU hale geliyor. Bu, çoklu platformları destekleyen sürücüler (driver) için bir sorun oluşturuyor haliyle.
Bunun bir güvenlik sebebiyle olduğunu söyleyebilmek kolay zira çünkü kötü amaçlı kodlar, sürücüler üzerinden bu belleği çalıştırabilir durumda oluyorlar eski sürümlerdeki tahsis etme seçeneği ile. Bunu Microsoft'un kendisinden de öğrenebiliyoruz:
Örnek kaynak: https://community.osr.com/t/mysterious-windows-10-driver-verifier-assertion/52368/3
Renklendirdiğim parametreler ile devam ederek sorunu biraz daha analiz etme şansımız oluyor:
Kırmızı ile işaretlediğim Dördüncü parametre PoolTag adresini içeriyor...
Rich (BB code):
1: kd> .formats 00000000474c5452
Evaluate expression:
Hex: 00000000`474c5452
Decimal: 1196184658
Decimal (unsigned) : 1196184658
Octal: 0000000000010723052122
Binary: 00000000 00000000 00000000 00000000 01000111 01001100 01010100 01010010
Chars: ....GLTR
Time: Tue Nov 27 20:30:58 2007
Float: low 52308.3 high 0
Double: 5.90994e-315
Rich (BB code):
1: kd> !pooltag GLTR
Pooltag GLTR not found in pooltag.txt!pooltag GLTR komutunun “not found” dönmesi, bunun standart Windows PoolTag veritabanında tanımlı olmadığını gösteriyor. Bu da muhtemelen soruna sebep olan sürücünün internal içeriğinde olduğunu söylüyor sadece.Türünü mavi ve kalın puntolarla işaretlediğim ilk parametre, beklenen havuz (pool) türünün çalıştırılamaz (non-executable) NonPagedPool olduğunu belirtiyor. Ancak anlattığım gibi sürücü ise soruna sebep olacak şekilde çalıştırılabilir (executable) NonPagedPool türünde bir bellek tahsis isteğinde bulunuyor....
Turuncu ile işaretlediğim üçüncü parametre ise kullanılan havuz türünün değerini belirtiyor.
Rich (BB code):
1: kd> dt _POOL_TYPE
mssmbios!_POOL_TYPE
NonPagedPool = 0n0
NonPagedPoolExecute = 0n0 // Sürücünün talep ettiği "eski tip" pool
PagedPool = 0n1
NonPagedPoolMustSucceed = 0n2
DontUseThisType = 0n3
NonPagedPoolCacheAligned = 0n4
PagedPoolCacheAligned = 0n5
NonPagedPoolCacheAlignedMustS = 0n6
MaxPoolType = 0n7
NonPagedPoolBase = 0n0
NonPagedPoolBaseMustSucceed = 0n2
NonPagedPoolBaseCacheAligned = 0n4
NonPagedPoolBaseCacheAlignedMustS = 0n6
NonPagedPoolSession = 0n32
PagedPoolSession = 0n33
NonPagedPoolMustSucceedSession = 0n34
DontUseThisTypeSession = 0n35
NonPagedPoolCacheAlignedSession = 0n36
PagedPoolCacheAlignedSession = 0n37
NonPagedPoolCacheAlignedMustSSession = 0n38
NonPagedPoolNx = 0n512 // Sürücünün talep etmesi gereken "yeni tip" pool
NonPagedPoolNxCacheAligned = 0n516
NonPagedPoolSessionNx = 0n544Son olarak da yeşil ile işaretlediğim ikinci parametre, çağrı yığınında son çalıştırılan işlevin dönüş adresini ifade ediyor. Aynı şekilde bu çağrı yığınında sürücüyü de bulabiliyoruz.
Rich (BB code):
1: kd> KnL
# Child-SP RetAddr Call Site
00 ffffbe80`26be21c8 fffff806`28de0e34 nt!KeBugCheckEx
01 ffffbe80`26be21d0 fffff806`289b1b65 nt!VerifierBugCheckIfAppropriate+0xe0
02 ffffbe80`26be2210 fffff806`28dd7df4 nt!VfReportIssueWithOptions+0x101 // Hata fark ediyor
03 ffffbe80`26be2260 fffff806`28de5042 nt!VfCheckPoolType+0x90 // Verifier talep ettiği pool'un type'ını kontrol ediyor
04 ffffbe80`26be22a0 fffff801`23989064 nt!VerifierExAllocatePoolWithTag+0x62 // Belli bir işaret ile bir bellek tahsisi talep ediyor
05 ffffbe80`26be22f0 ffffe387`02730a10 RtsPer+0x79064 // Hataya sebep olan sürücümüzHatanın sebebinin Realtek Kart Okuyucu sürücüsü olduğunu da öğrenmiş oluyoruz bu şekilde. Aynı zamanda 2.parametredeki adresin işaret ettiği dönen son fonksiyonu da görebiliyoruz bu şekilde...
Rich (BB code):
1: kd> ub fffff801`23989064
RtsPer+0x79042:
fffff801`23989042 ec in al,dx
fffff801`23989043 288325359f03 sub byte ptr [rbx+39F3525h],al
fffff801`23989049 0000 add byte ptr [rax],al
fffff801`2398904b ba00000800 mov edx,80000h
fffff801`23989050 33c9 xor ecx,ecx
fffff801`23989052 41b852544c47 mov r8d,474C5452h
fffff801`23989058 8915269f0300 mov dword ptr [RtsPer+0xb2f84 (fffff801`239c2f84)],edx
fffff801`2398905e ff15cc3f0300 call qword ptr [RtsPer+0xad030 (fffff801`239bd030)]Kart okuyucu sürücün o kadar eski ki, Windows 10'un resmi çıkış tarihinden bile önce...
Rich (BB code):
1: kd> lmvm RtsPer
Browse full module list
start end module name
fffff801`23910000 fffff801`239cd000 RtsPer T (no symbols)
Loaded symbol image file: RtsPer.sys
Image path: \SystemRoot\system32\DRIVERS\RtsPer.sys
Image name: RtsPer.sys
Browse all global symbols functions data
Timestamp: Wed May 6 10:22:09 2015 (5549C121)
CheckSum: 000C6119
ImageSize: 000BD000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:Muhtemelen sürücü daha sonradan güncellenerek Windows 10 ile beraber gelen zorunlu havuz etiketleriyle çalışacak şekilde değiştirilmiştir. Senin de güncellemen iyi olacaktır.
OCCT veya Prime95 üzerinden belli bir stres testi seçeneği ile de yapabilirsin. Ben onları tavsiye ederim.
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.
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.
Ş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.
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...
Ş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ı.
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
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ş.
Eğer bir sorun olmazsa RAM kontrolü de yapalım. Laptop'larda RAM kontrolü çileli de olabiliyor. Yine de deneyeceğiz.
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: ntSorun ş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...
Ş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_BITDirekt 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ş.
Eğer bir sorun olmazsa RAM kontrolü de yapalım. Laptop'larda RAM kontrolü çileli de olabiliyor. Yine de deneyeceğiz.
KS
KS
3uncubayezit
Uzman
- Katılım
- 13 Mart 2025
- Mesajlar
- 14
- Beğeniler
- 2
Verifier yaptıktan sonra bilgisayarı yeniden başlattığım sırada mavi ekran aldım. Bu da minidump raporu. Ek olarak Memtest86 da yapabilirim. Nasıl yapacağımı biliyorum.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.
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...
Ş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ş.
Eğer bir sorun olmazsa RAM kontrolü de yapalım. Laptop'larda RAM kontrolü çileli de olabiliyor. Yine de deneyeceğiz.
Rich (BB code):
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, BugChecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000002000, Code Integrity Issue: The caller specified an executable pool type. (Expected: NonPagedPoolNx)
Arg2: fffff80123989064, The address in the driver's code where the error was detected.
Arg3: 0000000000000000, Pool Type.
Arg4: 00000000474c5452, Pool Tag (if provided).Mavi ile işaretlediğim ilk parametre hatanın türünü açıklıyor. Bu da bir sürücünün yürütülebilir (executable) belleği, NonPagedPoolNx yerine başka bir pool türüyle tahsis etmeye çalıştığını ve bu durumun Verifier tarafından engellendiğini gösteriyor.
Çok daha eski Windows sürümlerinde ExAllocatePool ile yapılan bellek tahsisleri Sayfalanabilen Havuz veya Sayfalanmayan Havuz türleriyle yapılıyordu. Bu türler, okuma/yazma/çalıştırma izinlerine sahip bellek sayfaları tahsis ediyorlar. Windows 8 ile birlikte Microsoft, yalnızca okuma/yazma erişimine sahip ve çalıştırılamayan NonPagedPoolNx türünü ekliyor ve Windows 10 itibariyle artık NonPagedPoolNx kullanmak ZORUNLU hale geliyor. Bu, çoklu platformları destekleyen sürücüler (driver) için bir sorun oluşturuyor haliyle.
Bunun bir güvenlik sebebiyle olduğunu söyleyebilmek kolay zira çünkü kötü amaçlı kodlar, sürücüler üzerinden bu belleği çalıştırabilir durumda oluyorlar eski sürümlerdeki tahsis etme seçeneği ile. Bunu Microsoft'un kendisinden de öğrenebiliyoruz:
Örnek kaynak: https://community.osr.com/t/mysterious-windows-10-driver-verifier-assertion/52368/3
Renklendirdiğim parametreler ile devam ederek sorunu biraz daha analiz etme şansımız oluyor:
Kırmızı ile işaretlediğim Dördüncü parametre PoolTag adresini içeriyor...
Rich (BB code):
1: kd> .formats 00000000474c5452
Evaluate expression:
Hex: 00000000`474c5452
Decimal: 1196184658
Decimal (unsigned) : 1196184658
Octal: 0000000000010723052122
Binary: 00000000 00000000 00000000 00000000 01000111 01001100 01010100 01010010
Chars: ....GLTR
Time: Tue Nov 27 20:30:58 2007
Float: low 52308.3 high 0
Double: 5.90994e-315
Rich (BB code):
1: kd> !pooltag GLTR
Pooltag GLTR not found in pooltag.txt!pooltag GLTR komutunun “not found” dönmesi, bunun standart Windows PoolTag veritabanında tanımlı olmadığını gösteriyor. Bu da muhtemelen soruna sebep olan sürücünün internal içeriğinde olduğunu söylüyor sadece.Türünü mavi ve kalın puntolarla işaretlediğim ilk parametre, beklenen havuz (pool) türünün çalıştırılamaz (non-executable) NonPagedPool olduğunu belirtiyor. Ancak anlattığım gibi sürücü ise soruna sebep olacak şekilde çalıştırılabilir (executable) NonPagedPool türünde bir bellek tahsis isteğinde bulunuyor....
Turuncu ile işaretlediğim üçüncü parametre ise kullanılan havuz türünün değerini belirtiyor.
Rich (BB code):
1: kd> dt _POOL_TYPE
mssmbios!_POOL_TYPE
NonPagedPool = 0n0
NonPagedPoolExecute = 0n0 // Sürücünün talep ettiği "eski tip" pool
PagedPool = 0n1
NonPagedPoolMustSucceed = 0n2
DontUseThisType = 0n3
NonPagedPoolCacheAligned = 0n4
PagedPoolCacheAligned = 0n5
NonPagedPoolCacheAlignedMustS = 0n6
MaxPoolType = 0n7
NonPagedPoolBase = 0n0
NonPagedPoolBaseMustSucceed = 0n2
NonPagedPoolBaseCacheAligned = 0n4
NonPagedPoolBaseCacheAlignedMustS = 0n6
NonPagedPoolSession = 0n32
PagedPoolSession = 0n33
NonPagedPoolMustSucceedSession = 0n34
DontUseThisTypeSession = 0n35
NonPagedPoolCacheAlignedSession = 0n36
PagedPoolCacheAlignedSession = 0n37
NonPagedPoolCacheAlignedMustSSession = 0n38
NonPagedPoolNx = 0n512 // Sürücünün talep etmesi gereken "yeni tip" pool
NonPagedPoolNxCacheAligned = 0n516
NonPagedPoolSessionNx = 0n544Son olarak da yeşil ile işaretlediğim ikinci parametre, çağrı yığınında son çalıştırılan işlevin dönüş adresini ifade ediyor. Aynı şekilde bu çağrı yığınında sürücüyü de bulabiliyoruz.
Rich (BB code):
1: kd> KnL
# Child-SP RetAddr Call Site
00 ffffbe80`26be21c8 fffff806`28de0e34 nt!KeBugCheckEx
01 ffffbe80`26be21d0 fffff806`289b1b65 nt!VerifierBugCheckIfAppropriate+0xe0
02 ffffbe80`26be2210 fffff806`28dd7df4 nt!VfReportIssueWithOptions+0x101 // Hata fark ediyor
03 ffffbe80`26be2260 fffff806`28de5042 nt!VfCheckPoolType+0x90 // Verifier talep ettiği pool'un type'ını kontrol ediyor
04 ffffbe80`26be22a0 fffff801`23989064 nt!VerifierExAllocatePoolWithTag+0x62 // Belli bir işaret ile bir bellek tahsisi talep ediyor
05 ffffbe80`26be22f0 ffffe387`02730a10 RtsPer+0x79064 // Hataya sebep olan sürücümüzHatanın sebebinin Realtek Kart Okuyucu sürücüsü olduğunu da öğrenmiş oluyoruz bu şekilde. Aynı zamanda 2.parametredeki adresin işaret ettiği dönen son fonksiyonu da görebiliyoruz bu şekilde...
Rich (BB code):
1: kd> ub fffff801`23989064
RtsPer+0x79042:
fffff801`23989042 ec in al,dx
fffff801`23989043 288325359f03 sub byte ptr [rbx+39F3525h],al
fffff801`23989049 0000 add byte ptr [rax],al
fffff801`2398904b ba00000800 mov edx,80000h
fffff801`23989050 33c9 xor ecx,ecx
fffff801`23989052 41b852544c47 mov r8d,474C5452h
fffff801`23989058 8915269f0300 mov dword ptr [RtsPer+0xb2f84 (fffff801`239c2f84)],edx
fffff801`2398905e ff15cc3f0300 call qword ptr [RtsPer+0xad030 (fffff801`239bd030)]Kart okuyucu sürücün o kadar eski ki, Windows 10'un resmi çıkış tarihinden bile önce...
Rich (BB code):
1: kd> lmvm RtsPer
Browse full module list
start end module name
fffff801`23910000 fffff801`239cd000 RtsPer T (no symbols)
Loaded symbol image file: RtsPer.sys
Image path: \SystemRoot\system32\DRIVERS\RtsPer.sys
Image name: RtsPer.sys
Browse all global symbols functions data
Timestamp: Wed May 6 10:22:09 2015 (5549C121)
CheckSum: 000C6119
ImageSize: 000BD000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:Muhtemelen sürücü daha sonradan güncellenerek Windows 10 ile beraber gelen zorunlu havuz etiketleriyle çalışacak şekilde değiştirilmiştir. Senin de güncellemen iyi olacaktır.
OCCT veya Prime95 üzerinden belli bir stres testi seçeneği ile de yapabilirsin. Ben onları tavsiye ederim.
Benzer konular
- Soru
Yeni konular
-
-
-
-
-
-
ASUS A55BM-E anakart ile mavi ekran ve performans sorunu
- yigitminer
- Mesaj: 0
-
