【原创】FltSendMessage蓝屏分析

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的.

时间: 2024-07-30 01:10:21

【原创】FltSendMessage蓝屏分析的相关文章

windows蓝屏分析

大半夜收到此类信息,应该是让所有系统管理员最头大的事情了 首先我快速通过iDRAC,发现服务器发生了重启操作,并得到相关日志信息 通过Dell的官方解释,确定了该问题是OS层面的异常导致.打开Windows Event Log,使用时间&严重程度进行筛选,我们发现了如下信息: 由此,我猜测此次事故由于0x7a类型的蓝屏错误导致!为了证实这种猜想以及继续分析根本原因,借助Microsoft提供的Debug工具对DUMP文件进行分析,内容如下: 通过初步bugcheck,基本确定了我的猜测,再结合c

Windows蓝屏了怎么办?

说到蓝屏,可能很多朋友会深恶痛绝,颇多诟病,甚至还有歪诗曰"补丁与漏洞齐飞,死机共蓝屏一色"... 其实这是一种误解,蓝屏实际上是Windows的"维稳"手段,当发生严重故障时,就要壮士断腕.挥泪斩马谡.而不能欲盖弥彰.阻止上访.以下是盆盆曾经在电梯里看到的蓝屏.嗯,说到电梯,华来四里的程尊华老师曾经和盆盆说过,他小时的理想就是:坐电梯上下楼.坐地铁上下班.现在完全可以问一句:成功其庶几乎? 以下是一个比较著名的Windows蓝屏场景,您懂的... 一提到蓝屏,印象

蓝屏 Dump文件分析方法

WinDbg使用有点麻烦,还要符号表什么的.试了下,感觉显示很乱,分析的也不够全面... 试试其他的吧!今天电脑蓝屏了,就使用其dump文件测试,如下: 1.首先,最详细的,要属Osr Online这个在线分析网站了: 打开其分析地址:http://www.osronline.com/page.cfm?name=analyze 下拉,找到上传按钮(上图),将需要分析的dump文件浏览上传即可...dump文件一般在C:\www\minidump下 分析完成后生成的内容非常多: 主要看第一个Pri

揪出“凶手”——实战WinDbg分析电脑蓝屏原因

http://www.appinn.com/blue-screen-search-code/ 蓝屏代码查询器 – 找出蓝屏的元凶 11 文章标签: windows / 系统 / 蓝屏. 蓝屏代码查询器可以帮你查出引起蓝屏的故障原因并可以到微软知识库中查询解决方案,和之前的 BlueScreenView 配合是很好的蓝屏故障排除组合.@Appinn 使用时只需填入错误代码的简写即可,另外在支持中心中有关于蓝屏原因分析的文章链接,有兴趣的童鞋可以去看看..  官方网站 | 来自小众软件 http:/

使用Windbg分析蓝屏原因

序言:     当电脑频繁蓝屏时我们需要软件来查找蓝屏原因,此时可以使用Windbg软件对蓝屏文件进行分析查找原因. 工具:     1.WinDbg软件,有两种版本,可以参考我的上一篇文章:安装与配置windbg的symbol(符号) 方法/步骤:     1.首先我们要保证我们设置了蓝屏转储,这样当电脑蓝屏时,系统会以.dmp文件方式保留蓝屏故障原因,我们需要查询是否设置内存转储和蓝屏文件存放位置.右键单击桌面计算机图标--选择属性,单击高级系统设置,在启动和故障恢复栏中单击设置,在写入调试

WinDbg 分析蓝屏

最近机器老是蓝屏,看来用了4年的系统改换换了 这篇文章挺有帮助,感谢 http://support.icafe8.com/technologynews/focus/932.html WinDbg 这个工具要好好研究一下

Windows蓝屏后产生的.dmp分析原因

Windows系统电脑出现蓝屏后都会自动重启,重启后电脑屏幕会提示蓝屏的相关信息,此时如果你没有来得及查看,你也可以进入windows7的“事件查看器”(位置为:控制面板--系统和安全--管理工具--查看事件日志),在“事件查看器”中你将也会看到出错的系统信息,一般提示的信息如下: “已将转储的数据保存在: C:\Windows\MEMORY.DMP”或“C:\Windows\Minidup文件夹中的.dmp文件中.” 这些以.dmp文件是什么文件呢?它们是windows的内存转储文件,在win

YUV422蓝屏显示输出功能辅助调试

YUV422有YUYV,YVYU,UYVY,VYUY四种,以下笔者就就以UYVY为例介绍一下数据构成.因为常常要跟视频输入打交道,所以YUV422这种常见的视频信号是常常碰到的.有时候我们调试一个模块输出YUV422,然后再显示出来.非常多时候,可能没法准确推断你那个模块是不是已经正常跑起来了,跑起来来的情况下,是不是真的有数据输出,有了数据输出后来的数据究竟对不正确. 带着这些疑问,当然有非常多对策,笔者就先把这个事情一分为二,以YUV422数据为界限分两部分,假设怀疑是模块没有输出YUV42

蓝屏代码stop:0X000000EA(0X85E286B8,0X8635F210,0XF7A53CBC,0X00000001)

你这是显卡驱动问题,我把蓝屏代码都给你,以后在出现蓝屏自己看看行了. 1.0x0000000A:IRQL_NOT_LESS_OR_EQUAL ◆错误分析:主要是由问题的驱动程序.有缺陷或不兼容的硬件与软件造成的. 从技术角度讲. 表明在内核模式中存在以太高的进程内部请求级别(IRQL)访问其没有权限访问的内存地址. ◇解决方案:请用前面介绍的解决方案中的2.3.5.8.9方案尝试排除. 2.0x00000012:TRAP_CAUSE_UNKNOWN ◆错误分析:如果遇到这个错误信息, 那么很不幸