约有 9 项符合查询结果， 以下是第 1 - 1项。
费时 < 1 秒。
这是个COM thread, 而且corrupt的是COM的heap, 检查下interop代码。dump分析至少应该 ~*kb 把所有的stack都列出来。
Posted in .Net程序调试
by
johnl
on 2011-06-27
取决于地址是否 4byte aligned, aligned 的是atomic, 可以不加锁。
Posted in Windows内核调试
by
johnl
on 2011-06-26
0:000> x user32!*getdc*
773ad1a5 user32!xxxBNGetDC =
7738a649 user32!NtUserGetDCEx =
7739c621 user32!NtUserGetDC =
773c4011 user32!LBGetDC =
bp user32!NtUserGetDC
Posted in WinDbg
by
johnl
on 2009-08-28
使用debugdiag, ms 免费的工具。windbg+dump不总是最好的手段，他只是一个snapshot,
memory leak天生应该是应该用动态分析工具来分析的
Posted in WinDbg
by
johnl
on 2009-07-28
pageheap enabled的情况下，VAD 部分是占最大比例的，因为heap block再小，他的成本也是8k, 两个页面。debug memory leak是不能把pageheap enabled的，high load app很快就会把2g吃掉。
disable pageheap (if enabled). 使用debugdiag
来debug memory leak是合适的方法。
Posted in WinDbg
by
johnl
on 2009-07-27
WDK doc 讲的比较清楚，在call KeAttachProcess之前应该检查irql <= irql_dispatch_level.
我建议你严格条件为passive_level更符合逻辑。另外，detach 也要 <= irql_dispatch_level.
你自己的dispatch routine的irql要清楚。
Posted in Windows内核调试
by
johnl
on 2008-09-29
WDK doc 讲的比较清楚，在call KeAttachProcess之前应该检查irql 533: CurIRQL = KeGetCurrentIrql();
534: while(CurIRQL > DISPATCH_LEVEL) ？？？
535: {
536: KeDetachProcess();
537: // wait for low IRQL
538: LogPrint((g_DevExt->hLogFile, ''KeAttachProcess IRQL is %d\r\n'', CurIRQL));
Posted in Windows内核调试
by
johnl
on 2008-09-29