排查ASP.NET响应迟钝.用DebugDiag分析转储,再用WinDbg+sosex查看调用参数

作者:V君 发布于:2017-6-9 17:01 Friday 分类:填坑经验

WEB应用程序出现响应很慢甚至卡死的现象,

Server Admin 通过 DebugDiag 分析转储发现有个请求特别耗时间 (一个小时以上)


于是锅放到我这里辣.


DebugDiag得出堆栈已经显示具体代码位置了, 

想知道哪些数据被操作,还需要知道传入了哪些参数,这时候必须请出WinDbg+sosex了.

 

参考其 sosex 的 readme.txt MSDN文章 得知 !mk 命令可以查看当前线程调用堆栈

要切换当前线程 使用 ~*s 命令 (更多命令参见 windbg.info文章 )


搞起! .load sosex 再 ~*s 然后 !mk 这样就可以看到刚才的堆栈了,确保没选错线程

然而参数还没出来... 别急,呔! !mdso 列出当前线程堆栈上下文对象值

这个命令支持使用参数 /t:类名 来筛选结果. 这次排查过程顺利得有些出乎意料哇 乂目.

 

标签: 软件开发 ASP.NET 调试技术 windbg

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

记一次COOKIE域造成ASP.NET会话丢失

作者:V君 发布于:2017-5-24 16:05 Wednesday 分类:填坑经验

TL;DR

从浏览器 COOKIES 开始检查, 注意每次请求时 asp.net_sessionid 是否有变化, 

注意响应 COOKIES 是否有设置 Domain. 于是发现为了兼容子域名被设定了值.

加上调试条件编译跳过就解决了.


稍稍扯扯:

最初,发现 ajax 请求没有返回预期内容, 调试发现 Session 里面的东西变 null 了.

第一反应是Session配置问题或可能被 Abandon 过, 全文检索代码没发现被调用. 

先排除被 Abandon 这个可能.

去 web.config 看看 Session 配置, 切换了 InProcess 和 StateService 模式都不奏效.

然后观察每次请求上下文,发现 SessionId 每次都会变,COOKIE asp.net_sessionid 也每次都变

最后只好把焦点放到浏览器了, 仔细观察 COOKIE 响应况发现了原因.

标签: 软件开发 ASP.NET 调试技术 Web技术

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

Mono Android WebView 应用初体验[Updated]

作者:V君 发布于:2017-2-16 20:38 Thursday 分类:折腾手记

Hybrid App 这个技术诞生的时间很早, 到现在已经颇为成熟.

虽然略有所闻, 也在 Windows forms 上面用 CEF 玩得很溜, 但还是没去实际接触开发.

由于最近有想折腾的玩意儿, 况且公司在不久之后有需要做APP的可能.

就开始去接触吧!

 

略去安装开发环境的过程, 打开 VS2015. (当然要用我大井来写, 做什么都要用我大井才爽啊)

首先新建 WebView 项目, 然后观察. 


和常见的 Android 项目一样, 也见到了熟悉的 Assets Resources MainActivity 这些玩意儿.

不过多了 Models 和 Views 这两个文件夹.


MainActivity 的模板初始化代码也从按钮事件处理, 替换成了 WebView 视图初始化.

还没来得及纠结如何实现页面与原生功能交互时, 已经能看到模板类 HybridWebViewClient 了.


虽然方式有点土, 只能通过请求拦截来实现调用原生代码.

但这已经满足了 APP 开发的最低要求.


那问题来了: (挖掘机哪家强) 跑在手机应用的网页要怎样调试脚本呢?

我们知道 Chrome 的 F12 很好用, 但 APP 能这样整吗?

答案是可以! 咕狗关键字 Android Web View Debug 第一条就找到了官方文档.

官方文档也是先 TL;DR 地列出3个粗略的步骤, 然后再对其逐一详细解释.


1) 启用 WebView 调试属性.

2) 开个Chrome浏览器访问 chrome://inspect 这个 URI.

3) 在页面上列出的视图列表上找到你的应用对应视图, 点击 inspect 链接.


山口山! 一个 F12 工具蹦出来了! 鼠标在元素列表上划过, 手机端视图也和浏览器一样高亮!

整个就像是 Chrome的 F12 一样! (´∀((☆ミつ 本来这就是 Chrome 的 F12! 


初体验结束. 接下来可以愉快地写 APP 辣!


Update:

发现要做到这样调试还有一个前提, 也就是需要科学咳咳. 不信你就看 → git/issues

在另一台机做了同样操作,发现白屏了,咕狗一下才知道原来只要这样搞.

因为一直都有自动电梯, 所以没察觉到有这要求...

标签: 软件开发 调试技术 移动端 Android HybridApp

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

使用Debug Diagnostic Tool分析.net转储

作者:V君 发布于:2016-10-25 11:26 Tuesday 分类:填坑经验

TL;DR:

去M¥官网下载该工具, 对应其x86/x64. 安装时选择关联文件类型. 

装好之后双击要分析的dmp文件. 等一会儿. 一个可视化的mht分析报表就出来了.

注意这工具只能在Vista(NT6)以上环境运行.


转储dmp文件可以用Sysinternals出品的免费系统工具Process Explorer来做.


听我扯扯:

虽然WinDbg+sos/sosex很强大, 但是用起来很复杂, 载入符号也很慢.

于是找到了这货来帮忙, 尽管和前者比起来就差不能在内存中找对象.

但是非常方便收集异常信息以及线程堆栈.

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

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

[更新]使用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

 

After.Ps:
另一种方式,使用 sosex 下载来丢windbg旁边
1).load sosex
2)!sosex.mfrag -stat

参考来源 debugging.io


继续补充:

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

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

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

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

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

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

(我不会说之前的人真是丧心病狂, 60多万行1G以上内容,

居然直接查询出来放到内存里面去挨个处理) ‘皿’

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

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

Powered by emlog 去你妹的备案 sitemap