Çözüldü Format sonrası NETIO.SYS mavi ekran hatası

  • Konuyu başlatan Konuyu başlatan Akbabuş
  • Başlangıç Tarihi Başlangıç Tarihi
  • Mesaj Mesaj 6
  • Görüntüleme Görüntüleme 236
Bu konu çözüldü olarak işaretlenmiştir. Çözülmediğini düşünüyorsanız konuyu rapor edebilirsiniz.
Çözüm
Dosyanın yettiği kadarıyla anlatmaya çalışacağım. Minidump bu dosyayı incelemek için yeterli değil.

Rich (BB code): 
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000008, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff8041328cc88, address which referenced memory

Mor ile işaretlenmiş olan ilk parametreye bakarsan geçerli olmayan bir bellek adresine referans verildiğini görebilirsin, bu adresin geçerli bir fiziksel bellek adresine işaret etmediğini ve bu nedenle bellek yöneticisini de PageFault oluşturmaya ittiğini söyleyebiliriz.

Rich (BB code): 
4: kd> ln fffff8041328cc88
Browse module
Set bu breakpoint

(fffff804`1328cc2c)   NETIO!StreamInvokeCalloutAndNormalizeAction+0x5c   |  (fffff804`1328d650)   NETIO!StreamNormalizeClassifyOut

Yeşil ile işaretlediğim son parametre ise, mavi ekrana yol açan ilk parametredeki adrese kimin başvurduğunu gösteriyor. Gördüğün gibi, fonksiyon ağ yığınının bir kısmına aitt ve senin de dediğin gibi buna ağ tabanlı bir sürücünün soruna neden olduğu gibi bir çıkarım koyulabilir. Ancak daha da önemlisi, fonksiyon adını incelersek, bir ağ akışıyla ilgili bir filtre çağrısı yaptığını da görebiliyoruz.

Rich (BB code): 
4: kd> k
 # Child-SP          RetAddr               Call Site
00 ffff8584`2c3476f8 fffff804`802b8fe9     nt!KeBugCheckEx
01 ffff8584`2c347700 fffff804`802b42a8     nt!KiBugCheckDispatch+0x69
02 ffff8584`2c347840 fffff804`1328cc88     nt!KiPageFault+0x468
03 ffff8584`2c3479d0 fffff804`1328c68b     NETIO!StreamInvokeCalloutAndNormalizeAction+0x5c
04 ffff8584`2c347ad0 fffff804`1328b224     NETIO!StreamCalloutProcessingLoop+0x147
05 ffff8584`2c347b90 fffff804`1328a01e     NETIO!StreamProcessCallout+0x2f4
06 ffff8584`2c347cc0 fffff804`13288a67     NETIO!ProcessCallout+0x88e
07 ffff8584`2c347dc0 fffff804`132c4ae6     NETIO!ArbitrateAndEnforce+0x3f7
08 ffff8584`2c347f00 fffff804`802a5d5e     NETIO!ArbitrateAndEnforceCallout+0x46
09 ffff8584`2c347f60 fffff804`802a5d1b     nt!KxSwitchKernelStackCallout+0x2e
0a ffff8584`28e151b0 00000000`00000000     nt!KiSwitchKernelStackContinue

Filtreden kastımız da , TCP/IP veri paketlerini incelemek ve belirli bir koşula bağlı olarak bir eylem uygulamak için kullanılan Windows Filtreleme Platformu veya onunla alakalı bir parça diyebilirim. Örneğin, belirli bir dize veya IP adresi içeren veri paketlerini günlüğe kaydetmek istemek; bunu başarmak için bir filtre çağrı sürücüsü kullanılabilir. Her callout, filtreleme platformunun kalbi olan ve ağ yığınımızdan geçen paketleri inceleyen Filtre Motoru ile kayıt oluyor. Bu mesajın sonunda Windows'un ilgili dökümanını da koyacağım. Şimdilik,



TCP paketlerinin nasıl yakalandığını tam olarak anlamak için filtreleme hakkında bu filtreleme yapısının temsili resmine bakalım; Bir ağ paketi ağ yığınından geçerken, ilgili filtre katmanındaki filtre(ler) değerlendiriliyor, tüm filtreleme koşulları doğruysa ve filtre filtreleme eylemi için bir çağrı sağlarsa ilgili çağrının sınıflandırma işlevi daha sonra filtreleme mekanizması tarafından çağırılıyor.

Evet buraya kadar sorunun nasıl ortaya çıktığını anlayabiliyoruz ama bundan sonra bu noktadan elimizdeki dosyayla pek bir şansımız yok zira bir sürücü sorunu olduğunu anlayabiliyoruz ama bunu tam olarak tespit etmemiz için Windows Filtreleme Çağrı yığının başlangıç noktasından ilerlememiz gerekiyor.

Rich (BB code): 
4: kd> dp   netio!gWfpGlobal L1
fffff804`13305b18  ????????`???????? // Filtreleme çağrı yapısının işaretçisi -- Dosya yetersiz/Göremiyoruz

İlk olarak bu işaretçiyi elde etmemiz gerekiyor. Daha sonra bu işaretçiye itilen offset alanlarını bulmamız gerekiyor.

Rich (BB code): 
NETIO!FeInitCalloutTable:
fffff804`132d7ef0 4053            push    rbx
fffff804`132d7ef2 4883ec20        sub     rsp,20h
fffff804`132d7ef6 488b051bdc0200  mov     rax,qword ptr [NETIO!gWfpGlobal (fffff804`13305b18)]
fffff804`132d7efd 0f57c0          xorps   xmm0,xmm0
fffff804`132d7f00 ba57667043      mov     edx,43706657h
fffff804`132d7f05 b900800100      mov     ecx,18000h
fffff804`132d7f0a 0f118098010000  mov  xmmword ptr [rax+198h],xmm0
fffff804`132d7f11 4c8b0500dc0200  mov     r8,qword ptr [NETIO!gWfpGlobal (fffff804`13305b18)]

Aynı şekilde bu dosyanın yetersiz olması, Bu yapıya itilen tüm offsetleri de göstermiyor. Bu noktada elde etmeye çalıştığımız döngüde elimizde olması gereken 4 veriden 3 tanesine sahip olamıyoruz.

Son olarak da bu döngüyü düzgün bir şekilde elde etmek için her callout yapısının boyutunu bulmamız gerekiyor. Bunu bulmak için, varsayılan callout için başlatma fonksiyonunu analiz edebiliriz...

Rich (BB code): 
NETIO!InitDefaultCallout:
fffff804`132d7f84 4053            push    rbx
fffff804`132d7f86 4883ec20        sub     rsp,20h
fffff804`132d7f8a 4c8d05f7d80200  lea     r8,[NETIO!gFeCallout (fffff804`13305888)]
fffff804`132d7f91 ba57667043      mov     edx,43706657h
fffff804`132d7f96 b960000000      mov     ecx,60h // Boyutumuz
fffff804`132d7f9b e89016faff      call    NETIO!WfpPoolAllocNonPaged (fffff804`13279630)
fffff804`132d7fa0 488bd8          mov     rbx,rax
fffff804`132d7fa3 4885c0          test    rax,rax

Elde olan 4 veriden 3 tanesine sahip olamadığımız bir için ilgili döngüye bakamıyoruz. Bu da o an döngüde mevcut olan sürücüleri görmemizi engelliyor. Dosya yetersiz çünkü. Elimizdeki tek şans bu yığının tüm bellek bölgelerinin içeriğine bakmak oluyor.

Rich (BB code): 
0xffff85842c347838 : 0xfffff804802b42a8 : nt!KiPageFault+0x468
0xffff85842c347840 : 0xffff85842c347c01 : adgnetworkwfpdrv
0xffff85842c347948 : 0xfffff8041328d006 : NETIO!StreamInvokeCalloutAndNormalizeAction+0x3da
0xffff85842c347968 : 0xfffff8041328f054 : NETIO!StreamDataBlock+0xc8
0xffff85842c3479a8 : 0xfffff8041328cc88 : NETIO!StreamInvokeCalloutAndNormalizeAction+0x5c
0xffff85842c3479e0 : 0xfffff80413305000 : NETIO!WPP_GLOBAL_Control
0xffff85842c347a28 : 0xfffff8041328dfe7 : NETIO!StreamApplyCalloutActionToData+0x113
0xffff85842c347a48 : 0xfffff804132b572f : NETIO!StreamCalloutProcessDisconnect+0x7f
0xffff85842c347ac8 : 0xfffff8041328c68b : NETIO!StreamCalloutProcessingLoop+

En başta dediğim gibi Adguard sürücüsünün PageFault öncesi çağrılması beni suçlu olmasına itti ama aynı şekilde Ethernet sürücüsü de olabilir. Bir MEMORY.DMP varsa inceleyebiliriz (C:/Windows klasöründe MEMORY.DMP adıyla herhangi bir klasöre dahil olmadan direkt olarak bulunur.) Yoksa da Adguard ve Ethernet sürücülerinden birinden çözüme gidebiliriz.


Tarihe göre sırala Puana göre sırala
Sorunun sebebi AdGuard olabilir. Açıkçası NetIO API'sinin kullandığı tüm fonksiyonlara hakim değilim. Sadece Kaspersky gibi uygulamaların bağlantıları için kullandıklarından bir haber sayılırım. Dosyada dikkatimi çeken şey bu arkadaşa ait sürücünün sık sık sistemin hata yakalamasından önce çağırıldığını görmek oldu.

Rich (BB code): 
0: kd> lmvmadgnetworkwfpdrv
Browse full module list
start end module name
fffff802`5f5a0000 fffff802`5f5ba000 adgnetworkwfpdrv T (no symbols)
 Loaded symbol image file: adgnetworkwfpdrv.sys
 Image path: adgnetworkwfpdrv.sys
 Image name: adgnetworkwfpdrv.sys
 Browse all global symbols functions data
 Timestamp: Wed Mar 5 16:03:33 2025 (67C84BA5)
 CheckSum: 00023CFA
 ImageSize: 0001A000
 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
 Information from resource tables:
 
İfadeler: 99
Artı 0 Eksi
@bicy Merhaba hocam,

AdGuard Windows için Premium kullanıyorum. Oradaki bir ayardan mı kaynaklıdır, çünkü formattan öncede kullanıyordum sorun çıkmamıştı. Ethernet sürücüsü kaynaklı düşünüyorum ben, çok anlamam ama Direkt olarak mavi ekran verip kapatmıyor, mavi ekranı bozuk görüntü ile verip yeniden başlatıyor.
 
Artı 0 Eksi
Dosyanın yettiği kadarıyla anlatmaya çalışacağım. Minidump bu dosyayı incelemek için yeterli değil.

Rich (BB code): 
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000008, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff8041328cc88, address which referenced memory

Mor ile işaretlenmiş olan ilk parametreye bakarsan geçerli olmayan bir bellek adresine referans verildiğini görebilirsin, bu adresin geçerli bir fiziksel bellek adresine işaret etmediğini ve bu nedenle bellek yöneticisini de PageFault oluşturmaya ittiğini söyleyebiliriz.

Rich (BB code): 
4: kd> ln fffff8041328cc88
Browse module
Set bu breakpoint

(fffff804`1328cc2c)   NETIO!StreamInvokeCalloutAndNormalizeAction+0x5c   |  (fffff804`1328d650)   NETIO!StreamNormalizeClassifyOut

Yeşil ile işaretlediğim son parametre ise, mavi ekrana yol açan ilk parametredeki adrese kimin başvurduğunu gösteriyor. Gördüğün gibi, fonksiyon ağ yığınının bir kısmına aitt ve senin de dediğin gibi buna ağ tabanlı bir sürücünün soruna neden olduğu gibi bir çıkarım koyulabilir. Ancak daha da önemlisi, fonksiyon adını incelersek, bir ağ akışıyla ilgili bir filtre çağrısı yaptığını da görebiliyoruz.

Rich (BB code): 
4: kd> k
 # Child-SP          RetAddr               Call Site
00 ffff8584`2c3476f8 fffff804`802b8fe9     nt!KeBugCheckEx
01 ffff8584`2c347700 fffff804`802b42a8     nt!KiBugCheckDispatch+0x69
02 ffff8584`2c347840 fffff804`1328cc88     nt!KiPageFault+0x468
03 ffff8584`2c3479d0 fffff804`1328c68b     NETIO!StreamInvokeCalloutAndNormalizeAction+0x5c
04 ffff8584`2c347ad0 fffff804`1328b224     NETIO!StreamCalloutProcessingLoop+0x147
05 ffff8584`2c347b90 fffff804`1328a01e     NETIO!StreamProcessCallout+0x2f4
06 ffff8584`2c347cc0 fffff804`13288a67     NETIO!ProcessCallout+0x88e
07 ffff8584`2c347dc0 fffff804`132c4ae6     NETIO!ArbitrateAndEnforce+0x3f7
08 ffff8584`2c347f00 fffff804`802a5d5e     NETIO!ArbitrateAndEnforceCallout+0x46
09 ffff8584`2c347f60 fffff804`802a5d1b     nt!KxSwitchKernelStackCallout+0x2e
0a ffff8584`28e151b0 00000000`00000000     nt!KiSwitchKernelStackContinue

Filtreden kastımız da , TCP/IP veri paketlerini incelemek ve belirli bir koşula bağlı olarak bir eylem uygulamak için kullanılan Windows Filtreleme Platformu veya onunla alakalı bir parça diyebilirim. Örneğin, belirli bir dize veya IP adresi içeren veri paketlerini günlüğe kaydetmek istemek; bunu başarmak için bir filtre çağrı sürücüsü kullanılabilir. Her callout, filtreleme platformunun kalbi olan ve ağ yığınımızdan geçen paketleri inceleyen Filtre Motoru ile kayıt oluyor. Bu mesajın sonunda Windows'un ilgili dökümanını da koyacağım. Şimdilik,



TCP paketlerinin nasıl yakalandığını tam olarak anlamak için filtreleme hakkında bu filtreleme yapısının temsili resmine bakalım; Bir ağ paketi ağ yığınından geçerken, ilgili filtre katmanındaki filtre(ler) değerlendiriliyor, tüm filtreleme koşulları doğruysa ve filtre filtreleme eylemi için bir çağrı sağlarsa ilgili çağrının sınıflandırma işlevi daha sonra filtreleme mekanizması tarafından çağırılıyor.

Evet buraya kadar sorunun nasıl ortaya çıktığını anlayabiliyoruz ama bundan sonra bu noktadan elimizdeki dosyayla pek bir şansımız yok zira bir sürücü sorunu olduğunu anlayabiliyoruz ama bunu tam olarak tespit etmemiz için Windows Filtreleme Çağrı yığının başlangıç noktasından ilerlememiz gerekiyor.

Rich (BB code): 
4: kd> dp   netio!gWfpGlobal L1
fffff804`13305b18  ????????`???????? // Filtreleme çağrı yapısının işaretçisi -- Dosya yetersiz/Göremiyoruz

İlk olarak bu işaretçiyi elde etmemiz gerekiyor. Daha sonra bu işaretçiye itilen offset alanlarını bulmamız gerekiyor.

Rich (BB code): 
NETIO!FeInitCalloutTable:
fffff804`132d7ef0 4053            push    rbx
fffff804`132d7ef2 4883ec20        sub     rsp,20h
fffff804`132d7ef6 488b051bdc0200  mov     rax,qword ptr [NETIO!gWfpGlobal (fffff804`13305b18)]
fffff804`132d7efd 0f57c0          xorps   xmm0,xmm0
fffff804`132d7f00 ba57667043      mov     edx,43706657h
fffff804`132d7f05 b900800100      mov     ecx,18000h
fffff804`132d7f0a 0f118098010000  mov  xmmword ptr [rax+198h],xmm0
fffff804`132d7f11 4c8b0500dc0200  mov     r8,qword ptr [NETIO!gWfpGlobal (fffff804`13305b18)]

Aynı şekilde bu dosyanın yetersiz olması, Bu yapıya itilen tüm offsetleri de göstermiyor. Bu noktada elde etmeye çalıştığımız döngüde elimizde olması gereken 4 veriden 3 tanesine sahip olamıyoruz.

Son olarak da bu döngüyü düzgün bir şekilde elde etmek için her callout yapısının boyutunu bulmamız gerekiyor. Bunu bulmak için, varsayılan callout için başlatma fonksiyonunu analiz edebiliriz...

Rich (BB code): 
NETIO!InitDefaultCallout:
fffff804`132d7f84 4053            push    rbx
fffff804`132d7f86 4883ec20        sub     rsp,20h
fffff804`132d7f8a 4c8d05f7d80200  lea     r8,[NETIO!gFeCallout (fffff804`13305888)]
fffff804`132d7f91 ba57667043      mov     edx,43706657h
fffff804`132d7f96 b960000000      mov     ecx,60h // Boyutumuz
fffff804`132d7f9b e89016faff      call    NETIO!WfpPoolAllocNonPaged (fffff804`13279630)
fffff804`132d7fa0 488bd8          mov     rbx,rax
fffff804`132d7fa3 4885c0          test    rax,rax

Elde olan 4 veriden 3 tanesine sahip olamadığımız bir için ilgili döngüye bakamıyoruz. Bu da o an döngüde mevcut olan sürücüleri görmemizi engelliyor. Dosya yetersiz çünkü. Elimizdeki tek şans bu yığının tüm bellek bölgelerinin içeriğine bakmak oluyor.

Rich (BB code): 
0xffff85842c347838 : 0xfffff804802b42a8 : nt!KiPageFault+0x468
0xffff85842c347840 : 0xffff85842c347c01 : adgnetworkwfpdrv
0xffff85842c347948 : 0xfffff8041328d006 : NETIO!StreamInvokeCalloutAndNormalizeAction+0x3da
0xffff85842c347968 : 0xfffff8041328f054 : NETIO!StreamDataBlock+0xc8
0xffff85842c3479a8 : 0xfffff8041328cc88 : NETIO!StreamInvokeCalloutAndNormalizeAction+0x5c
0xffff85842c3479e0 : 0xfffff80413305000 : NETIO!WPP_GLOBAL_Control
0xffff85842c347a28 : 0xfffff8041328dfe7 : NETIO!StreamApplyCalloutActionToData+0x113
0xffff85842c347a48 : 0xfffff804132b572f : NETIO!StreamCalloutProcessDisconnect+0x7f
0xffff85842c347ac8 : 0xfffff8041328c68b : NETIO!StreamCalloutProcessingLoop+

En başta dediğim gibi Adguard sürücüsünün PageFault öncesi çağrılması beni suçlu olmasına itti ama aynı şekilde Ethernet sürücüsü de olabilir. Bir MEMORY.DMP varsa inceleyebiliriz (C:/Windows klasöründe MEMORY.DMP adıyla herhangi bir klasöre dahil olmadan direkt olarak bulunur.) Yoksa da Adguard ve Ethernet sürücülerinden birinden çözüme gidebiliriz.


 
Artı 0 Eksi
Çözüm
@bicy,

Elinize sağlık hocam, makale gibi olmuş. Çoğunlukla anlamadığım ve bilmediğim terimler. Daha önce Ethernet sürücüsünü Windows'a bırakıyordum ellemiyordum, son formatta Gigabyte'ın APP Center uygulamasından kurdum, ondan sonra böyle hatalar vermeye başladı. Son formattan önce yine AdGuard kullanıyordum uzun süre mavi ekranı hatasını almamıştım. Şu an yine Windows Update'deki sürücüyü yükledim kullanıyorum, hata devam ederse bildiririm. MEMORY.DMP dosyası da çıkmadı maalesef.
 
Artı 0 Eksi
Mesaj yazmak için giriş yapmalı ya da kaydolmalısınız.

Benzer konular

E
  • Soru Soru
Format sonrası FPS drop, ses kesilmesi ve mavi ekran sorunu
Mesaj
4
Görüntüleme
152
Ebetraiboz
E
B
  • Soru Soru
R5 5600 ve RTX 3060 Sistemde Reaper Kullanırken Mavi Ekran Hatası
Mesaj
2
Görüntüleme
116
Bilgin
B
E
  • Soru Soru
Monster Tulpar T7'de VIDEO_DXGKRNL_FATAL_ERROR 0x113 mavi ekran hatası
Mesaj
2
Görüntüleme
82
Emir Çip
E
  • Soru Soru
GTA 5 indirken mavi ekran hatası
Mesaj
5
Görüntüleme
166
Astro.PR
Menü
Giriş yap
Kaydol
Bu siteyi kullanmak için çerezler gereklidir. Siteyi kullanmaya devam etmek için çerezleri kabul etmelisiniz. Daha Fazlasını Öğren.…