一：背景 1. 讲故事 在.NET高级调试的旅程中，我常常会与 Bitmap 短兵相接，它最大的一个危害就是会让程序抛出匪
一：背景 1. 讲故事 前些天有位朋友在微信上联系到我，说他们的程序在客户那边崩掉了，让我帮忙看下怎么回事，dump也拿到了，那就上手分析吧。 二
这次生产事故彻底破坏了两个语言团队之间的相互合作的信任度，信任重建可就难了，不怕神一样的对手，就怕猪猪一样的队友，放在这里还是挺合适的，哈哈，开个小玩笑。
Bitmap使用不当危害巨大，所以一定要谨记尽早释放的原则，如果真的不幸被吃了很多内存，也一定要明白那些未知的大内存段是不是被 Bitmap 所关联，从而尽早的找到真正的祸根。
0:000> !sos.help analyzeoom, AnalyzeOOM Displays the info of the last OOM that occurred on an allocation request to the GC heap. assemblie
一：事情起因 在.NET圈里混了十多年，相信有不少人知道我专注于玩 .NET高级调试，如今技术上的硬实力还是能够解决市面上的一些疑难杂症，但软实力却在另一个极端，如（人际交往，人情事故），所以就萌生了刻意训练的念头，便自我发起了这个活动 "寻访中国100家.NET中大企业"。 二：苏州站 正值暑假，
我曾长期在互联网公司上班，没有人会喊工程师为xxx工，在我dump分析之旅中被人喊为xxx工，起初还挺不适应的，但也扛不住多呀，我就继续沿用这样的称谓吧，安工镜头感非常好，侃侃而谈，分享的经验让我受益匪浅，给人一个邻家大哥哥的感觉。正值暑假，出行的同时带着孩子一起去各地见见世面，扩大下孩子的眼界，苏州
这次生产事故分析还是非常有意思的，一个看似阻塞的问题也会引发CPU爆高，超出了一些人的认知吧，对，其实它就是经典的现象，大家有任
这次生产事故挖了点新东西，有点好奇的是现在工控行业也开始用 Avalonia 替代 WPF 了吗？不过现阶段稳定性和 WPF 是没法比的，期待未来更健壮的版本吧。
一：背景 1. 讲故事 前些天有位朋友找到我，说他们的系统出现了CPU 100%的情况，让我帮忙看一下怎么回事？dump也
一：背景 1. 讲故事 前些天有位朋友找到我，说他们的程序崩溃了，也自己分析了下初步结果，让我帮忙再确认下，既然让我确认，那
最新版本 的WinDbg真的让人很兴奋，可以将自己伪装成 GDB 来和远程的 GDBServer 打通来实现对 Linux 上 .NET程序进行调试，这
一：背景 1. 讲故事 最新版本 1.2402.24001.0 的WinDbg真的让人很兴奋，可以将自己伪装成 GDB 来和远程的 GDBServer 打通
最近遇到了几个朋友向我咨询这个问题，想在事故机器上安装 WinDbg，但是事故机器不能联网，请问如何离线安装。 下载 windbg.appinstaller 打开 MSDN： h
说实话这个dump分析起来还是挺有难度的，需要你对Windows线程池clr源码实现有一个基础了解，否则很难构造出完整证据链。
在大工控领域里，这是我见过第三例bit位翻转导致的程序崩溃，太无语了，恶魔到底是不是旁边的伺服电机?
一：背景 1. 讲故事 前些天有位朋友找到我，说他的程序每次关闭时就会自动崩溃，一直找不到原因让我帮忙看一下怎么回事，这位朋友应该是第二次找我了，分析了下 dump 还是挺经典的，拿出来给大家分享一下吧。 二：WinDbg 分析 1. 为什么会崩溃 找崩溃原因比较简单，用 !analyze -v 命
一：背景 1. 讲故事 前段时间有位朋友找到我，说他们有一个崩溃的dump让我帮忙看下怎么回事，确实有太多的人在网上找各种故障分析最后联系到了我，还好我一直都是免费分析，不收取任何费用，造福社区。 话不多说，既然有 dump 来了，那就上 windbg 说话吧。 二：WinDbg 分析 1. 为什么
这个卡死事故还是蛮好解决的，如果有一些经验直接用也是能搞定的，重点在于这是一个 Linux的dump，同时又是 .NET上的一个很好玩的场景，故此分享出来。
一：背景 1. 讲故事 早就听说过有什么 网络边缘计算，这次还真给遇到了，有点意思，问了下 chatgpt 这是干嘛的 ? 网络边缘计算是一种计算模型，它将计算能力和数据存储位置从传统的集中式数据中心向网络边缘的用户设备、传感器和其他物联网设备移动。这种模型的目的是在接近数据生成源头的地方提供更快速
WeakReference 的内部玩法有很多，更深入的理解还需要对进行深度挖掘，后面有机会再聊吧，有时候dump分析还是挺苦逼的，需要对相关领域底层知识有一个足够了解，否则谈何修复呢？
一：背景 1. 讲故事 最近在分析dump时，发现有程序的卡死和WeakReference有关，在以前只知道怎么用，但不清楚底层逻辑走向是什么样
这次朋友的生产事故，对我们做分析的人来说还是有很大的教训意义，有时候主线程的一些抛错或者阻塞假象会诱导我们陷入分析误区，这就需要调试人员具有一双慧眼识别，及时的浪子回头。
花了半天研究这东西还是挺有意思的，重点还是要理解下那张图，理解了之后我相信你对方法注释中所指的会有一个新的体会。
一：背景 1. 讲故事 前些天有位朋友找到我，说他们的程序会偶发性的卡死一段时间，然后又好了，让我帮忙看下怎么回事？窗体类的程序解决起
一：背景 1. 讲故事 在dump分析的过程中经常会看到很多线程卡在Monitor.Wait方法上，曾经也有不少人问我为什么用 !syn
前些天有位朋友找到我，说他们的程序内存会偶发性暴涨，自己分析了下是非托管内存问题，让我帮忙看下怎么回事？哈哈，看到这
这次程序崩溃的原因很简单，就是空引用异常，但诡异就诡异在明明有 trycatch 在外部，硬是没接住，这个大概率是 CLR 的 bug，让我这个眼界，无语了无语了。。。
有时候程序崩溃往往不是你代码写的烂，极有可能是底层承载的bug导致的，甚至罪魁祸首是环境中的辐射，所以分析崩溃类的dump
这个dump所呈现的三角循环死锁还是非常经典的，更开心的是这位学员的分析能力已经出了新手村。。。
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
