Large Pool 错误

最新推荐文章于 2022-11-26 16:20:47 发布
最新推荐文章于 2022-11-26 16:20:47 发布
阅读量4k 收藏 1
点赞数
分类专栏： 软件调试 文章标签： large pool 0x4E BSOD windbg
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/blog_index/article/details/17613101
版权
本文详细分析了一个Windows 7系统中的PFN_LIST_CORRUPT(4e)蓝屏问题，通过逐步排查定位到了内存释放过程中出现的错误。文章介绍了如何利用Windbg等工具进行故障诊断，最终发现是由于内存块被破坏导致的蓝屏现象。
摘要由CSDN通过智能技术生成

引用注明>> 【作者：张佩】【原文：www.yiiyee.cn/blog】

我前几个月曾经分析了一个BAD_POOL_CALLER的问题（链接），今天收到的这个dump文件，系统是Win7 X64，最后发现问题和前者非常相似，但二者的分析过程却截然不同。

引子

打开dump文件后，首先进行自动分析。蓝屏号是0x4E。

************************************************************
*                                                          *
*                        Bugcheck Analysis                 *
*                                                          *
************************************************************

PFN_LIST_CORRUPT (4e)
Typically caused by drivers passing bad memory descriptor lists (ie: calling
MmUnlockPages twice with the same list, etc).  If a kernel debugger is
available get the stack trace.
Arguments:
Arg1: 000000000000009a, 
Arg2: 000000000014e26c
Arg3: 0000000000000006
Arg4: 0000000000000002

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

BUGCHECK_STR:  0x4E_9a

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff8000495b9ef to fffff800048ccbc0

STACK_TEXT:
... nt!KeBugCheckEx
... nt!MiBadRefCount+0x4f
... nt!MiFreePoolPages+0xa8b
... nt!ExFreePoolWithTag+0x7c7
... TestModule!MemMgr::Free+0x77 
//省略若干TestModule的调用帧
... nt!PopIrpWorker+0x3c5
... nt!PspSystemThreadStartup+0x5a
... nt!KxStartSystemThread+0x16

从Windbg的帮助文档中，找到0x4E相关的内容，根据第一个参数值0x9A，拿到下面的一些信息。

Parameter 1

Parameter 2

Parameter 3

Parameter 4

Cause of Error

0x9APage frame numberCurrent page stateThe reference count of the entry that is being removedA driver attempted to free a page that is still locked for IO.

驱动试图释放一个仍然被锁定的页。到目前为止，我对这个描述还是不太清楚。

内存分析

从调用栈看，出问题的时候，驱动程序正在调用ExFreePoolWithTag来释放一个内存块。加载符号文件，通过进一步分析，我发现正在释放的是一个维度为4的指针数组里面的第三个成员指针所指向的内存。前面两个指针所指向的内存已经释放成功，并且指针已经清零。剩下的两个指针值如下：

Pointer 2 = 0xfffffa80`04c6c000
pointer 3 = 0xfffffa80`04c8d000

分别对这两个指针使用!pool命令进行分析。如果!pool命令还能够认识它们，说明内存块相关的结构体没有被破坏。否则就是内存块被破坏了。

0: kd> !pool 0xfffffa80`04c6c000
Pool page fffffa8004c6c000 region is Nonpaged pool
fffffa8004c6c000 is not a valid large pool allocation, checking large session pool...
fffffa8004c6c000 is not a valid small pool allocation, checking large pool...
unable to get pool big page table - either wrong symbols or pool tagging is disabled
fffffa8004c6c000 is freed (or corrupt) pool
Bad allocation size @fffffa8004c6c000, zero is invalid

***
*** An error (or corruption) in the pool was detected;
*** Attempting to diagnose the problem.
***
*** Use !poolval fffffa8004c6c000 for more details.

Pool page [ fffffa8004c6c000 ] is __inVALID.

Analyzing linked list...
[ fffffa8004c6c000 --> fffffa8004c6c010 (size = 0x10 bytes)]: Corrupt region

Scanning for single bit errors...

None found

0: kd> !pool 0xfffffa80`04c8d000
Pool page fffffa8004c8d000 region is Nonpaged pool
*fffffa8004c8d000 : large page allocation, Tag is TAG6, size is 0x4020 bytes

两个指针的分析结果，第一个分析不出任何结果，第二个则看上去是正确的。为了确定第二个不是“碰巧”正确的，可确认一下TAG6这个内存分配时指定的tag，如果确实有的话，就基本可认为不是“碰巧”的了。

第一个内存块已经被破坏了，并且这时候，我已经确认，指针列表中的4个内存缓冲区的size都是一样的。所以知道第一个pool块的size也是0x4020字节。

我此时首先想到的是，为什么4个pool memory，看上去只有第三个被破坏了。因为前面两个已经被成功释放掉了，第四个也是好的。这有点奇怪。在没有进一步的资料前，我只能认为这4个pool memory是用在不同的地方，而第三个是碰巧被破坏了。后来的事实也证明，通过这个途径我不可能找到任何突破口。好在很快也就放弃了。

Large Pool

上一次我通过使用POOL_HEADER结构体来查看被破坏的pool块。但这一次，这个办法不能用。原因是这次内存块的大小超过了一个页面长度(定义为PAGE_SIZE，即4K字节)。

根据系统的定义（见MSDN），如果申请的内存块size < PAGE_SIZE,系统会在一个内存页中分配，不会跨越页边界。举例说，如果有一个0x20字节的内存申请请求，系统不会把page1尾巴上的0x10字节和page2前面的0x10字节拼在一起返回给申请者；只会把page2前面的0x20字节返回给调用者。

如果申请的size > PAGE_SIZE，系统怎么做的呢？假设现在用户准备申请5000字节（4K+4）的内存块，它恰好比一个page多4个字节。系统会以4K为边界，找到相邻的两个空闲页，将起始地址返回给申请者。PAGE1的全部和PAGE2的前面部分，由申请者使用；PAGE2尾部的部分，系统另做他用。在这里，我们把这种大内存块称为：Large Pool。

和普通pool块不同，large pool块不使用POOL_HEADER结构体来维护内存块的大小。所以这次我不能从POOL_HEADER入手，这正是困难所在。通过网上搜索，我发现了MSDN BLOG上的这篇文章。它介绍了一种查看large pool块完整性的方法。

在large pool块的尾部，系统会保留两个小pool块，并把它们的tag分别设置为Frag和Free。我估计frag是指Fragment（碎片），而Free指空闲的意思。

通过这篇文章介绍的方法，我先对正确的那个large pool块进行了测试：

0: kd> dc fffffa80`04c8d000+0x4020 L40
fffffa80`04c91020  02010000 67617246 00000000 00000000  ....Frag........
fffffa80`04c91030  00020001 65657246 00000000 00000000  ....Free........
fffffa80`04c91040  04c94040 fffffa80 04bf6040 fffffa80  @@......@`......
fffffa80`04c91050  020c0002 6c734d46 00000000 00000000  ....FMsl........

果然看到了Frag和Free这两个tag。能正确看到这两个tag，至少说明这个pool块在使用时没有发生越界的情况，否则应该会覆盖tag值（但如果只越界4个字节，也有可能，此处不考虑此种情况）。还可以对这个页使用!pool命令：

0: kd> !pool fffffa80`04c8d000+0x4020
Pool page fffffa8004c91020 region is Nonpaged pool
*fffffa8004c91020 size:   10 previous size:    0  (Allocated) *Frag
fffffa8004c91030 size:   20 previous size:   10  (Free)       Free
fffffa8004c91050 size:   c0 previous size:   20  (Allocated)  FMsl
fffffa8004c91110 size:  160 previous size:   c0  (Allocated)  Ntfx
后省略

说明这一页的前0x20个字节是large pool块的一部分。剩下的部分则可以看到开头tag为Frag和Free的特殊pool块。后面的页内存被其它模块申请。

再来看看发生错误的那个large pool块:

0: kd> dc fffffa8004c6c000+0x4020
fffffa80`04c70020  02010000 67617246 b660fdb5 4fabc845  ....Frag..`.E..O
fffffa80`04c70030  0c050003 6873534b 0538ab30 fffffa80  ....KSsh0.8.....
fffffa80`04c70040  053f6170 fffffa80 00000000 00000000  pa?.............
fffffa80`04c70050  00000001 00000001 00000000 00000000  ................
fffffa80`04c70060  000006e4 00000000 001ea6c8 00000000  ................
fffffa80`04c70070  00000000 00000000 00000032 00000001  ........2.......

0: kd> !pool fffffa8004c6c000+0x4000
Pool page fffffa8004c70000 region is Nonpaged pool
*fffffa8004c70000 size:   30 previous size:    0  (Free)      *Free
fffffa8004c70030 size:   50 previous size:   30  (Free )  KSsh Process: fffffa800538ab30
fffffa8004c70080 size:   80 previous size:   50  (Free )  Even (Protected)
fffffa8004c70100 size:  1a0 previous size:   80  (Free)       None
fffffa8004c702a0 size:   50 previous size:  1a0  (Free )  VadS
fffffa8004c702f0 size:   c0 previous size:   50  (Allocated)  FMsl
fffffa8004c703b0 size:   c0 previous size:   c0  (Free)       CcPL

可以看到被破坏的痕迹：Frag后面没有Free这个tag，而是tag为KSsh的pool块。这说明large pool 块被破坏了。而最可能的破坏原由就是缓冲区溢出。

后记

这时候，还有一个较好的办法可证实是不是缓冲区溢出：把指定pool块的长度增大后，再测试。我建议把申请的size增加到0x5000字节，其它地方不动。代码逻辑仍然把它当做只有0x4020字节来用。这个问题原本比较容易做出来，但做了这样的改动后，经过两天的测试，再也没有蓝屏。从侧面证实了缓冲区溢出的可能。对我而言，问题至此就算解决了。

另外还有两个悬疑。第一是为什么这个问题被报成0xCE错误，即试图释放被锁定的内存。我个人的理解是，系统在释放pool块时，最后一个page已经被别的模块锁定或挪作他用，系统坚持释放而导致错误。

第二个问题是，系统既然不使用POOL_HEADER结构体，到底是如何维护large pool块的？我在网上查找large page/large pool关键字，暂时还没有得到满意的结果。

参考：

Stop 0x19 in a Large Pool Allocation
MSDN: ExAllocatePoolWithTag

张佩
关注
专栏目录
oracle错误一览表
03-04
### Oracle错误一览表详解 #### 1. ORA-00001: 违反唯一约束条件 - **描述**: 当尝试插入一个已经存在于唯一索引中的值时触发此错误。 - **解决方法**: 检查并确认数据是否符合唯一性要求，或者调整表结构来移除或...
ExFreePoolWithTag函数irql蓝屏
DaiCharlie的博客
10-12 402
ExFreePoolWithTag函数irql蓝屏
MDL 内存描述符链表
ma_de_hao_mei_le的博客
08-02 295
mdl全称MemoryDescriptorLists。它用于描述位于虚拟内存中的一段buffer在物理内存中的布局。如果你不知道什么是虚拟内存。
Oracle错误代码大全
01-24
* ORA-00092: LARGE_POOL_SIZE 必须大于 LARGE_POOL_MIN_ALLOC * ORA-00093: 必须介于 和 之间 * ORA-00094: 要求整数值 * ORA-00096: 值 对参数 无效，它必须来自 之间 * ORA-00097: 使用 Oracle SQL 特性不在 SQL...
oracle 错误一览表
08-12
- **解决方法**：增加 LARGE_POOL_SIZE 的值或减少 LARGE_POOL_MIN_ALLOC 的值。 #### ORA-00093: Parameter values do not match - **描述**：参数值不匹配。 - **解决方法**：确认参数值一致。 #### ORA-00094: ...
UE4资源及内存控制台命令
weixin_36369675的博客
11-26 2806
1024x1024 (2731 KB, 0), 1024x1024 (2731 KB), PF_ASTC_8x8, TEXTUREGROUP_WorldDiffuse, /Game/Assets/Environment/TexArray/T_Env_TexArray_DH.T_Env_TexArray_DH, NO, 0, 8, 8 // 为一张1024x1024的TextureArray（纹理数组）注2：BackBuffer（2336x1080，PF_B8G8R8A8）占9855KB；
文件共享服务器蓝屏,我的电脑是WIN7的，从网上邻居共享电脑XP上复制文件会一直蓝屏（蓝屏4次了），而且 - Microsoft Community...
weixin_35942678的博客
08-04 1185
这是WINDBG的一次输出。。Loading Dump File [C:\Windows\Minidump\122110-43664-01.dmp]Mini Kernel Dump File: Only registers and stack trace are availableWARNING: Whitespace at end of path elementSymbol search pat...
中国移动网站控件引发的蓝屏问题分析
weixin_30546189的博客
02-26 741
本周四（2月23日），我接到了我们同事的一个奇怪的蓝屏case，据他回忆，他最近没有安装任何软件和驱动，也没有更改计算机的硬件配置，除了Windows后台进行的自动更新之外，他实在想不起来到底对计算机有什么额外的改变。可是突然，就从前一天23日周三晚上起，他的计算机就开始蓝屏，重启之后，进系统之前就会蓝屏，或者进了系统用不到一会儿也会蓝屏。因此，他怀疑是硬件（如内存）故障导致的，或者是 Windo...
MDL（memory descriptor list）
多媒体编程、网络编程、系统编程、网络安全编程、驱动编程
03-24 1236
typedef struct _MDL { struct _MDL *Next; CSHORT Size; CSHORT MdlFlags; struct _EPROCESS *Process; PVOID MappedSystemVa; PVOID StartVa; ULONG ByteCount; ULONG ByteOffset; } MDL, *PMDL; MDL只
Windows 文件过滤驱动经验总结
sqqsongqiqi的专栏
01-05 539
原文地址 http://www.dnjsb.com/xitong/win-xp/7930.html   1、获得文件全路径以及判断时机 除在所有 IRP_MJ_XXX 之前自己从头创建 IRP 发送到下层设备查询全路径外，不要尝试在 IRP_MJ_CREATE 以外的地方获得全路径，因为只有在 IRP_MJ_CREATE 中才会使用 ObCreateObject() 来建立一个有效的 FIL
11g新特性recover corruption list
weixin_34362991的博客
03-19 512
11g新特性RMAN语法recover corruption list是为了简化数据坏块的修复，在11g中recover corruption块时不需要一一指定数据文件名字了，只要是在v$database_block_corruption视图中记录的坏块，只要使用了 corruption list语法，都会试图修复。   下面我们使用recover .. clear命令手动造成个别数据块坏块，...
CREATE LARGE TABLESPACE AISCOMMON PAGESIZE 32K MANAGED BY DATABASE USING ( file '/home/data/UFAUD/raiscommon' 1G ) AUTO RESIZE YES EXTENTSIZE 32 OVERHEAD 7.5 PREFETCHSIZE 32 TRANSFERRATE 0.06 BUFFERPOOL aispool NO FILE SYSTEM CACHING DROPPED TABLE RECOVERY ON 哪里有语法错误
最新发布
07-08
在你给出的语句中，我没有发现明显的语法错误。但是，请注意以下几点： 1. `AISCOMMON` 应该是你想要创建的表空间的名称，确保它符合数据库命名规范。 2. 确保指定的文件路径 `/home/data/UFAUD/raiscommon` 是有效的，并且数据库有访问权限。 3. 检查文件大小的指定部分 `1G` 是否符合数据库的要求。 4. 确保所使用的参数值，如 `PAGESIZE`、`EXTENTSIZE`、`OVERHEAD`、`PREFETCHSIZE`、`TRANSFERRATE`、`BUFFERPOOL` 等都是有效的并与数据库配置相符。 5. 检查是否需要在表空间名之后指定数据库名称或其他参数。 请注意，我只能提供基于常见经验的建议，并不能保证完全正确，具体情况还需根据你所使用的数据库版本和配置进行进一步调试和确认。建议参考相关数据库文档或咨询专业人士以获得准确的答案。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值