var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-333696-1']); _gaq.push(['_trackPageview']); _gaq.push(['_trackPageLoadTime']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })();
  • 2009年03月23日

    Windows界面自动化录制机制

    分类:

    不同于SpyWindows自动化录制工具需要记录有效的操作信息,这就需要对接收到的消息进行筛选。考虑到这个要求,使用Win32 Hooks是最有效地解决方式,利用它截获并筛选鼠标和键盘消息。

  • 2009年03月17日

    Unhandled Exceptions

    分类:

    下图是Windows Exception dispatching logic

     

    Matt Pietrek的文章介绍了UnHandledExceptionFilter会检查是否有postmortem(jit) debugger,如果有则CreateProcess把出错的进程挂上jit debugger,并等待dump完毕调用NtTerminateProcess,这一过程绕过了自定义UnHandledExceptionFilter。所以如果想要在调试器附上时仍能调用自定义的UnHandledExceptionFilter,可以Crack NtQueryInformationProcess或者SetEvent

     

    如果调试器正附着在上,UnHandledExceptionFilter立即被困即自定义UnHandledExceptionFilter无法被执行,此时能看到原始的寄存器状态;如果没有调试器附着,一个unhandled exception处理在JIT调试处理生效前的最初异常环境内被执行然后调试器附上了。既然在栈内存空间的讨厌的崩溃在访问异常发生前已经出栈,此unhandled exception就被重用并重写了这讨厌的栈空间,这发生在保存dump这里是另一种解释。

  • 2009年03月09日

    为何事后调试会失效

    分类:

    Demystifying first-chance exceptions中给出了下图:

     

    介绍了postmortem debugger会在上图打叉的地方中断,可能的原因是因为异常处理可能以一种特殊的方式并且会安静地中断或退出引发该异常的线程或者关键线程数据崩溃。文Who calls the postmortem debugger?介绍了如何得到了这个异常处理流程,文When a process dies silently解释了64位进程内如果栈溢出该进程将安静地死掉。这就解释了Windows自带的postmortem debuggerXP及之前NTSDDr. Watson (drwtsn32.exe)VistaWER (Windows Error Reporting,WerFault.exe)为何有时会一闪而过看不见错误窗口和生成dump,这时需要改用ADPlus或者使用实时的debugger附着上程序。

     

    How to distinguish between 1st and 2nd chances介绍了第一次机会异常不会在用户态的线程栈内留下任何痕迹于是不会在线程原生栈上看到任何异常代码。

    【资源】

    Reversing Microsoft Visual C++ Part I: Exception HandlingPart II: Classes, Methods and RTTI

     

  • 2009年03月03日

    网页应用程序反应时间

    分类:

    Grow Fast We Apps Organical中讲道,Keynote公司度量反应时间,最近一期Keynote商业40报告中平均反应时间为1.82秒。

     

    动态事务访问多架构层,它典型地可能包括一个Web服务器,应用程序服务器,数据库和后端/主机服务器。一个动态事务的执行是重要的。当更多层和集成点允许一个更灵活的系统实施,每个集成点增加反应和执行时间。该总开销可能包括数据的列集/散列,压缩/解压缩,和队列/出列。独立的这些行为可能仅需耗费数百万秒,但合聚起来能增至数秒。

     

    通常复杂动态事务包括账务详细和搜索。下图显示最佳反应时间从最近信用卡账户细览报告由Gomez生成。反应时间范围介于8~17秒,并且平均反应时间是14秒。用户似乎习惯这个执行时间长并且期望被有效管理通过进度条,动画消息.gif文件或其它方法。

     

    对媒体店,它典型使用内容管理引擎并带有多个数据库,Gomez跟踪搜索反应时间(见下图)。该范围从4秒到多于15秒,平均11秒左右。

     

    诸如这些提供的真实性能数据你能用来对比你的界面。在我们顾问实施中,我们理想争取12秒的反应时间-对静态网页有效。然而,对当今复杂的动态事务来说,一个更实际的跨越静态和动态内容的反应时间应该是3~8秒。达成用户体验通过包括内容缓存,异步加载技术和进度条技术的使用,所有这些有效地辅助达成用户的期望和大部分用户满意。

  • 2009年02月28日

    本月文章收录

    分类:

    Perl and Web [0][1][2][3]

    Win32Perl移植版汇总

    SQL Server 2005 配置发送邮件