重点看了一下嫌疑最重的process,有一个比较可疑的stack ChildEBP RetAddr Args to Child 99b678f0 816b2b15 8477ba88 00000000 8176dd20 nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4]) 99b67928 816b1403 99b67b84 8477ba88 8477bb6c nt!KiSwapThread+0x266 99b67950 816ad6ef 8477ba88 8477bb48 00000000 nt!KiCommitThreadWait+0x1df ...

不知道也，没有详细说环境什么。也许用beep比较快吧，对自己的代码比较熟悉，打几个点就能解决问题。 int 10比较麻烦把。

一个hang的dump文件，process 0的IRQL没问题，是i8042prt驱动执行的IRQL 但是process 1 有点奇怪，按我的经验一般nt!KiIdleLoop都是run在IRQL 0上的。 系统是Win7 7600 0: kd> ~11: kd> kvChildEBP RetAddr  Args to Child              807f6d24 00000000 0000000e 3b013afc 3b433b18 nt!KiIdleLoop+0x1a (FPO: [0,0,0])1: kd> ...

看到一篇blog,原文在这里 http://blogs.msdn.com/ntdebugging/archive/2009/05/21/debugging-without-a-debugger.aspx 他遇到的问题是无法连kernel debug,并且问题出在boot阶段，也就是说无法用dbgview. 解决方法是使用蜂鸣器，加些代码然后听beep来判断程序执行的逻辑。

查了IA32手册等资料，我是在一块Atom上看得，对于不同类型的cpu判断memory type是不一样。 首先是用!pte拿到page table entry 1: kd> !pte 0f2c430c VA 0f2c430c PDE at 00000000C06003C8 PTE at 00000000C0079620 contains 000000001C690867 contains 800000001CE9586F 然后看page talbe entry中 PAT(bit 7), PCD(bit 4), PWT(bit 3) 1: kd> .formats 1CE9586F Evaluate ...

Win32k.sys!memmove占用了极其高的CPU资源。我想去验证一下src和dst的cache类型。 我应该看那几个Windbg的命令，有个思路就可以了，谢谢  

我的思路是，先找出是什么进程导致了问题，是否是一个固定的进程。如果是，就用一个user mode的调试。 所导致的问题是否是应为执行了dll内的一些代码，如果是在一个恰当的地方加入一个__debugbreak();的断点尝试是否能抓住现场。 ''计算机有问题''是什么样子的问题，知道了具体问题是什么样子的，也许有更好的地方来抓住现场。

既然你有代码，为何不加个print语句打印是什么process呢。 或者除了问题以后看你的dll在那些process里面呢？ 这样一个条件断点会很大的降低系统性能的。

VC的话你可以试试看“/EP /C“编译选项

谢谢 用ed nt!Kd_Default_Mask 0xffffffff 搞定了 0n(-1)好像不行，Windbg把0n(-1)当成一个64位的数字了，结果把nt!Kd_Default_Mask+4的内容改成ffffffff了 还有关于这个mask更多的信息码？Kernel debug能只接受指定process或者模块的debug输出吗？