焦点热议:记一次 .NET 某医疗住院系统 崩溃分析
最近收到了两起程序崩溃的dump,查了下都是经典的 double free
造成的,蛮有意思,这里就抽一篇出来分享一下经验供后面的学习者避坑吧。
windbg 带了一个自动化分析命令 !analyze -v
可以帮助我们找到崩溃时的程序指令地址以及崩溃的代码,这对我们分析问题非常有帮助。
0:090> !analyze -v******************************************************************************** ** Exception Analysis ** ********************************************************************************CONTEXT: (.ecxr)rax=00007ffec265d6e0 rbx=00000000c0000374 rcx=00000053653fe4f0rdx=00007ffec1d3e9a0 rsi=0000000000000001 rdi=00007ffed7b827f0rip=00007ffed7b1b349 rsp=00000053653fed10 rbp=000001c14fd20000 r8=000001c11957d9a0 r9=0000000000000033 r10=000001c453dbc7f0r11=00007ffeb94db004 r12=0000000000000001 r13=000001c12e8526d0r14=0000000000000000 r15=000001ce25531c60iopl=0 nv up ei pl nz na po nccs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206ntdll!RtlReportFatalFailure+0x9:00007ffe`d7b1b349 eb00 jmp ntdll!RtlReportFatalFailure+0xb (00007ffe`d7b1b34b)Resetting default scopeEXCEPTION_RECORD: (.exr -1)ExceptionAddress: 00007ffed7b1b349 (ntdll!RtlReportFatalFailure+0x0000000000000009) ExceptionCode: c0000374 ExceptionFlags: 00000001NumberParameters: 1 Parameter[0]: 00007ffed7b827f0PROCESS_NAME: w3wp.exe...
熟悉 windows ntheap 的朋友应该知道,ExceptionCode: c0000374
是经典的 堆破坏状态码,那到底是谁破坏了呢?
(相关资料图)
2. 到底是谁破坏了NT堆windows 给了 ntheap 强大的调试支持,默认开启了 Termination on corruption
破坏检测,也就是说当你使用 !heap -s
的时候会显示具体破坏的详情记录,输出如下:
0:090> !heap -s************************************************************************************************************************ NT HEAP STATS BELOW*************************************************************************************************************************************************************************************** ** HEAP ERROR DETECTED ** ***************************************************************Details:Heap address: 000001c14fd20000Error address: 000001ce25531c50Error type: HEAP_FAILURE_BLOCK_NOT_BUSYDetails: The caller performed an operation (such as a free or a size check) that is illegal on a free block.Follow-up: Check the error"s stack trace to find the culprit.Stack trace:Stack trace at 0x00007ffed7b82848 00007ffed7abe109: ntdll!RtlpLogHeapFailure+0x45 00007ffed7acbb0e: ntdll!RtlFreeHeap+0x9d3ce 00007ffeb093276f: OraOps12!ssmem_free+0xf 00007ffeb0943077: OraOps12!OpsMetFreeValCtx+0xd7 00007ffeb093cdd8: OraOps12!OpsDacDispose+0x2b8 00007ffe655e4374: +0x655e4374LFH Key : 0x5baf44f8068da60fTermination on corruption : ENABLED Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast (k) (k) (k) (k) length blocks cont. heap -------------------------------------------------------------------------------------000001c14fd20000 00000002 1021576 964388 1020020 19222 6063 166 2 82f LFH000001c14fc70000 00008000 64 4 64 2 1 1 0 0 ...
上面的 Error type: HEAP_FAILURE_BLOCK_NOT_BUSY
表示是一个 double free,从 Stack trace
看是 OpsDacDispose
方法造成的,应该和 Oracle 相关,这就比较迷了。。。
是不是托管层触发的呢?这就需要理解 Windows 独有的 SEH 异常处理机制,也就是说 Windows 的异常都会在 内核态
走一圈,画个图如下:
只要找到 t1
时刻的崩溃点,然后观察线程栈即可,代码如下:
0:090> .ecxrrax=00007ffec265d6e0 rbx=00000000c0000374 rcx=00000053653fe4f0rdx=00007ffec1d3e9a0 rsi=0000000000000001 rdi=00007ffed7b827f0rip=00007ffed7b1b349 rsp=00000053653fed10 rbp=000001c14fd20000 r8=000001c11957d9a0 r9=0000000000000033 r10=000001c453dbc7f0r11=00007ffeb94db004 r12=0000000000000001 r13=000001c12e8526d0r14=0000000000000000 r15=000001ce25531c60iopl=0 nv up ei pl nz na po nccs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206ntdll!RtlReportFatalFailure+0x9:00007ffe`d7b1b349 eb00 jmp ntdll!RtlReportFatalFailure+0xb (00007ffe`d7b1b34b)0:090> k *** Stack trace for last set context - .thread/.cxr resets it # Child-SP RetAddr Call Site00 00000053`653fed10 00007ffe`d7b1b313 ntdll!RtlReportFatalFailure+0x901 00000053`653fed60 00007ffe`d7b23b9e ntdll!RtlReportCriticalFailure+0x9702 00000053`653fee50 00007ffe`d7b23eaa ntdll!RtlpHeapHandleError+0x1203 00000053`653fee80 00007ffe`d7abe109 ntdll!RtlpHpHeapHandleError+0x7a04 00000053`653feeb0 00007ffe`d7acbb0e ntdll!RtlpLogHeapFailure+0x4505 00000053`653feee0 00007ffe`b093276f ntdll!RtlFreeHeap+0x9d3ce06 00000053`653fef80 00007ffe`b0943077 OraOps12!ssmem_free+0xf07 00000053`653fefb0 00007ffe`b093cdd8 OraOps12!OpsMetFreeValCtx+0xd708 00000053`653fefe0 00007ffe`655e4374 OraOps12!OpsDacDispose+0x2b809 00000053`653ff060 00007ffe`655e31cf 0x00007ffe`655e43740a 00000053`653ff150 00007ffe`6a80969d 0x00007ffe`655e31cf0b 00000053`653ff1f0 00007ffe`c4b96d06 0x00007ffe`6a80969d0c 00000053`653ff220 00007ffe`c4c30e81 clr!FastCallFinalizeWorker+0x60d 00000053`653ff250 00007ffe`c4c30e09 clr!FastCallFinalize+0x550e 00000053`653ff2a0 00007ffe`c4c30d3a clr!MethodTable::CallFinalizer+0xb50f 00000053`653ff2f0 00007ffe`c4c30bf5 clr!CallFinalizer+0x5e10 00000053`653ff330 00007ffe`c4c304dc clr!FinalizerThread::DoOneFinalization+0x9511 00000053`653ff410 00007ffe`c4c31777 clr!FinalizerThread::FinalizeAllObjects+0xbf12 00000053`653ff450 00007ffe`c4b97d01 clr!FinalizerThread::FinalizeAllObjects_Wrapper+0x1813 00000053`653ff480 00007ffe`c4b97c70 clr!ManagedThreadBase_DispatchInner+0x3914 00000053`653ff4c0 00007ffe`c4b97bad clr!ManagedThreadBase_DispatchMiddle+0x6c15 00000053`653ff5c0 00007ffe`c4b9ac34 clr!ManagedThreadBase_DispatchOuter+0x7516 00000053`653ff650 00007ffe`c4bf5271 clr!ManagedThreadBase_DispatchInCorrectAD+0x1517 00000053`653ff680 00007ffe`c4b9ac72 clr!Thread::DoADCallBack+0x10918 00000053`653ff830 00007ffe`c4c3172a clr!ManagedThreadBase_DispatchInner+0x8219 00000053`653ff870 00007ffe`c4c304dc clr!FinalizerThread::DoOneFinalization+0x1f11a 00000053`653ff950 00007ffe`c4c3062b clr!FinalizerThread::FinalizeAllObjects+0xbf1b 00000053`653ff990 00007ffe`c4b97d01 clr!FinalizerThread::FinalizerThreadWorker+0xbb1c 00000053`653ff9d0 00007ffe`c4b97c70 clr!ManagedThreadBase_DispatchInner+0x391d 00000053`653ffa10 00007ffe`c4b97bad clr!ManagedThreadBase_DispatchMiddle+0x6c1e 00000053`653ffb10 00007ffe`c4cf4d4a clr!ManagedThreadBase_DispatchOuter+0x751f 00000053`653ffba0 00007ffe`c4d5044f clr!FinalizerThread::FinalizerThreadStart+0x12620 00000053`653ffc40 00007ffe`d6157e94 clr!Thread::intermediateThreadProc+0x8621 00000053`653ffd00 00007ffe`d7a87ad1 kernel32!BaseThreadInitThunk+0x1422 00000053`653ffd30 00000000`00000000 ntdll!RtlUserThreadStart+0x210:090> !clrstack OS Thread Id: 0x5634 (90) Child SP IP Call Site00000053653ff0b8 00007ffed7abf0e4 [InlinedCallFrame: 00000053653ff0b8] Oracle.DataAccess.Client.OpsDac.Dispose(IntPtr, IntPtr, IntPtr, IntPtr ByRef, Oracle.DataAccess.Client.OpoMetValCtx*, Oracle.DataAccess.Client.OpoDacValCtx* ByRef, Oracle.DataAccess.Client.OpoSqlValCtx*, Int32, Int32)00000053653ff0b8 00007ffe655e4374 [InlinedCallFrame: 00000053653ff0b8] Oracle.DataAccess.Client.OpsDac.Dispose(IntPtr, IntPtr, IntPtr, IntPtr ByRef, Oracle.DataAccess.Client.OpoMetValCtx*, Oracle.DataAccess.Client.OpoDacValCtx* ByRef, Oracle.DataAccess.Client.OpoSqlValCtx*, Int32, Int32)00000053653ff060 00007ffe655e4374 DomainNeutralILStubClass.IL_STUB_PInvoke(IntPtr, IntPtr, IntPtr, IntPtr ByRef, Oracle.DataAccess.Client.OpoMetValCtx*, Oracle.DataAccess.Client.OpoDacValCtx* ByRef, Oracle.DataAccess.Client.OpoSqlValCtx*, Int32, Int32)00000053653ff150 00007ffe655e31cf Oracle.DataAccess.Client.OracleDataReader.Dispose(Boolean)00000053653ff1f0 00007ffe6a80969d Oracle.DataAccess.Client.OracleDataReader.Finalize()00000053653ff608 00007ffec4b96d06 [DebuggerU2MCatchHandlerFrame: 00000053653ff608] 00000053653ff788 00007ffec4b96d06 [ContextTransitionFrame: 00000053653ff788] 00000053653ff8d0 00007ffec4b96d06 [GCFrame: 00000053653ff8d0] 00000053653ffb58 00007ffec4b96d06 [DebuggerU2MCatchHandlerFrame: 00000053653ffb58]
从调用栈来看,原来是 终结器线程
在调用 OracleDataReader.Dispose()
方法的时候抛的异常,这个结果还是挺意外的,也就是说这个问题不是用户代码造成的,真的是 Oracle 这个 OraOps12.dll
造成的。。。
接下来用 lm
观察下这个 dll 的详情信息,输出如下:
0:090> lmDvmOraOps12Browse full module liststart end module name00007ffe`b0920000 00007ffe`b098c000 OraOps12 C (export symbols) OraOps12.dll Loaded symbol image file: OraOps12.dll Image path: C:\ODAC\xxxx\OraOps12.dll Image name: OraOps12.dll Browse all global symbols functions data Timestamp: Sat Sep 26 23:16:56 2015 (5606B6E8) CheckSum: 00000000 ImageSize: 0006C000 File version: 2.121.2.0 Product version: 2.121.2.0 File flags: 0 (Mask 3F) File OS: 4 Unknown Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04b0 Information from resource tables: CompanyName: Oracle Corporation ProductName: Oracle Data Provider for .NET InternalName: OraOps OriginalFilename: OraOps12.dll ProductVersion: 2.121.2.0 ODAC RELEASE 4 FileVersion: 2.121.2.0 FileDescription: Oracle Provider Services LegalCopyright: Copyright © 2014
虽然对 Oracle 不熟,但从 Timestamp: Sat Sep 26 23:16:56 2015
来看应该是一个比较老的 DLL 了,所以给到朋友的建议就是升级 OraOps12.dll
。
有时候直接让朋友升级dll有点缺少底气,最好就是找到一些同行者,经过一顿搜索,还真有同行者,又多了一份说服力,网址: https://techcommunity.microsoft.com/t5/iis-support-blog/w3wp-exe-crash-exception-code-0xc0000005/ba-p/334351
。
在百加dump的分析旅程中,碰到和 Oracle SDK 相关的也有 3+
起了,可能也许这些 SDK 在对接 .NET 上还不是特别稳健,大家在使用上尽量更新到最新版本吧,且用且珍惜!
标签:
推荐文章
- 焦点热议:记一次 .NET 某医疗住院系统 崩溃分析
- 2023郑州高新区公租房199套房源地址+报名方式_全球今热点
- 当前速看:北京市便民商业网点超10万个
- 人民的名义剧情介绍分集 焦点滚动
- 焦点热文:当工作可以网约 数字游民一根网线“闯天下”
- 每日消息!我有一剑什么时候出 公测上线时间预告
- 世界快资讯:风向变了!卷王惊现,淘宝祭出“大杀器”!
- 2023河北公务员考试笔试最低控制分数线_速递
- 全球快播:石油矿场机械教材(石油矿场机械)
- 世界新动态:华晨宇家世如何
- 国家滑板训练基地落户山东 全球热推荐
- 每日热点:手机同时开着wifi和热点_手机wifi和热点同时开
- 【解放思想助推高质量发展】我县各乡镇各部门各单位陆续召开“解放思想、开拓创新、真抓实干”转作风专题教育活动动员会-今热点
- 80多岁老太爬树摘榆钱 喊都喊不下来具体详细内容是什么-全球热资讯
- 环球即时:新水浒传武松谁演的
- 2023山东临沂市郯城人才人力资源服务有限公司招聘食品药品协管员总成绩公告
- 嘉华地产楼盘_嘉华地产_全球球精选
- 银行板块涨0.82% 苏州银行涨2.89%居首
- 【热点】棕榈油价格不断下行 后市还会走低吗? 热消息
- 视讯!阿里M6大模型前带头人杨红霞加盟字节跳动 参与语言生成大模型研发
- HealthPlix获得2200万美元C轮融资
- 立昂微:3月21日融资净买入566.77万元,连续3日累计净买入4433.86万元|环球新动态
- 经常大重量健身的人,可能心脏不好!4个方法帮你保护心脏 焦点精选
- 语义错误在线观看樱花高清_语义错误在线观看樱花|全球新资讯
- 资讯推荐:马龙孙颖莎抵达上海:莎莎身穿绿色轻薄风衣现身机场
- 焦点快报!淘宝账户怎么注销不了_淘宝账户怎么注销
- 哲学三大巨头都有谁_哲学三问题
- 混动汽车省油是真却不省钱,两大优势明显但3大痛点也不可忽视_天天热资讯
- 缅甸被绑定女店员当晚被放回去未交赎金 中国籍女店员缅甸遭绑架哭诉我还有个两个小孩(今日/头条)
- 每日快看:晒坯_对于晒坯简单介绍
- 环球动态:给自己立flag是什么意思_flag是什么意思中文
- 环球今亮点!应力计算公式有限元_应力计算公式
- 焦点快报!分摊面积计算公式excel_分摊面积计算公式
- 测不准原理为什么测不准_测不准原理-微资讯
- 欧洲签证生物识别_欧洲签证
- 2023年3月20日山东省氯化钾价格最新行情预测
- 修复坍塌墙体 消除安全隐患(反馈) 全球即时看
- 科技赋能“菜篮子” 各地品春鲜 尝春意-今亮点
- 【全球新要闻】成大有门选修课需要带面粉,是真的么?
- 天天微资讯!新天龙八部:别离火,拯救你的废9星装备,活动还剩最后几天
- 原油涨也亏,原油跌也亏!为什么中石油和中石化总是哭穷? 天天头条
- 民营企业聚力高质量发展 扩大数字低碳等领域投资-世界热门
- 缅北“马冬梅”变成了网上高价悬赏的通缉犯,缅北地区到底有多乱 环球资讯
- 探戈灵魂崔斯特皮肤多少钱_探戈灵魂崔斯特|环球热推荐
- 全球观天下!安徽金时代科技有限责任公司
- 【全球速看料】电脑系统还原怎么操作_如何还原电脑系统
- 今日视点:汇客厅|朱凌云:矢志创新,勇闯传感器行业崭新赛道
- 名人关于春天的美文摘抄段落_名人写春天的文章 世界即时看
- 菩萨蛮大柏地原文_菩萨蛮大柏地全诗意思-天天快报
- 案子少了 长江美了_聚看点
- 世界即时看!头笼是什么_头笼
- 山东齐鲁味精集团
- 驱鬼电影叫什么名字_驱鬼电影
- 陕西教育厅紧急预警严禁带病上学上班
- ST大集董秘回复:作为百度“文心一言”首批生态合作伙伴|世界视点
- 2月份楼市更加活跃 住房需求进一步释放
- 焦点!3-0!马龙横扫名将晋级!冲击大满贯冠军 闫安:对手被打懵了 附直播
- 硬膜外出血怎么回事_硬膜外出血怎么治疗
- 环球热点!据法新社和美国广播公司(ABC)等媒体3月16日消息,波兰总统杜达16日称,波兰将在未来几天内向乌克兰提供4架苏制米格-29战机,将成为首个向乌援助战机的北约国家。杜达指出
- 政策性资本金大部分来源于_一般来说政策性的资本金主要应由什么投资形成
- 当前快讯:珲春销毁11万余支假烟_珲
- 天帝叶凡有多少位弟子?他们都有着怎样的体质?修炼天赋又如何呢|焦点简讯
- 世界新消息丨水煮蚕豆嘌呤高吗_水煮蚕豆
- 反转!资深记者曝出猛料:国足希望之星做出决定,球迷吐槽声一片|世界资讯
- 微风往事之仙神妖说 当前快播
- 日照市科技中等专业学校获评乡村振兴先进单位|天天信息
- 从杨紫琼到黄柳霜,亚裔女演员的艰难路
- 暴雷欠下2万亿,被谣传跳楼自杀躲债,许家印:2023年全部还清
- 大数据Canal(二):Canal下载安装-全球独家
- 小兔子资料简介 小兔子的简介-即时焦点
- 全球要闻:吉林省博物院招聘若干岗位
- 拼音输入法皮肤选择(拼音输入法皮肤)
- 体彩延售带来的排列五30万元大奖
- 巴西大豆大量到港后,豆油库存有望止降回升金十期货3月15日讯,上周油厂开机率维持低位,下游提货亦放缓,豆油库存持稳,仍为2021年5月以来最低水平 环球热头条
- 试点恢复出境团队游60国全名单来了 请收藏→ 全球快播
- 北京多所学校试行教师弹性上下班 让老师早点儿回家休息
- 嘉和生物-B(06998.HK):3月14日南向资金减持2000股|视讯
- 观天下!肠道里长息肉,上厕所时或有4个提示,一文分析下
- 丰都新型冠状病毒肺炎疫情:3月14日丰都疫情最新消息今天数据统计情况通报
- 记者:曼联现阶段并未认真考虑凯恩转会,奥斯梅恩更具吸引力
- 063期老杨排列三预测奖号:首中末位分析_全球热门
- 【环球新要闻】总资产报酬率的范围包括(总资产报酬率的范围)
- 云南自由行旅游攻略及花费_云南抚仙湖旅游攻略 全球最资讯
- 美轰炸机模拟核打击圣彼得堡,俄专家:俄可能采取行动回击
- NBA最新实力榜公布:雄鹿坐稳第一,勇士跌出前10,湖人排名第18|全球百事通
- 天天快资讯丨点球绝杀,1-0!中国男足爆发,扬科维奇助手神了,剑指亚运金牌
- dnf仓库等级顺序_dnf仓库等级
- 双创基金ETF: 华夏基金管理有限公司关于华夏中证科创创业50交易型开放式指数证券投资基金流动性服务商的公告
- 康泰医学(300869)3月13日主力资金净卖出686.97万元
- 马爹利广东海陵岛红树林保护项目第二阶段正式启动
- 每日速递:太平洋航运涨超2% 机构预计短期运价延续高位震荡
- 券商观点|煤炭开采行业周报:建议淡化煤价波动,注重行业中长期配置价值
- r档位的英文(r档)-世界即时看
- 阿森纳本赛季英超队内助攻榜:萨卡9次居首,特罗萨德5次并列第3
X 关闭
资讯
X 关闭