前段时间有位朋友找到我，说他们有一个崩溃的dump让我帮忙看下怎么回事。
话不多说，既然有 dump 来了，那就上 windbg 说话吧。
说实话windbg非常强大，双击打开dump就能第一时间帮你显示出简略的异常信息，输出如下：
This dump file has an exception of interest stored in it.The stored exception information can be accessed via .ecxr.(bf8.5dc4): Access violation - code c0000005 (first/second chance not available)For analysis of this file, run !analyze -vclr!WKS::gc_heap::mark_object_simple1+0x220:00007ffb`380453c4 833a00 cmp dword ptr [rdx],0 ds:00007ffa`35451300=????????从卦中又看到了经典的 mark_object_simple1 方法，这个方法是GC用来做对象标记之用的，所以大概率又是托管堆损坏，真是无语了，接下来用 !verifyheap 检查下托管堆。
0:083> !verifyheapobject 00000218e96963d8: bad member 00000218E9696450 at 00000218E9696420Last good object: 00000218E96963C0.Could not request method table data for object 00000218E9696450 (MethodTable: 00007FFA35451300).Last good object: 00000218E96963D8.一看这卦就很不吉利，真的是有对象的mt是不对的，至此我们把崩溃的直接原因给找到了。
要找到这个答案就需要深挖 00000218e96963d8 对象，分别使用 !do 命令以及 dp 来观察内存地址。
0:083> !do 00000218e96963d8Name: System.Threading.Tasks.Task+DelayPromiseMethodTable: 00007ffb3542b3e8EEClass: 00007ffb3567c7c0Size: 120(0x78) bytesFile: C:/Windows/Microsoft.Net/assembly/GAC_64/mscorlib/v4.0_4.0.0.0__b77a5c561934e089/mscorlib.dllFields:...00007ffb35451300 40035d5 48 ...m.Threading.Timer 0 instance 00000218e9696450 Timer0:083> dp 00000218e9696450 L600000218`e9696450 00007ffa`35451301 00000000`0000000000000218`e9696460 00000218`e96964c8 00000000`0000000000000218`e9696470 00007ffb`353e4b51 00000218`e9696368仔细观察卦中对象 00000218e9696450 所显示的mt，你会发现一个是 00007ffb35451300，一个是 00007ffa35451301，很显然前者是对的，后者是错的，可以分别用 !dumpmt 做个验证。
0:083> !dumpmt 00007ffb35451300EEClass: 00007ffb356942f0Module: 00007ffb353b1000Name: System.Threading.TimermdToken: 0000000002000504File: C:/Windows/Microsoft.Net/assembly/GAC_64/mscorlib/v4.0_4.0.0.0__b77a5c561934e089/mscorlib.dllBaseSize: 0x20ComponentSize: 0x0Slots in VTable: 23Number of IFaces in IFaceMap: 10:083> !dumpmt 00007ffa3545130100007ffa35451301 is not a MethodTable细心的朋友会发现虽然两个mt地址不一样，但已经非常相近，看样子又是一例经典的bit位翻转，我去，用 .formats 转成二进制观察一下，截图如下：
图片
从卦中可以清晰的看到当前地址有两个 bit 的翻转，分别是第0位和第32位，接下来就要洞察为什么会有两个bit位的翻转？
接下来我们逐一来聊一下。
熟悉 coreclr 底层的朋友应该知道，gc 在标记的过程中会给 mt 的第0位设置为1，表示当前对象在深度优先中已经标记过，防止重复标记，当然这个也是有源码作证的,简化后的代码如下：
inline BOOL gc_heap::gc_mark(uint8_t* o, uint8_t* low, uint8_t* high, int condemned_gen){ if ((o >= low) && (o < high)) { BOOL already_marked = marked(o); if (already_marked) { return FALSE; } set_marked(o); return TRUE; }}#define marked(i) header(i)->IsMarked()BOOL IsMarked() const{ return !!(((size_t)RawGetMethodTable()) & GC_MARKED);}有了这段源码，这个 bit 为什么为 1 就能轻松的解释了，所以这个翻转是一个正常情况。
这个是我无法解释的，也正是因为这个 bit32 的翻转导致 gc 认为这个 obj 是一个损坏的对象，到底是什么原因呢？民间众说纷纭，在我的过往分析旅程中我已见过两例，但我不敢确定自己又遇到了辐射类的奇葩情况，所以也第一时间找朋友确认程序周边是否存在辐射环境。
图片
朋友反馈过来附近有 伺服电机 类，说实话工控的东西我是真的不太懂，只能上网搜搜这玩意是否有辐射，截图如下：
图片
到底是不是这玩意导致的，其实我心里也没底，跟朋友的沟通后说是只出现过一次，这就更加玄乎了。
图片
不管怎么说，我只能给出如下两个方案：
在大工控领域里，这是我见过第三例bit位翻转导致的程序崩溃，太无语了，恶魔到底是不是旁边的 伺服电机 ?
本文链接：http://www.28at.com/showinfo-26-100725-0.html记一次 .NET某上位视觉程序离奇崩溃分析
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
