【原創】FltSendMessage藍屏分析

來源:互聯網
上載者:User

標籤:

INVALID_PROCESS_DETACH_ATTEMPT (6)
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------


CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x6

PROCESS_NAME: BAVSvc.exe

LAST_CONTROL_TRANSFER: from 80508d2f to 805376df

STACK_TEXT:
ba6e5be0 80508d2f 00000006 8a715818 00000000 nt!KeBugCheck+0x14
ba6e5c00 8062cfd8 ba6e5c18 8a715818 00000000 nt!KeUnstackDetachProcess+0x118
ba6e5c50 f745664d 8a3105e8 8a6bdbb0 00000001 nt!MmProbeAndLockProcessPages+0x6a
ba6e5d54 ba711870 8ab61818 ba71708c e4446410 fltMgr!FltSendMessage+0x1db
ba6e5dac 80576320 00000000 00000000 00000000 Bfilter!ScUnInitExcludePath
ba6e5ddc 804ec7b9 ba7118a0 00000000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

深入內部,看是什麼條件觸發的藍屏. 分析KeUnstackDetachProcess(x)裡面的關鍵程式碼片段
.text:0041D02F cmp byte ptr [esi+165h], 0
.text:0041D036 jz loc_431CA1
.text:0041D03C cmp byte ptr [esi+48h], 0
.text:0041D040 jnz loc_431CA1
.text:0041D046 lea eax, [esi+34h]
.text:0041D049 cmp [eax], eax
.text:0041D04B jnz loc_431CA1
.text:0041D051 lea eax, [esi+3Ch]
.text:0041D054 cmp [eax], eax
.text:0041D056 jnz loc_431CA1

.text:00431CA1 loc_431CA1: ; CODE XREF: KeUnstackDetachProcess(x)+3Dj
.text:00431CA1 ; KeUnstackDetachProcess(x)+47j ...
.text:00431CA1 push 6 ; BugCheckCode
.text:00431CA3 call [email protected] ; KeBugCheck(x)

可見有四個條件導致 INVALID_PROCESS_DETACH_ATTEMPT 藍屏,首先我們要排查是走到哪個分支出現問題.這裡 esi 是儲存當前線程對象的指標.
[esi+165h] 是取線程裡 ApcStateIndex 的值, 看記憶體的值
0: kd> db @esi+165 l1
8ab544ed 01
也就是ApcStateIndex的值為1,不是因為ApcStateIndex錯誤導致的藍屏,繼續[esi+48h],是取線程裡面ApcState->KernelApcInProgress的值,查看記憶體
0: kd> db @esi+48 l1
8ab543d0 00
ApcState->KernelApcInProgress的值為0,不是因為ApcState->KernelApcInProgress錯誤導致的藍屏, 繼續分析下面指令
.text:0041D046 lea eax, [esi+34h]
.text:0041D049 cmp [eax], eax
.text:0041D04B jnz loc_431CA1

0: kd> ? @esi+34
Evaluate expression: -1967832132 = 8ab543bc

0: kd> dd 8ab543bc l1
8ab543bc 8a3f6254

eax的值為 8ab543bc, [8ab543bc]的值為 8a3f6254, cmp [eax], eax 比較結果不相等導致藍屏.其實這裡就是判斷當前線程的核心APC列表是否為空白,不為空白的話就藍屏了.也就是系統往我們的線程KiInsertQueueApc插入一個核心APC,導致鏈表不為空白,在KeUnstackDetachProcess出了問題。觀察線程的線程的一些APC欄位,發現 KernelApcPending 的值為1,說明KiInsertQueueApc沒調用到KiDeliverApc, 很可能是APC 被禁止Deliver,調用ExAcquireFastMutex就可以禁止核心APC投遞.不要調用ExAcquireFastMutex應該可以解決這類問題,但現在還有一個問題: 誰會往這個調用FltSendMessage的核心線程投遞APC ?核心APC的一個主要作用是從系統空間拷貝I/O操作結果和狀態資訊到線程虛擬記憶體空間的一個緩衝中,所以有可能是FltSendMessage內部同步出現BUG.導致這個函數返回後,應用程式層再應答資料回來,會往這個DELAY線程插APC. 這種情況最有可能是應用程式層掃描出現了延遲導致.

暫時XP SP3可行的解決辦法:
1 不要在一個線程裡迴圈調用FltSendMessage
2 調用之前FltSendMessage不要調用ExAcquireFastMutex
3 只利用FltSendMessage來發送非同步訊息,就是不用等應用程式層應答結果,這樣系統是不會往我們線程插入APC的.

【原創】FltSendMessage藍屏分析

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.