如何洞察 C# 程序的 GDI 句柄泄露
2023/6/12 14:22:05
本文主要是介绍如何洞察 C# 程序的 GDI 句柄泄露,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
一:背景
1. 讲故事
前段时间有位朋友找到我,说他的程序界面操作起来很慢并且卡顿等一些不正常现象,从任务管理器看了下 GDI句柄
已经到 1w 了,一时也找不出什么代码中哪里有问题,让我帮忙看下,其实这种问题看内存dump作用不是很大,主要是写脚本很麻烦,这一篇我们就来简单聊聊如何洞察此类问题。
二:如何洞察泄露
1. 一个测试小案例
在 windows 上gdi的句柄类型有很多,比如:pen
,font
,bitmap
,device
等,具体可以网上搜一下,这里我就造一个 bitmap 的句柄泄露,参考代码如下:
private void button1_Click(object sender, EventArgs e) { Task.Factory.StartNew(() => { Bitmap bmp = new Bitmap(100, 100); for (int i = 0; i < 10000; i++) { bmp.GetHbitmap(); Thread.Sleep(100); } }); }
代码非常简单,大概 100ms
泄露一个 bitmap 句柄,接下来把程序跑起来点击 Button_Click
按钮,然后上瑞士军刀 WinDbg
附加进程。
2. 如何观察GDI泄露
观察 GDI句柄
是否异常,最简单的方法就是看任务管理器中的 GDI对象
一列,截图如下:
但这里有一个问题,你只知道有一个总数,并不知道是哪种句柄类型的泄露,比如是:bitmap? font ?device? 对吧。
那怎么办呢?这就需要考验一点基础知识了,你要知道 GDI 的句柄表(GDI Shared Handle Table)是维护在用户态的虚拟地址上,区别于维护在内核中的 ObjectTable,可以用 !address 验证下。
0:011> !address BaseAddress EndAddress+1 RegionSize Type State Protect Usage -------------------------------------------------------------------------------------------------------------------------- + 294`d1500000 294`d1681000 0`00181000 MEM_MAPPED MEM_COMMIT PAGE_READONLY Other [GDI Shared Handle Table] 0:011> !address 294`d1500000 Usage: Other Base Address: 00000294`d1500000 End Address: 00000294`d1681000 Region Size: 00000000`00181000 ( 1.504 MB) State: 00001000 MEM_COMMIT Protect: 00000002 PAGE_READONLY Type: 00040000 MEM_MAPPED Allocation Base: 00000294`d1500000 Allocation Protect: 00000002 PAGE_READONLY Additional info: GDI Shared Handle Table Content source: 1 (target), length: 181000
在这 1.5M
的虚拟地址段中就雪藏了我们要找的各句柄的统计信息,但要挖它需要写脚本,再配合 GDICELL
结构体,分组其中的 wType
句柄类型。
typedef struct { PVOID64 pKernelAddress; // 0x00 USHORT wProcessId; // 0x08 USHORT wCount; // 0x0a USHORT wUpper; // 0x0c USHORT wType; // 0x0e PVOID64 pUserAddress; // 0x10 } GDICell; // sizeof = 0x18
虽然可以手工分组出来,但这种问题你肯定不是第一个遇到,早有人写了一个工具来解决这类问题,它就是 GDIView.exe
,大家可以网上搜一下。
打开 GDIView 之后,可以很清楚的看到 WindowsFormsApp1
程序中各个句柄的统计信息,并且 type=Bitmap
是非常可疑的,截图如下:
知道了是 Bitmap
的句柄泄露,定位的范围一下子就小了很多,长舒一口气。
3. 如何寻找 Bitmap 的底层函数
熟悉 Windows 的朋友应该都知道 GDI 的逻辑是封装在底层的 GDI32.dll
中,模块信息如下:
0:012> lmvm gdi32 Browse full module list start end module name 00007ff9`b0c80000 00007ff9`b0cab000 GDI32 (deferred) Image path: C:\windows\System32\GDI32.dll Image name: GDI32.dll Browse all global symbols functions data Image was built with /Brepro flag. Timestamp: 3EE1D71F (This is a reproducible build file hash, not a timestamp) CheckSum: 0002B228 ImageSize: 0002B000 File version: 10.0.19041.2130 Product version: 10.0.19041.2130 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04b0 Information from resource tables: CompanyName: Microsoft Corporation ProductName: Microsoft® Windows® Operating System InternalName: gdi32 OriginalFilename: gdi32 ProductVersion: 10.0.19041.2130 FileVersion: 10.0.19041.2130 (WinBuild.160101.0800) FileDescription: GDI Client DLL LegalCopyright: © Microsoft Corporation. All rights reserved.
言外之意就是可以在 GDI32
模块中下方法断点,这时候问题就来了,到底搁哪个方法下呢?这个只能求助 MSDN 了,功夫不负有心人,找到了一篇很老的文章:https://learn.microsoft.com/en-us/archive/msdn-magazine/2003/january/detect-and-plug-gdi-leaks-with-two-powerful-tools-for-windows-xp
从图中看记载的非常详细,但我亲自观察下来有些方法找不到,所以只能做个参考吧,不过在 Windbg 中提供了一个非常好的 bm
命令,它可以对方法名进行 模糊断点
,比如 bm gdi32!*Bitmap*
就可以一口气下 45 个断点。
0:012> bm gdi32!*Bitmap* "? @$tid; k; gc" 0: 00007ff9`b0c86f7c @!"GDI32!IsCreateBitmapPresent" 1: 00007ff9`b0c87216 @!"GDI32!_imp_load_CreateDIBitmap" 2: 00007ff9`b0c8906c @!"GDI32!_imp_load_DwmCreatedBitmapRemotingOutput" 3: 00007ff9`b0c86460 @!"GDI32!NtGdiGetBitmapDpiScaleValue" 4: 00007ff9`b0c8850c @!"GDI32!_imp_load_ClearBitmapAttributes" 5: 00007ff9`b0c88745 @!"GDI32!_imp_load_CreateDiscardableBitmap" 6: 00007ff9`b0c84470 @!"GDI32!CreateBitmapStub" ... 42: 00007ff9`b0c8713e @!"GDI32!_imp_load_GetBitmapBits" 43: 00007ff9`b0c89580 @!"GDI32!GdiConvertBitmapV5" 44: 00007ff9`b0c89080 @!"GDI32!DwmCreatedBitmapRemotingOutput" 45: 00007ff9`b0c8aaac @!"GDI32!_imp_load_SetBitmapDimensionEx" 0:007> .bpcmds bu0 @!"GDI32!IsCreateCompatibleBitmapPresent" "? @$tid; k; gc"; bu1 @!"GDI32!_imp_load_CreateDIBitmap" "? @$tid; k; gc"; bu2 @!"GDI32!_imp_load_DwmCreatedBitmapRemotingOutput" "? @$tid; k; gc"; bu3 @!"GDI32!NtGdiGetBitmapDpiScaleValue" "? @$tid; k; gc"; bu4 @!"GDI32!_imp_load_ClearBitmapAttributes" "? @$tid; k; gc"; bu5 @!"GDI32!_imp_load_CreateDiscardableBitmap" "? @$tid; k; gc"; ...
天网恢恢,疏而不漏,肯定会命中其中一个的,接下来继续 g 让程序跑起来,你会看到有大量的方法被命中,并且仔细观察会有一个用户态函数 <button1_Click>b__1_0
,截图如下:
此时这个托管函数就是重点怀疑对象,也就很轻松的找到问题之所在,有些朋友可能要问,这样重复的信息是不是会很多,那当然了,大家可以根据输出信息做下一步的洞察,比如上面的 gdiplus!CopyOnWriteBitmap::CreateHBITMAP
函数会特别多,这时候可以重新 bp 来缩小范围,对吧!参考代码如下:
0:010> bc * 0:010> bp gdiplus!CopyOnWriteBitmap::CreateHBITMAP "? @$tid; k; gc" 0:010> g Evaluate expression: 15768 = 00000000`00003d98 # Child-SP RetAddr Call Site 00 000000bb`041febd8 00007ff9`9df0a21f gdiplus!CopyOnWriteBitmap::CreateHBITMAP 01 000000bb`041febe0 00007ff9`9df0a19a gdiplus!GpBitmap::CreateHBITMAP+0x3b 02 000000bb`041fec10 00007ff9`72442c61 gdiplus!GdipCreateHBITMAPFromBitmap+0xaa 03 000000bb`041fec50 00007ff9`72439471 System_Drawing_ni+0x72c61 04 000000bb`041fed10 00007ff9`7243940a System_Drawing_ni!System.Drawing.Bitmap.GetHbitmap+0x51 05 000000bb`041fed70 00007ff9`36d02a75 System_Drawing_ni!System.Drawing.Bitmap.GetHbitmap+0x7a 06 000000bb`041fede0 00007ff9`8d597a47 WindowsFormsApp1!WindowsFormsApp1.Form1.<>c.<button1_Click>b__1_0+0x75 ...
三:总结
说实话,找到程序的 GDI句柄泄露
的前因后果难度系数还是蛮高的,在没有系统科学的工具和基础知识之前,花费几天的时间排查这个问题是很正常的,相信这篇文章给后来人少踩坑吧。
这篇关于如何洞察 C# 程序的 GDI 句柄泄露的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2022-03-01沐雪多租宝商城源码从.NetCore3.1升级到.Net6的步骤
- 2024-12-06使用Microsoft.Extensions.AI在.NET中生成嵌入向量
- 2024-11-18微软研究:RAG系统的四个层次提升理解与回答能力
- 2024-11-15C#中怎么从PEM格式的证书中提取公钥?-icode9专业技术文章分享
- 2024-11-14云架构设计——如何用diagrams.net绘制专业的AWS架构图?
- 2024-05-08首个适配Visual Studio平台的国产智能编程助手CodeGeeX正式上线!C#程序员必备效率神器!
- 2024-03-30C#设计模式之十六迭代器模式(Iterator Pattern)【行为型】
- 2024-03-29c# datetime tryparse
- 2024-02-21list find index c#
- 2024-01-24convert toint32 c#