V君的博客

IE9也是一个坑: JQuery 出现 Date not defined

作者：V君 发布于：2015-12-1 16:28 Tuesday 分类：填坑经验

TL;DR: 似乎是脚本还是DOM引擎的缺陷, 会遇到系统对象/类还没定义, 脚本就使用的情况. 

解决:吃我大Chromium啦!

参考: JQuery官方BUG追踪系统 爆栈

 

标签: javascript bug IE9

评论(0) 引用(0) 浏览(1791)

[更新]使用WinDbg分析转储文件 找出C#程序内存占用过大的原因

作者：V君 发布于：2015-9-15 14:37 Tuesday 分类：填坑经验

TL;DR: 

1)打开windbg载入dmp

2).loadby sos mscorwks

3)!dumpheap -stat 

你写的程序你估计就知道为啥了

扯扯:

这次不是进程崩溃, 是另一个服务进程内存占用异常的大 , 超过4GB

原因诊断十分顺利, 然并卵,

因为某个环节需要调用第三方服务接口来解析数据,

这个接口似乎承受不住请求密度, 出现严重延迟现象

进程内部队列一直堆积着, 内存就撑大了 _(:з」∠)_

参考来源 调试内存泄漏问题的一些经验 by Dawei XU

 

参考来源 debugging.io

继续补充:

当不是你写的程序, 然而你又看到大量String而不知所措时

先用!strings命令来刷刷内存中的字符串, 适当的时候按暂停, 不然会卡死你

然后总结一下内容,看看有没有大片有规律的字符串

使用 !gcroot 每行前面的地址查看是什么地方引用了它　(参考来源: theartofdev.com）

再进一步: !mdt 出来的根对象地址, 如果是List<T> 还可以查看内容哟

顺着items进去,点击 expand first 40 items, 嗯嗯 这下真相大白啦

标签: 软件开发 C# 调试技术 windbg

评论(0) 引用(0) 浏览(2623)

[已解决]遭遇 clr20r3

作者：V君 发布于：2015-9-10 11:05 Thursday 分类：填坑经验

有个负责的老项目服务进程多次崩溃, 没有留下有价值的线索.

事件日志查到的信息不多

EventType clr20r3, P1 ******.exe, P2 1.0.0.0, P3 ******, P4 mscorlib, P5 2.0.0.0, P6 ******, P7 dc, P8 5, P9 a4dh5wwiwww1yjtmp0c0kv4zwcalu4in, P10 NIL.

咕狗过 a4dh5wwiwww1yjtmp0c0kv4zwcalu4in , 似乎是 KeyNotFoundException 

然而并不知道是什么地方爆错,先上个 AppDomain.CurrentDomain.UnhandledException 

看看能不能捕获“临终”前的异常.

-待更(等待下一次崩溃。。。）

-然而进程到现在还没崩溃。。。

-似乎是另一个进程把内存撑爆了才挂掉 _(:з」∠)_

结果更:

总算是等到崩溃了,临终遗言GET! 和查到的一样, 是 KeyNotFoundException

2015-11-26 **:**:**,** [**] FATAL

程序集： **.**.**, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

消息： System.Collections.Generic.KeyNotFoundException: 给定关键字不在字典中。

   在 System.ThrowHelper.ThrowKeyNotFoundException()

   在 System.Collections.Generic.Dictionary`2.get_Item(TKey key)

   在 **()

   在 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)

   在 System.Threading.ThreadHelper.ThreadStart()

额外信息： 发生严重错误导致进程崩溃

标签: 软件开发 C# 软件故障诊断

评论(2) 引用(0) 浏览(5901)

使用TcpView和ProcMon高效地诊断应用程序故障

作者：V君 发布于：2015-8-17 13:28 Monday 分类：填坑经验

收到通知说咱们的软件在客户的电脑上不工作, 于是通过远程协助到客户的电脑上做诊断.

咱们的软件分为一个 Winform 配置界面和一个 Windows 服务.

 

情况是这样:

通过配置界面输入参数, 然后启动服务开始工作. 

然而似乎配置不生效 -- 使用TcpView看到服务连接目标是默认值而不是配置文件指定的

另外日志文件也一点都不产生.

 

诊断及修正:

打开ProcMon, 把服务进程名添加到筛选器, 开始观察.

找配置文件以及日志的路径监视结果, 发现拒绝访问.

嗯 马丹 去配置文件目录一看, 只有Administrator...  

修正权限让服务进程能访问文件. 

重新启动服务, 这下问题解决 -- 服务进程已经按照配置的参数连接到目标

日志文件也出来了.  乂目

 

总结:

我大 Sysinternals 棒棒哒!

(文中的两个软件都是这群人整出来的)

 

吐槽: 企鹅远程太难用了...

标签: 软件开发 调试技术 软件故障诊断 Sysinternals

评论(0) 引用(0) 浏览(2526)

使用Windbg分析转储来定位高CPU占用的C#代码

作者：V君 发布于：2015-8-6 14:51 Thursday 分类：填坑经验

今天运维告诉我服务器上出现使用大量 CPU 的进程.

要想定位/调优必须知道这些 CPU 处理量都用去做啥然后才能动刀子.

生产环境不能附加调试, 只能绕点弯路.

服务器是Win2003 x64

当时马上就想起 Procexp 能查看线程的 CPU 使用量, 运气好还能看到本地映像的调用堆栈.

不过这次运气并不太好, 调用堆栈只能看到 kernel32.dll , 之后啥都,看不到..

 

于是找找看有没有专门的 .net dump / 堆栈查看工具.

找到了Managed Stack Explorer/CLR Stack Explorer

前者只能查看32位进程, 放到服务器上运行啥也刷不出

后者在工作机上能刷出所有进程,还能标出是不是64位, 然而在服务器上也是啥都刷不出...

算了还是请出高大上的 WinDbg 吧. 让运维用 Procexp 做了个 mini Dump.

在用 WinDbg 打开 dmp 文件, 载入 sosex , 呃, 提示需要完整内存转储.

好吧于是做了个了个完整内存转储 -- 1G大的dmp文件..

 

输入 ~ 回车, 对应 Procexp 线程列表占用 CPU 高的 TID 对应这边十六进制ID

然后 ~*e!mk 回车 列出所有线程堆栈, 然后, Bingo! 

完整的堆栈信息弄到了, 足足61个堆栈帧, 详细的列出函数名称, 部分还提示了源代码行号.

这样就能够精确定位占用CPU高的功能代码块了! 乂目

 

Tips.

符号路径格式以及地址: srv*C:\SymbolCache*http://msdl.microsoft.com/download/symbols

加载sosex: >.load sosex

Windbg下载方法 sosex下载地址

标签: 软件开发 C# 调试技术 windbg

评论(0) 引用(0) 浏览(4756)