Rich (BB code):
KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common BugCheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffff80000003, The exception code that was not handled
Arg2: fffff807dfe79470, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: fffff807dfe79470, Parameter 1 of the exception
Gördüğümüz gibi oldukça genel bir hata kontrolümüz var. Bunlar, kendileri için işleyici yazılmamış ya da yapılandırılmış istisna işleme kullanılarak yakalanamayan istisnaların atılmasından kaynaklanıyor. Örneğin, PageFault, try-catch deyimi ile ele alınamayan bir istisnadır.
İşlenmeyen istisna nedir?
Rich (BB code):
0: kd> !error 80000003
Error code: (HRESULT) 0x80000003 (2147483651) - Bir veya daha fazla bağımsız değişken geçersiz
İstisnaya sebep olan fonksiyon nedir?
Rich (BB code):
0: kd> ln fffff807dfe79470
Browse module
Set bu breakpoint
(fffff807`dfe79470) nt!DbgBreakPoint | (fffff807`dfe79480) nt!DbgUserBreakPoint
Exact matches:
Microsoft'un bunun hakkındaki
belgelemesine bakarsak:
The DbgBreakPoint routine is the kernel-mode equivalent of DebugBreak.
This routine raises an exception that is handled by the kernel debugger if one is installed; otherwise, it is handled by the debug system. If a debugger is not connected to the system, the exception can be handled in the standard way.
In kernel mode, a break exception that is not handled will cause a bug check. You can, however, connect a kernel-mode debugger to a target computer that has stopped responding and has kernel debugging enabled.
Bu neden sistemin mavi ekran verdiğini açıklıyor. Lakin ne yüzünden verdiğini açıklamıyor, Yığıtlara bakarak bunu çözebiliriz;
Rich (BB code):
0: kd> k
# Child-SP RetAddr Call Site
00 fffff807`71b950c8 fffff807`dff2a112 nt!KeBugCheckEx
01 fffff807`71b950d0 fffff807`e003d172 nt!KiFatalExceptionHandler+0x22
02 fffff807`71b95110 fffff807`dfd52302 nt!RtlpExecuteHandlerForException+0x12
03 fffff807`71b95140 fffff807`dfd53469 nt!RtlDispatchException+0x2d2
04 fffff807`71b958a0 fffff807`e0033d92 nt!KiDispatchException+0xac9
05 fffff807`71b95fb0 fffff807`e0033d60 nt!KxExceptionDispatchOnExceptionStack+0x12
06 fffff807`71b84128 fffff807`e0047c3e nt!KiExceptionDispatchOnExceptionStackContinue
07 fffff807`71b84130 fffff807`e003fe9b nt!KiExceptionDispatch+0x13e
08 fffff807`71b84310 fffff807`dfe79471 nt!KiBreakpointTrap+0x35b < Çökme
09 fffff807`71b844a8 fffff807`71532260 nt!DbgBreakPoint+0x1
0a (Inline Function) --------`-------- Wdf01000!Mx::MxDbgBreakPoint+0xc
0b fffff807`71b844b0 fffff807`714c6f0d Wdf01000!FxVerifierDbgBreakPoint+0x50
0c (Inline Function) --------`-------- Wdf01000!FxVerifierCheckIrqlLevel+0xc43 < Doğrulama kontrolü
0d fffff807`71b844f0 fffff807`65932fab Wdf01000!imp_WdfUsbTargetDeviceSendControlTransferSynchronously+0xf7d
0e fffff807`71b848c0 00000000`00000000 sshid+0x2fab
Verifier'in önemini şimdi anlamış olduk. Sorunun sebebini ilk çökmede verdi kendi dosyası olmasa bile. SteelSeries sürücüsü dediğim gibi, en başından beri. Bir USB aygıtına Senkranizasyon kontrolü yapılıyor ve burada bir breakpoint yakalıyor sistem/Verifier. Nerede çöktüğümüzü ve ayrıca önceden çağrılan sorunlu bir sürücüyü görebiliyoruz kırmızı ile. Yığına dikkat edersen
Wdf01000!FxVerifierCheckIrqlLevel ve
Wdf01000!FxVerifierDbgBreakPoint. Artık kesme noktasının neden çağrıldığını biliyoruz,
FxVerifierCheckIrqlLevel işlevi tarafından bir hata ayıklayıcının içeri girmesini ve geliştiricinin sürücüsünün neden çöktüğünü görmesini sağlamak için kullanılıyor. SSHID, yanlış IRQL düzeyinde çağırılıyor bu da çökmeye direkt olarak sebep olması için yeterlidir çünkü IRQL 2 düzeyinde Kernel bir sürücünün herhangi bir işlevinin yaptığı bir yanlış sistemi çökertecek düzeyde olur.
Rich (BB code):
0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 2 (DISPATCH_LEVEL)
Sürücünün doğrulama kontrolünde başarısız olduğunu ve bu nedenle kesme noktasının çağrıldığını varsayabiliriz, ancak bunu
!wdflogdump komutunu kullanarak kesin olarak doğrulayabilirdik ama,
Dosya da her zamanki gibi yetersiz:[
Rich (BB code):
0: kd> !wdflogdump sshid
ReadListEntry failed
Warning: It looks like you're using the WDF debugger extension on a WDM
driver. Framework logs will not be available
Muhtemelen karşılaşacağımız hata bu olacaktı:
Rich (BB code):
38: FxPkgPnp::HandleQueryBusRelations - WDFDEVICE 00001BF908FB2F68 returning 3 devices in relations FFFF820D1551C5D0
39: FxVerifierCheckIrqlLevel - Called at wrong IRQL; at level 2, should be at level 0
Sshid, açıkça çökmeye sebep oluyor. SS klavye sürücüsünü kaldırmalısın. Aygıt yöneticisi üzerinde bulabiliyor olman lazım ilgili sürücüyü, HID olmadan SS Keyboard aygıtı olarak ekli olması lazım...
Rich (BB code):
0: kd> lmvmsshid
Browse full module list
start end module name
fffff807`65930000 fffff807`6593d000 sshid T (no symbols)
Loaded symbol image file: sshid.sys
Image path: sshid.sys
Image name: sshid.sys
Browse all global symbols functions data
Timestamp: Thu Feb 24 06:09:08 2022 (6216F6D4)
CheckSum: 00018401
ImageSize: 0000D000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:
drive.google.com
Eninde sonunda o noktaya gelecekleri belli ne yazık ki. Ayrıntılı bir şekilde yardım edemezler genelde çünkü çok fazla kişi iletişime geçiyordur. Bekleyebilirsin tabii ki. Konuyu henüz kapatmadım, emin olmak istiyorum ben de en az senin kadar.
