Genel olarak bir device Object'i bir yığından rastgele bir anda ayırmak güvenli bir hareket olarak nitelendirilen bir şey değildir. Diğer sürücüler kendi device Objectler'ini de bu sürücü üzerine ekleyebilir, birisi daha fazla I/O bu Object'e referans tutabilir ve bu durumda referans sayısı artan objectin kullanım ihtimali de artar.
Aslında,
IoAttachDevice'i çağırdıktan sonra direkt olarak objenin ömrü üzerindeki kontrolü kaybetmiş oluyoruz.
PnP yığınları için, ayırmanın mantıklı sayılabilecek tek yolu ırp_mn_remove_devıce isteğini işlemektir. PnP olmayan yığınlar için bunu başarmanın kolay ve güvenli bir yolu yok ne yazık ki.
Rich (BB code):
KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure. The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 000000000000000a, Indirect call guard check detected invalid control transfer.
Arg2: 0000000000000000, Address of the trap frame for the exception that caused the BugCheck
Arg3: 0000000000000000, Address of the exception record for the exception that caused the BugCheck
Arg4: fffff8004b923de0, Reserved
Burada gördüğümüz hata genel bu hatanın başlığından farklı olarak (genelde liste yapılarının bozulmasını içerir) ve tam detaylı yorumlanmamış olarak; çekirdek bir fonksiyon Pointer'ı beklenmeyen bir adrese çağrı yapmaya çalışmış. Genelde yanlış fonksiyon Pointer'ı, bozulmuş context, ya da önceden serbest bırakılmış obje kullanıldığında ortaya çıkan bir hatadan ibaret diyebiliriz. Tabii bunu daha iyi anlamlandırabilmek için stack yığınını da incelemek gerekiyor...
Rich (BB code):
15: kd> k
# Child-SP RetAddr Call Site
00 ffffa600`f0b84c78 fffff800`9d2ad6de nt!KeBugCheckEx
01 ffffa600`f0b84c80 fffff800`9cf30127 nt!guard_icall_bugcheck+0x1e
02 ffffa600`f0b84cb0 fffff800`9cf2f073 nt!IopfCompleteRequest+0x1087 // 2.kez tamamlanan rutin ?
03 ffffa600`f0b84dd0 fffff800`2f1ad2ce nt!IofCompleteRequest+0x13 // Tamamlanan rutin
04 (Inline Function) --------`-------- Wdf01000!FxIrp::CompleteRequest+0x13 // IofCompleteRequest'i çağırmak için kullanılan WDF işlevi
[minkernel\wdf\framework\shared\inc\private\km\FxIrpKm.hpp @ 75]
05 ffffa600`f0b84e00 fffff800`2f1e8840 Wdf01000!FxRequest::CompleteInternal+0x13e [minkernel\wdf\framework\shared\core\fxrequest.cpp @ 869]
06 (Inline Function) --------`-------- Wdf01000!FxRequest::Complete+0x30 [minkernel\wdf\framework\shared\inc\private\common\FxRequest.hpp @ 803]
07 ffffa600`f0b84e90 fffff800`2f1e86a3 Wdf01000!FxRequest::CompleteWithInformation+0x54 [minkernel\wdf\framework\shared\inc\private\common\FxRequest.hpp @ 819]
08 ffffa600`f0b84ef0 fffff800`2f1b5b59 Wdf01000!FxIoQueue::CancelForQueue+0x87 [minkernel\wdf\framework\shared\irphandlers\io\fxioqueue.cpp @ 4435]
09 ffffa600`f0b84f50 fffff800`2f1b53aa Wdf01000!FxIoQueue::QueuePurge+0x3dd [minkernel\wdf\framework\shared\irphandlers\io\fxioqueue.cpp @ 4056]
0a ffffa600`f0b84fd0 fffff800`2f1b714f Wdf01000!FxIoQueue::QueuePurgeSynchronously+0x56 [minkernel\wdf\framework\shared\irphandlers\io\fxioqueue.cpp @ 4156]
0b ffffa600`f0b85050 fffff800`4b8a0ccb Wdf01000!imp_WdfIoQueuePurgeSynchronously+0x4f [minkernel\wdf\framework\shared\irphandlers\io\fxioqueueapi.cpp @ 1201]
0c ffffa600`f0b85090 fffff800`4b89b532 bthhfenum!ScoCleanup+0x137
0d ffffa600`f0b850e0 fffff800`4b8939aa bthhfenum!BthHwUnInitialize+0x1a6
0e ffffa600`f0b85110 fffff800`2f218bf6 bthhfenum!Bus_EvtDeviceSelfManagedIoFlush+0x4a
0f ffffa600`f0b85150 fffff800`2f1bb915 Wdf01000!FxPowerDeviceDisarmWakeFromS0::InvokeClient+0x16 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpcallbacks.cpp @ 735]
10 ffffa600`f0b85180 fffff800`2f21e3f0 Wdf01000!FxPrePostCallback::InvokeStateless+0x31 [minkernel\wdf\framework\shared\irphandlers\pnp\cxpnppowercallbacks.cpp @ 408]
11 (Inline Function) --------`-------- Wdf01000!FxPnpDeviceSelfManagedIoFlush::Invoke+0x21 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpcallbacks.cpp @ 709]
12 ffffa600`f0b851b0 fffff800`2f1bacc6 Wdf01000!FxSelfManagedIoMachine::Flushing+0x30 [minkernel\wdf\framework\shared\irphandlers\pnp\selfmanagediostatemachine.cpp @ 515]
13 ffffa600`f0b851e0 fffff800`2f20e946 Wdf01000!FxSelfManagedIoMachine::ProcessEvent+0x17a [minkernel\wdf\framework\shared\irphandlers\pnp\selfmanagediostatemachine.cpp @ 339]
14 (Inline Function) --------`-------- Wdf01000!FxSelfManagedIoMachine::Flush+0xb [minkernel\wdf\framework\shared\inc\private\common\FxSelfManagedIoStateMachine.hpp @ 157]
15 ffffa600`f0b85260 fffff800`2f2437e8 Wdf01000!FxPkgPnp::PnpCleanupForRemove+0xa6 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 2265]
16 ffffa600`f0b85290 fffff800`2f1dd671 Wdf01000!FxPkgPnp::PnpEventRemovingDisableInterfaces+0x18 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 2335]
17 ffffa600`f0b852c0 fffff800`2f1dd381 Wdf01000!FxPkgPnp::PnpEnterNewState+0x125 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 1240]
18 ffffa600`f0b85360 fffff800`2f1dd1c7 Wdf01000!FxPkgPnp::PnpProcessEventInner+0xd1 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 1154]
19 ffffa600`f0b853e0 fffff800`2f1ddca6 Wdf01000!FxPkgPnp::PnpProcessEvent+0x153 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 935]
1a ffffa600`f0b85470 fffff800`2f1fd2e3 Wdf01000!FxPkgPnp::_PnpRemoveDevice+0xa6 [minkernel\wdf\framework\shared\irphandlers\pnp\fxpkgpnp.cpp @ 2603]
1b ffffa600`f0b854e0 fffff800`2f1e72e2 Wdf01000!FxPkgPnp::Dispatch+0x103 [minkernel\wdf\framework\shared\irphandlers\pnp\fxpkgpnp.cpp @ 794]
1c (Inline Function) --------`-------- Wdf01000!DispatchWorker+0xea [minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1587]
1d (Inline Function) --------`-------- Wdf01000!FxDevice::Dispatch+0xf3 [minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1601]
1e ffffa600`f0b85550 fffff800`9ce3650d Wdf01000!FxDevice::DispatchWithLock+0x232 [minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1445]
1f ffffa600`f0b855b0 fffff800`9d43ac0c nt!IofCallDriver+0xcd
20 ffffa600`f0b855f0 fffff800`9d5af446 nt!IopSynchronousCall+0xf8
21 ffffa600`f0b85660 fffff800`9d0a326c nt!IopRemoveDevice+0xe2 // Kaldırma IRP'si yollanıyor
22 ffffa600`f0b85710 fffff800`9d67386d nt!PnpRemoveLockedDeviceNode+0x234 // Bir aygıt kaldırılıyor
23 ffffa600`f0b85770 fffff800`9d67367d nt!PnpDeleteLockedDeviceNode+0x65
24 ffffa600`f0b857b0 fffff800`9d6f6f62 nt!PnpDeleteLockedDeviceNodes+0x109
25 ffffa600`f0b85840 fffff800`9d627b1f nt!PnpProcessQueryRemoveAndEject+0x2c167a
26 ffffa600`f0b85920 fffff800`9d56fe0e nt!PnpProcessTargetDeviceEvent+0xe7
27 ffffa600`f0b85950 fffff800`9cf386bc nt!PnpDeviceEventWorker+0x28e // Plug and Play işleyicisi bir görevi işliyor
28 ffffa600`f0b859d0 fffff800`9d097ffa nt!ExpWorkerThread+0x5ec
29 ffffa600`f0b85bb0 fffff800`9d2a5774 nt!PspSystemThreadStartup+0x5a // Çekirdeklerde çalışan iş parçacıkları kaldırılıyor
2a ffffa600`f0b85c00 00000000`00000000 nt!KiStartSystemThread+0x34 // Sistem NT'e geçiş yapıp başlıyor
Zaten gördüğümüz gibi sistem açıkça olay örgüsünü veriyor. En alttan en üste doğru okunduğunda bir olay örgüsü gibi cihaz kaldırma sürecini anlatıyor. Önce bir sistem worker Thread'i başlatılıyor ve bu thread, PnP alt sisteminde cihaz olaylarını işlemek üzere çalışıyor. Thread'e iletilen görev, bir cihazın kaldırılması yani remove etme olayı oluyor. Bu noktada PnP, ilgili cihaz Node'unu kilitliyor, kaldırılmak üzere işliyor ve
pnpremovelockeddevicenode üzerinden cihazın Stack'ten çıkartılması sürecine giriyor. Ardından ıopremovedevice çağrılarıyla ırp sistemi üzerinden kontrol wdf Framework'e (wdf01000) devrediliyor. Framework burada cihazın
PnP remove state machine'ini işletiyor; yani önce cihaz arayüzlerini devre dışı bırakıyor, sonra self-managed I/O'ları flush ediyor, ardından tüm I/O kuyruklarını purge etmeye başlıyor. Purge sırasında kuyruktaki istekler iptal edilip tamamlanıyor.
Bu noktada asıl çökme sebebine bakılıp stack yığının wdf kısmı sonrasına bakılırsa orada patlıyor, yani:
İlk olarak Bluetooth sürücüsünün kendi clean up süreci sonrası zaten wdf ile bir istek tamamlama ve bunu ıop API'sine devretme döngüsü görülüyor,
IoCompleteRequest() işlevini çağırarak bir ırp'yi tamamlamaya çalışıyor,
ancak bu ırp zaten daha önce başka bir sürücü (veya aynı sürücü) tarafından tamamlanmış durumda. aynı ırp'nin iki kez tamamlanması sistemde bellek bozulması yaratacak bir durumdur. Bunu wdf ya da direkt olarak BT sürücüsü clean up sürecinde yapmış olabilir... Ki iki seçenek de BT sürücüsüne doğrudan yol çizmiş oluyor...
İlgili ırp paketlerine bakınca herhangi bir veriye ulaşamadım...
Rich (BB code):
15: kd> !irp 0xffff950f2e9e6010
Irp is active with 25 stacks 25 is current (= 0xffff950f2e9e67a0)
No Mdl: No System Buffer: Thread ffff950f28265380: Irp stack trace.
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
Bunun Microsoft'un temel BT sürücüsünün patlamasından dolayı kaynaklandığına inanıyorum. Aynı şekilde kilit Node'lardan da aygıta ulaşabiliyoruz...
Rich (BB code):
15: kd> !devnode 0xffff950f427f1b70
DevNode 0xffff950f427f1b70 for PDO 0xffff950f48c15060
Parent 0xffff950f1896daf0 Sibling 0xffff950f6848d4d0 Child 0xffff950f42df0bb0
InterfaceType 0 Bus Number 0
InstancePath is "BTHENUM\{0000111f-0000-1000-8000-00805f9b34fb}_VID&00010075_PID&0100\9&2f4ad928&0&54DD4F32FA45_C00000000"
ServiceName is "BthHFEnum"
State = DeviceNodeQueryRemoved (0x312)
Sürücünün
DeviceNodeQueryRemoved durumunda olduğu da görülüyor. Bu direkt olarak 3.taraf bir sürücüden ziyade direkt bir Microsoft sürücüsü olan bu,
Bluetooth hands-Free profile (hfp) Audio gateway guıd yapısına işaret olduğunu görebiliyoruz ki bu sorunun BT üzerinden patladığının kanıtı. Tabii ki de bu sürücüye güncelleme atamayız. Dosyada direkt bir 3.taraf sürücü aramamız gerekiyor ki WinDbg'e sonradan eklenen! Blackboxpnp komutu ile ona da ulaşabiliyoruz zira dump dosyası oluşturulurken yakalanabilecek PnP aygıtları hakkındaki bilgileri görüntüleyen bir komuttur. Sistem tam da bu yüzden çöktüğünden dolayı bu dosyada işimize bir hayli yarıyor:
Rich (BB code):
15: kd> !blackboxpnp
PnpActivityId : {00000000-0000-0000-0000-000000000000}
PnpActivityTime : 134018259895442106
PnpEventInformation: 0
PnpEventInProgress : 1
PnpProblemCode : 21
PnpVetoType : 0
DeviceId : USB\VID_0489&PID_E0CD\000000000
VetoString :
Sorunlu sürücümüz MediaTek Bluetooth sürücümüz olarak görünüyor deviceıd ile. Verilen 21 hata kodunu da aşağıdaki program üzerinden yorumlayabiliyoruz...
Birçok Microsoft hata kodunun gerçekte ne anlama geldiğini anlamanıza yardımcı olur.
Eki Görüntüle 183355
cfgmgr32.h kütüphanesine dahil olan hata kodumuzda cihazın henüz hazır olmadığını gösteren bir uyarı atmış durumda. Muhtemelen çift kaldırma hatasını da bu noktadan anlayabiliyoruz.
Rich (BB code):
15: kd> lmDvmmtkbtfilterx
Browse full module list
start end module name
fffff800`3cbb0000 fffff800`3cc09000 mtkbtfilterx (deferred)
Image path: \SystemRoot\System32\DriverStore\FileRepository\mtkbtfilter.inf_amd64_56acba6f25d7988d\mtkbtfilterx.sys
Image name: mtkbtfilterx.sys
Browse all global symbols functions data
Timestamp: Mon Jun 3 20:18:43 2024 (665DFAF3)
CheckSum: 0005A6C5
ImageSize: 00059000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:
Sürücün 1 yıllık bir sürücü. Bunu güncelleyip son durumu bildir.