博客园_Performance Tuning相关的

微软上海招聘有经验的.NET开发人员

2011-03-09T02:37:00Z

如题，主要是做企业的项目开发，Vendor职位（非FTE）。要求对C#、ASP.NET、SQL比较熟练。工作经验三年以上，学历不限。

有意的兄弟，请发简历给我：charju@microsoft.com

本文链接

塔防蜀的存档分析

2011-02-27T13:18:00Z

最近在玩塔防新春版，上手很容易，过关也简单。偶很喜欢研究游戏存档，看看有没有什么特别的剧情、人物、道具能够出来。

首先用iFunBox或者别的东西，把存档目录copy到本地电脑上，如我这里就是存放在了：C:\Users\username\Desktop\FolderName\F38DE1C9-0098-42AC-AF62-8D2A6A82E44F。

下面有4个子目录，我感兴趣的是两个，一个是documents，这里存放存档文件；另一个是threekingdomstdsehd.app，这里面有所有的图片、音乐、将领资料、道具资料、地图、剧情。除了save.plist在documents目录外，其他的都是在前文中的第二个目录。所有的xml文件都包含有英语、简体中文、繁体中文和日文四种语言。

Items_HD.xml
- 物品一共分为3种，武器、装备、坐骑。对应的itemtypename分别是Weapon，equipment和viecle。攻击力最大的是方天画戟150，其次是青钢剑和朱雀爪，各自140。攻击范围最大的兵器是青龙偃月刀，32；最大的装备是孙子兵法、神兽砚、饺子和中国结，都是攻击范围增加40；最大的坐骑是赤兔，攻击范围增加48。
- 每个item下面
  - icon image，指定了该道具的图片名称。
  - money包含buy和sell，我玩的里面没发现有可以买卖道具的地方，所以这个可能是为将来扩展用的。
  - limites。lv，这个应该是说武器最低使用等级，如诸葛连弩，只能3级或以上兵来用。wuxings这个不详，也许和五行有关？bosses，这个应该是该道具只能某个武将用。如，方天画戟只能吕布用。
  - Impacts，value=1应该是指攻击力，num=+150则意味着增加150。所以<impact value=”1” num=”+150”意味着方天画戟可以增加武将攻击力150。从其他的道具，如8651丈八蛇矛，impact value=”5” num=”+32”，结合介绍，可以看到，5代表攻击范围，值是num/2。所以这里意味着丈八蛇矛的攻击范围可以增加16。从9540倚天剑的介绍中可以猜出来，impact value=”3” num=”+0.1”，意味着倚天剑的攻击速度+0.1。再如9542青钢剑，impace value=”5” num=”-32”意味着青钢剑的攻击范围减少16。
Skills_HD.xml
- 技能分为将领和普通兵的，但是从xml item上没有明显标志区分。
- expend/food~value代表该技能消耗术的点数。如鼓舞，消耗45点术。注意的是，effectarea表明技能的使用范围，如鼓舞的effectarea value=”320”，但是游戏中用大、局部、全局来表示范围大小。如果看主要将领的最高一级技能，如水淹七军，可以知道effectarea value=”19998”代表全局。
- duration代表技能持续时间；
- effectargets，代表该技能针对哪些soldier有效，包括将领、普通兵种。如skill id=”27“，勇猛，专门针对张飞的：effectarget soldierid=”18”/8816/8815/8814/8813
soldier_HD.xml
- 所有的将领和普通兵的资料，这里面包含的是该将领“初始”状态具有的道具和技能。
- 让人诟病的是，每个将领都按照start lv从1到5，设置了5条记录，并且分别采用不同的soldier id，不知道为什么要这么设计。本来我想写一个修改器，可以把曹操、吕布等都选成我的人，但是里面有5个曹操、5个吕布，实在影响心情啊！！！每个将领从1到5，是通过Promotie来连接的，类似于一个链表一样。如刘备id=16, promotie=8805;id=8805,promotie=8806这么连接下去的。
- hp value、atk value分别是生命、攻击力，注意的是def value，如张飞def value=”90”，代表他的防御力，这个游戏里面没有用到。
- Soldierskill代表该将领在每级可以拥有的技能，最多3项。注意里面有一个是requirementskillid value=”0”，貌似技能需要另外技能作为前提，这个游戏里面现在没有体现。
- kindoms，似乎代表每个将领属于哪个主公的，xml中都是空，这个估计做外将来游戏扩展用。
- 里面有超过100个将领（士兵）的头像是dazhonglian01，就是“大众脸”，这个比较搞。如大名鼎鼎的曹彰、司马兄弟等。
save.plist
- 这里就是存档文件。因为游戏支持三个存档，所以文件中有三组plist/array/dict。
- 每个dict下面主要分为hero、level、storage、unit、是否完成。
- hero
  - 下面有若干个dict，代表将领的信息。isActive意味着该将领是否在出征队列。curExp代表经验值，这是一个real类型，比较怪异。
  - 然后是5组的道具信息，用center/downleft/downright/topleft/topright代表，该位置是否装备着某个武器或者道具或者坐骑（中间、左下、右下、左上、右上）。如果是-1，则意味该位置没有装备。如果都是-1,则该将领没有任何装备。
  - id代表武将或者士兵的id，和soldier_hd.xml相关联。
- level
  - easyHighscore、hardHighscore，代表普通、难的最高分。
  - maxStar代表几个星
- storage
  - 包含了当前仓库里面可用的装备信息，用id与items_hd.xml关联。
- Unit
  - 代表出场的士兵，如大象、弓兵等，用id与soldier_hd.xml关联。
Stage*_level_hd.xml
- *代表第几关，如01代表第一关。
- enemy_bosses代表本关会出场的boss的id，与soldier_hd.xml关联。
- exp_prize代表本关可以得到的经验值
- resource/money代表初始金币，resource/food代表初始术
- bonusitems代表本关可能出现的宝物奖励。如level01，有铁戟蛇矛、钱串等物品。每个物品后面有一个probability，应该代表掉落纪律。如铁戟蛇矛，0.7，但是钱串是1.3。所以不解这里是代表70%、130%还是说代表0.7%和1.3%。如果是后者，那么掉落几率是在太小了。
- Attackwave代表第几波的攻击。soldiers/soldier代表这一波有哪些将领、士兵来攻击；pathnodes代表在地图上的行动路线。
- 最后是events，分为condition和result，如event id=123226代表刘备如果遇到孙权，那么会发生单挑，如果单挑成功，则孙权退走。<dropitem triger=”false” itemid=”0/>，这里让我比较迷惑，看了很多关，这里好像都是triger=false, itemid=0。
state*_map_hd.xml
- 同上，02代表第二关。
- 里面都是地图的描述，不感兴趣。除非自己要写地图编辑器。

总结一下，基本上通过上述几个文件的增加、修改，开发商就可以迅速造出大量剧本和关卡莱。我们要自己改，也很容易。

如果要改装备，就修改save.plist。如果要改将领的攻击力、速度等，就改soldier_hd.xml，如果要改将领的技能，也改soldier_hd这个文件。

如果改某项技能的花钱数（如水淹七军只用1个术，或者负数），则修改skill_hd.xml。

其他诸如每关开始的钱、术，修改stage*_level_hd.xml即可。

本文链接

我的HD2手机

2010-08-04T11:33:00Z

感觉Windows Mobile 6.5的API实在太那个了………………

放两张下午写的小东西的图。那个comboBox、那个numericUpDown、那个MenuItem，偶要疯掉了。

这个是竖屏的，numericUpDown是自己做的一个很简单的UserControl。

这个也是竖屏的，恶心的ComboBox，手根本不好点选。

这个做成了横屏的，WM自己的numricUpDown

最后这个是天气预报，下午刚写的，看起来还好，hoho。

看到这个“选择城市”的菜单，我崩溃了……黑乎乎的界面，

本文链接

和我一起作Tess的windbg lab，结束

2010-06-27T07:25:00Z

这7篇post是花了3个小时分析+写完的。欣慰的是，偶已经比当年牛一些了，Tess大牛的7个lab被这么快搞完，哈哈！

应一些兄弟的要求，写了一下这个，还是比较粗糙。因为好多人最concern的是，抓到这个dump后，你为什么要敲那些命令？而不是敲这些命令？so，偶尽量写一下思路。

当然，windbg这个东西还是要多练习的。否则的话，时间长了，就废了。

我的分析还是很粗糙，有的思路也不严谨，so，可以到tess的blog上看。我在7篇中写的是lab的地址，每个review的地址大家可以自己找。

Tess现在是GTSC的EE，瑞典人，大牛，貌似也是一个美女，膜拜一下……

本文链接

和我一起作Tess的windbg lab - Lab7, MemoryLeak

2010-06-27T07:21:00Z

原文地址：http://blogs.msdn.com/b/tess/archive/2008/03/25/net-debugging-demos-lab-7-memory-leak.aspx

操作步骤：

1、产生压力：tinyget -srv:localhost -uri:/BuggyBits/News.aspx -threads:500 -loop:200

2、抓一个hang的dump，看看gc heap大小，!eeheap -gc，如下：

GC Heap Size 0x1899f44c(412742732)，大概400M，dump文件整个为550M。

3、看一下gc heap的总体状况：!dumpheap -stat，输出如下：

7912d7c0 1342 400044140 System.Int32[]

嗯，一共1300多个数组，但是这些数组居然占了400M，和gc heap的大小差不多。

4、察看一下详细情况，因为只有1300多个，所以我们可以全部打印出来：!dumpheap -mt 7912d7c0

5、几乎所有的数组，大小都是400K，随便找一个，然后找一下该数组的root，运行!gcroot 1f981e60，结果如下：

Scan Thread 49 OSTHread 2234
DOMAIN(00115B40):HANDLE(WeakLn):24b10dc:Root:02a621f4(System.Web.NativeFileChangeNotification)->
02a621d8(System.Web.DirMonCompletion)->
02a61ea4(System.Web.DirectoryMonitor)->
02a61ec8(System.Collections.Hashtable)->
02a61f00(System.Collections.Hashtable+bucket[])->
02a62100(System.Web.FileMonitor)->
02a62134(System.Collections.Specialized.HybridDictionary)->
02a62178(System.Collections.Specialized.ListDictionary)->
02a62194(System.Collections.Specialized.ListDictionary+DictionaryNode)->
02a5d538(System.Web.Compilation.BuildManager)->
02a5e0fc(System.Web.Compilation.MemoryBuildResultCache)->
02a2c970(System.Web.Caching.CacheSingle)->
02a2ca00(System.Web.Caching.CacheExpires)->
02a2ca20(System.Object[])->
02a2cd64(System.Web.Caching.ExpiresBucket)->
02b2e948(System.Web.Caching.ExpiresPage[])->
1b078ff0(System.Web.Caching.ExpiresEntry[])->
1b20583c(System.Web.Caching.CacheEntry)->
1b20581c(System.Web.Caching.CacheItemRemovedCallback)->
1b203db0(ASP.news_aspx)->
1f981e60(System.Int32[])
6、看其他的几个数组，引用顺序差不多。

7、猜测：代码中用了cache，cache中包含了一个400K的数组。但是由于某种原因，cache里面的东西没释放掉，越来越大。

8、查看源代码

    protected void Page_Load(object sender, EventArgs e)
    {
        string news = "<I>New site launched 2008-02-02</I>";
        string key = Guid.NewGuid().ToString();
        Cache.Add(key, news, null, Cache.NoAbsoluteExpiration, new TimeSpan(0, 5, 0), CacheItemPriority.NotRemovable, new CacheItemRemovedCallback(this.RemovedCallback));
        lblNews.Text = ((string)Cache[key]);
    }

Cache有一个5分钟的失效期。但是由于我们的测试中，负载上来了，还没有到5分钟，所以看到的cache还在内存中。那么5分钟之后呢，可能会消失。但是更可能的是，在3分钟的时候，负载太大了，cache的东西又加上来了，最终导致OOM，程序挂了。

Over

本文链接

和我一起作Tess的windbg lab - Lab6, MemoryLeak

2010-06-27T06:59:00Z

原文地址：http://blogs.msdn.com/b/tess/archive/2008/03/17/net-debugging-demos-lab-6-memory-leak.aspx

操作步骤：

1、产生压力： tinyget -srv:localhost -uri:/BuggyBits/ProductInfo.aspx?ProductName=Bugspray -threads:50 -loop:20

2、这个比较有意思，CPU很高，经常100%，内存很少，几十M而已。如果你仔细看taskmgr，会看到有几个csc诡异的出现，忙了一会，又消失了。

3、抓一个hang的dump，运行!eeheap -gc，看看内存状况：

GC Heap Size 0x68a0fc(6856956)

托管内存只用到了6M多，而我的dump是190M，那么，其余的内存被谁用了？

4、联想到步骤2中的诡异的csc进程，我们需要再检查一下，!eeheap -loader，看看有多少dll在loader heap里面？我这里一共看到了2223个

5、随便找一个module看看

0:000> !dumpmodule -mt 06f0ab78
Name: oghe0kiv, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
Attributes: PEFile
Assembly: 07093808
LoaderHeap: 00000000
TypeDefToMethodTableMap: 0702f8c4
TypeRefToMethodTableMap: 0702f8dc
MethodDefToDescMap: 0702f93c
FieldDefToDescMap: 0702f9a8
MemberRefToDescMap: 0702f9d4
FileReferencesMap: 0702fac4
AssemblyReferencesMap: 0702fac8
MetaData start address: 072e09e4 (4184 bytes)

Types defined in this module

MT TypeDef Name
------------------------------------------------------------------------------
06f0b7ac 0x02000002 Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterProduct
06f0b6fc 0x02000006 Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializerContract

Types referenced in this module

MT TypeRef Name
------------------------------------------------------------------------------
63a28fb0 0x01000001 System.Xml.Serialization.XmlSerializationWriter
63a295a4 0x01000004 System.Xml.Serialization.XmlSerializerImplementation
05e60b3c 0x01000005 Product
05e60bbc 0x01000006 ShippingInfo
79101fe4 0x01000008 System.Collections.Hashtable
79106894 0x01000009 System.Type
790fd0f0 0x0100000f System.Object
639ff1c4 0x01000013 System.Xml.XmlConvert

6、看到这里基本清楚了，这就是那个著名的XmlSerializer的问题。可以参考我以前写的blog：http://www.cnblogs.com/juqiang/archive/2008/01/15/1039936.html

Over

本文链接

和我一起作Tess的windbg lab - Lab5, Crash

2010-06-27T06:44:00Z

原文地址：http://blogs.msdn.com/b/tess/archive/2008/03/05/net-debugging-demos-lab-5-crash.aspx

操作步骤：

1、运行CompanyInformation.aspx

2、在输入框中输入一个字符串，如aaa，点Send按钮

3、等了几秒钟，IE报错：无法显示网页

4、抓一个crash的dump，加载SOS，看一下!threads，输出如下：

Hosted Runtime: yes
                                      PreEmptive   GC Alloc           Lock
       ID OSID ThreadOBJ    State     GC       Context       Domain   Count APT Exception
XXXX    1 dd0 000dbce8   1808220 Disabled 00000000:00000000 00102870     1 Ukn (Threadpool Worker) System.StackOverflowException (0291106c) (nested exceptions)
XXXX    2 f70 000e7ec8      b220 Enabled 00000000:00000000 000d91a0     0 Ukn (Finalizer)
XXXX    3 f80 000ec3a8      1220 Enabled 00000000:00000000 000d91a0     0 Ukn
XXXX    4 868 000ff360    80a220 Enabled 00000000:00000000 000d91a0     0 Ukn (Threadpool Completion Port)
XXXX    5 fac 00151ad0   880a220 Enabled 00000000:00000000 000d91a0     0 Ukn (Threadpool Completion Port)
托管线程有5个，但是都挂掉了。

5、重新抓dump，使用参数-FullOnFirst，等了N久，dump也没抓完。咋回事？停掉adplus，到dump目录看一下，2分钟内，居然有10几个dump，而且大小完全一致。

6、打开最早的一个dump，由于是crash的dump，所以windbg自动切换到出问题的线程，如下：

OS Thread Id: 0x364 (16)
ESP EIP
0203f1f0 7c80bee7 [HelperMethodFrame: 0203f1f0]
0203f294 05770ae7 BuggyMail.IsValidEmailAddress(System.String)

嗯，看来是IsValidEmailAddress这里出问题了。

7、别急，打开第二个dump看看：

OS Thread Id: 0x364 (16)
ESP EIP
0203efbc 7c80bee7 [HelperMethodFrame: 0203efbc]
0203f060 7948d980 System.IO.__Error.WinIOError(Int32, System.String)
0203f08c 79395557 System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean)
0203f184 793983c8 System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare, Int32, System.IO.FileOptions)
0203f1b0 793984e3 System.IO.StreamWriter.CreateFile(System.String, Boolean)
0203f1c0 79398550 System.IO.StreamWriter..ctor(System.String, Boolean, System.Text.Encoding, Int32)
0203f1e0 7949959c System.IO.StreamWriter..ctor(System.String)
0203f1ec 05770b52 Utility.WriteToLog(System.String, System.String)
0203f220 05770b0b ExceptionHandler.LogException(System.Exception)
0203f224 05770a81 BuggyMail.SendEmail(System.String, System.String)

比较有意思，在SendEmail里面，调用了LogException，然后在最上面产生了一个WinIOError

8、打开最后一个看看：

OS Thread Id: 0x364 (16)
ESP EIP
0203ec4c 7c80bee7 [HelperMethodFrame: 0203ec4c]
0203ecf0 7948d980 System.IO.__Error.WinIOError(Int32, System.String)
0203ed1c 79395557 System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean)
0203ee14 793983c8 System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare, Int32, System.IO.FileOptions)
0203ee40 793984e3 System.IO.StreamWriter.CreateFile(System.String, Boolean)
0203ee50 79398550 System.IO.StreamWriter..ctor(System.String, Boolean, System.Text.Encoding, Int32)
0203ee70 7949959c System.IO.StreamWriter..ctor(System.String)
0203ee7c 05770b52 Utility.WriteToLog(System.String, System.String)
0203eeb0 05770b0b ExceptionHandler.LogException(System.Exception)
0203eeb4 05770bd4 Utility.WriteToLog(System.String, System.String)
0203ef60 05770b0b ExceptionHandler.LogException(System.Exception)
0203ef64 05770bd4 Utility.WriteToLog(System.String, System.String)
0203f010 05770b0b ExceptionHandler.LogException(System.Exception)
0203f014 05770bd4 Utility.WriteToLog(System.String, System.String)
0203f0c0 05770b0b ExceptionHandler.LogException(System.Exception)
0203f0c4 05770bd4 Utility.WriteToLog(System.String, System.String)
0203f170 05770b0b ExceptionHandler.LogException(System.Exception)
0203f174 05770bd4 Utility.WriteToLog(System.String, System.String)
0203f220 05770b0b ExceptionHandler.LogException(System.Exception)
0203f224 05770a81 BuggyMail.SendEmail(System.String, System.String)
0203f2c8 05770a28 CompanyInformation.btnContact_Click(System.Object, System.EventArgs)
从最下面的SendEmail往上看，LogException调用了WriteToLog，然后WriteToLog又调用了LogException，后者又调用了WriteToLog。

9、结合上面步骤4的线程1最后那个列：StackOverFlowException，我们猜测，上面步骤8的结果可能就是StackOverFlowException的原因。那么，步骤8的最上面一行的WinIOError是什么意思呢？我们看一下出问题的线程16上的栈上的变量，运行!dso，结果如下：（部分）

0203ee48 02b38358 System.String c:\log.txt
0203ee54 02b3a850 System.String Access to the path 'c:\log.txt' is denied.

10、基本能猜测到，要访问c:\log.txt，但是无权限导致IOError的。

11、看代码，找到SendEmail那段：

    public void SendEmail(string message, string emailAddres){
        try
        {
            if (IsValidEmailAddress(emailAddres))
            {
                // send an email with the message
            }
        }
        catch (Exception ex)
        {
            ExceptionHandler.LogException(ex);

        }
    }
回到步骤6，正是从IsValidEmailAddress开始发生异常的。由于我输入的字符串是bbb，不是一个合理的email地址，所以会有异常（可以看Isvalid这个方法），然后异常被扔到了catch块中。

12、看catch里面的LogException怎么写的：

    public static void LogException(Exception ex)
    {
        Utility.WriteToLog(ex.Message, "c:\\log.txt");
    }
13、哈，这里出现了上面从!dso中看到的c:\log.txt字符串。这个没问题，看WriteToLog怎么写的。代码如下：

    public static void WriteToLog(string message, string fileName)
    {
        try
        {
            using (StreamWriter sw = new StreamWriter(fileName))
            {
                //Log the event with date and time.
                sw.WriteLine("--------------------------");
                sw.WriteLine(DateTime.Now.ToLongTimeString());
                sw.WriteLine("-------------------");
                sw.WriteLine(message);
            }
        }
        catch (Exception ex)
        {
            ExceptionHandler.LogException(ex);
        }
    }

这里try的地方可能会有问题，比如无权限、文件不存在等。关键的地方在于，try的地方如果出错，会被扔到catch块里面，执行LogException操作。

看明白了吗？如果这里有exception出现，就又返回到了步骤12中，最终又调用到了这里，又有exception，又返回到步骤12………………

14、解决办法，手工创建一个c:\log.txt，右键修改该文件的security，增加iuser_机器名这个用户，赋予full control。重新运行程序，好了。

Over

本文链接

和我一起作Tess的windbg lab - Lab4, High CPU

2010-06-27T06:02:00Z

原文地址：http://blogs.msdn.com/b/tess/archive/2008/02/22/net-debugging-demos-lab-4-high-cpu-hang.aspx

操作步骤：

1、产生压力：tinyget -srv:localhost -uri:/BuggyBits/AllProducts.aspx -threads:5 -loop:1

2、观察taskmgr的输出，w3wp的CPU为99%，这是一个典型的高CPU的Hang。抓一个hang的dump，然后等待10秒钟，再抓一个；10秒钟之后再抓一个。一共抓3个。

3、打开这三个dump，加载sos之后，分别查看!runaway的输出。

第一个dump的结果：

0:000> !runaway
User Mode Time
Thread       Time
27:848       0 days 0:00:06.279
26:c84       0 days 0:00:03.054
16:f10       0 days 0:00:02.784
28:d14       0 days 0:00:02.403
23:f0c       0 days 0:00:02.323

第二个dump的结果：

0:000> !runaway
User Mode Time
Thread       Time
26:848       0 days 0:00:06.990
25:c84       0 days 0:00:06.138
22:f0c       0 days 0:00:05.718
16:f10       0 days 0:00:05.387
27:d14       0 days 0:00:04.546

第三个dump的结果：

0:000> !runaway
User Mode Time
Thread       Time
25:848       0 days 0:00:12.167
26:d14       0 days 0:00:09.373
22:f0c       0 days 0:00:08.422
24:c84       0 days 0:00:07.811
16:f10       0 days 0:00:07.250

4、从上面三个dump来看，只有16和26号线程的时间一直在增长。

5、查看三个dump的!threadpool，都是100%

6、查看16和26号的托管callstack，如下：

OS Thread Id: 0xd14 (26)
ESP EIP
04faf034 7c9585ec [HelperMethodFrame: 04faf034]
04faf0a0 058f0981 AllProducts.Page_Load(System.Object, System.EventArgs)

7、查看所有托管线程的callstack，与上述代码类似，如25号线程。这里我们猜测，tinyget的压力不是一下子上来的，25号线程是后跑起来的，所以第一个dump的runaway中没有它的比较大的时间输出。

8、查看其他线程，加载合适的symbol之后，你会发现24号线程在作String.Concat和GC的操作。

9、查看上述的Page_load方法，里面调用了一个循环10000次的方法，然后针对输出的DataTable，进行了大量的String.Concat操作。我们知道，大量的Concat操作，同时也会在内存上产生大量的字符串对象，对内存会有压力，对GC也会有压力。

Over

本文链接

和我一起作Tess的windbg lab - Lab3, Memory

2010-06-27T05:30:00Z

原文地址：http://blogs.msdn.com/b/tess/archive/2008/02/15/net-debugging-demos-lab-3-memory.aspx

操作步骤：

1、产生压力：tinyget -srv:localhost -uri:/BuggyBits/Links.aspx -loop:4000

2、观察taskmgr的输出，w3wp的内存每秒钟大概增长100M。

3、内存到700M左右的时候，抓一个hang dump

4、由于这是一个memory的问题，所以我们要先看GC Heap的情况，运行命令：!eeheap -gc，结果如下：

GC Heap Size 0x2b307720(724596512)

由于dump一共870M，而GC占用了720M左右，所以我们的重点在于托管内存的分析。

5、看heap的整体状况，运行!dumpheap -stat，结果如下：

790fd8c4 49787 721599752 System.String

嗯，720M的托管内存中，String占用了绝大多数。

6、看一下string的情况，根据2/8原则，大小相同的string也许会很多，这里我们过滤一下，看看10K以上大小的字符串，运行命令：!dumpheap -mt 790fd8c4 -min 10000

0331d6dc 790fd8c4    20020
03322534 790fd8c4    20020
0332738c 790fd8c4    20020
0332c1e4 790fd8c4    20020
0333103c 790fd8c4    20020

大部分都是20K的字符串，随便找一个，我们需要看它被谁分配的

7、运行!gcroot 0331d6dc，结果如下：

Scan Thread 16 OSTHread 318
Scan Thread 18 OSTHread c38
Scan Thread 19 OSTHread a40
Scan Thread 20 OSTHread c00
Scan Thread 24 OSTHread 998
Scan Thread 14 OSTHread 4cc
Finalizer queue:Root:0331d6b8(Link)->
0331d6c8(System.Text.StringBuilder)->
0331d6dc(System.String)

在14号线程中，Link引用了这个字符串。而且我们看到，link是在Finalizer Queue中的。

8、查看finalizequeue，输出如下：

057e0bcc 35998 575968 Link

一共35998个Link对象。由于该对象存在于Finalizequeue中，所以一定显示的实现了Finalize方法。

9、查看该方法，代码如下：

~Link()
{
//some long running operation when cleaning up the data
Thread.Sleep(5000);
}

10、换个方向，看上面步骤7中的那个Link对象，!do 0331d6b8，输出结果如下：

      MT    Field   Offset                 Type VT     Attr    Value Name
790fdc5c 4000006        4 ...ext.StringBuilder 0 instance 0331d6c8 url
790fd8c4 4000007        8        System.String 0 instance 029bb0b8 name
再看第一个url对象，运行!do 0331d6c8 ，结果如下：

      MT    Field   Offset                 Type VT     Attr    Value Name
791016bc 40000b1        8        System.IntPtr 1 instance    dc1d8 m_currentThread
79102290 40000b2        c         System.Int32 1 instance 2147483647 m_MaxCapacity
790fd8c4 40000b3        4        System.String 0 instance 0331d6dc m_StringValue

注意最后一行的那个m_StringValue，对比一下步骤7中的!gcroot输入。

从这里我们看到，Link中包含了一个StringBuilder，而StringBuilder中包含了一个20K的字符串。

11、看代码：

public Link(string name, string url)
    {
        this.name = name;
        this.url.Append(url);
    }
可以看到，Link对象的构造方法中，引用了字符串。

12、再回头看上面的步骤9，Link自作聪明的实现了Finalize方法，但是该方法执行的时间太长（这里是5秒钟），导致垃圾回收的时候，迟迟不能把该对象回收掉。因为Link引用了字符串url，所以相应的字符串也无法被回收。这样内存就上涨的很快了。

Over

本文链接

和我一起作Tess的windbg lab - Lab2, Crash

2010-06-27T05:01:00Z

原文地址：http://blogs.msdn.com/b/tess/archive/2008/02/08/net-debugging-demos-lab-2-crash.aspx

操作步骤：

1、打开 http://localhost/BuggyBits/Reviews.aspx，点击5次refresh按钮，然后看到巨大的黑色粗体字：Service Unavailable

2、检察eventlog，点开始-运行，输入：eventvwr，先看Application的，会有如下错误：

Process ID: 1808

Exception: System.NullReferenceException

以及

Process ID: 3544

Exception: System.NullReferenceException

以及

Process ID: 7234

Exception: System.NullReferenceException

以及

Process ID: 2343

Exception: System.NullReferenceException

以及

Process ID: 9087

Exception: System.NullReferenceException
3、上面的错误，我们可以看到，W3WP一共crash了5次，然后看System的日志，可以看到：

事件类型: 错误
事件来源: W3SVC
事件种类: 无
事件 ID: 1002
日期:  2010-6-27
事件:  12:35:28
用户:  N/A
计算机: VPC2003
描述:
应用程序池 'LabAppPool' 被自动禁用，原因是为此应用程序池提供服务的进程中出现一系列错误。

有关更多信息，请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。

4、打开IIS，察看应用程序池，你会发现LabAppPool已经被disable掉了。

5、右键查看该apppool的属性，在快速失败保护中会发现，如果5分钟之内有5次crash，则该apppool会被禁用掉。

6、好了，这是一个典型的crash问题，并导致apppool被disable掉，对客户端显示HTTP503错误。现在开始debug

7、抓一个crash的dump，我们会发现产生了3个dump，分别是1st chance的AV、1st chance的process shutdown和2nd chance的netclr full，先打开第一个av的dump

a、由于是crash的dump，所以windbg会自动切换到导致AV的那个线程，我这里是18号。

b、加载sos，会有如下信息：

0:018> .loadby sos mscorwks
------------------------------------------------------------
sos.dll needs a full memory dump for complete functionality.
You can create one with .dump /ma <filename>
------------------------------------------------------------
因为这是一个mini dump，所以很多信息我们看不到。解决办法之一是在adplus的时候，用参数-FullOnFirst，但是这个参数有副作用，我们后面会看到。

c、查看托管线程，如下：

0:018> !clrstack
PDB symbol for mscorwks.dll not loaded
OS Thread Id: 0x64c (18)
ESP EIP
0221f950 05500efb Review.Finalize()
0221fc1c 79fbcca7 [ContextTransitionFrame: 0221fc1c]
0221fcec 79fbcca7 [GCFrame: 0221fcec]
可以看到，Review.Finalize方法导致了AV错误。
d、运行!threads，输出如下：

0:018> !threads
ThreadCount: 4
UnstartedThread: 0
BackgroundThread: 4
PendingThread: 0
DeadThread: 0
Hosted Runtime: yes
                                      PreEmptive   GC Alloc           Lock
      ID OSID ThreadOBJ    State     GC       Context       Domain   Count APT Exception
16    1 2a4 000dbce8   3808220 Enabled 00000000:00000000 001028a8     1 Ukn (Threadpool Worker)
18    2 64c 000e7de0      b220 Disabled 00000000:00000000 001028a8     0 Ukn (Finalizer)
19    3 538 000ec2c0      1220 Enabled 00000000:00000000 000d8fd8     0 Ukn
　 20    4 594 000ff408    80a220 Enabled 00000000:00000000 000d8fd8     0 Ukn (Threadpool Completion Port)

可以看到发生AV的18号线程是GC的finalizer线程。那么具体的exception在哪里呢？

e、执行命令，!dso。输出如下：

0:018> !dso
Error requesting details
Unable to determine bounds of gc heap

ooh，我们在一个mini的dump里面，很多东西是看不到的。so，需要抓一个fulldump来看。

f、重新运行adplus，增加参数：-FullOnFirst，重新看dump。

g、看!dso的结果：

0:018> !dso
OS Thread Id: 0x908 (18)
ESP/REG Object Name
esi 029b9158 Review
0221f990 029b9158 Review
0221f9dc 029b9158 Review
0221f9e8 029b9158 Review
0221f9fc 029b9158 Review
0221fa00 029b9158 Review
0221fa10 029b9158 Review
0221fae8 029b9158 Review
0221fcb0 029b9158 Review

没有exception，只有一个Review对象，继续看，执行!do 029b9158

      MT    Field   Offset                 Type VT     Attr    Value Name
790fd8c4 4000008        4        System.String 0 instance 00000000 quote
790fd8c4 4000009        8        System.String 0 instance 00000000 source

注意上面的两个string，都是0，这意味着都是null，那么，是否可能是null.SomeMethod导致的呢？

h、看步骤c中的Review.Finalizer方法，代码如下：

    ~Review()
    {
        if (quote.ToString() != string.Empty)
        {
            quote = null;
        }
    }

嗯，问题找到了，在于上面的quote.ToString造成的，因为某个原因，quote这个字符串变成了null，所以出现AV了。

i、实际上如果查看页面代码，我们能看到一个Clear方法把这个变量变成了null。

Over

本文链接