能力值：
( LV4，RANK：40 )
|
-
-
2 楼
你的意思是调试过DNF导致现在玩不了了?
Kernel Detective v1.4.1早已经有了
|
能力值：
( LV2，RANK：10 )
|
-
-
3 楼
兴奋→努力→疲倦→兴奋→疲倦→不信邪→努力→失败灰心→不信邪→疲倦→继续努力→疲倦→坚持不住→继续坚持→实在坚持不住了→彻底放弃→时隔半月→不信邪→重拾课本→继续努力→失败→灰心丧气→路遇伯乐→拨云见日→兴奋→灵感突显→业绩小有所成→得意→四出炫耀→出名→业绩又遇技术问题→信心遭打击→继续研究→研究出来了→变的低调→觉得高手很多→忐忑日后糊口→放松心态→继续潜心研究→看见晚辈→想起当年自己→笑了笑→继续低调→慢慢习惯→不说话→变成大牛→又觉的自己其实不是大牛→继续装逼→最终得出人生终极格言：学无止境！
|
能力值：
![]()
(RANK：50 )
|
-
-
4 楼
在函数头直接返回？！当然要出问题了，人家的函数没跑完就返回，很可能造成意外。或许TP对Kernel Detective之类的ARK采取了新的措施（不再直接非法或者BSOD）。
可以试试设置好DUMP后自己产生BugCheck，然后用WinDBG分析DUMP文件，查看该函数的反汇编代码
|
能力值：
( LV2，RANK：10 )
|
-
-
5 楼
KD启动的时候我没有启动电脑,是在电脑刚刚启动的时候启动的,同样没有效果,你后面说的看不怎么懂..有没什么简单的解决点的..
|
能力值：
( LV2，RANK：10 )
|
-
-
6 楼
说错了不是电脑是,DNF游戏出了自动启动的一些杀软和服务,KD最先启动
|
能力值：
( LV2，RANK：10 )
|
-
-
7 楼
虚拟机内也出现类似的问题.查看函数头并不是直接返回
0: kd> u 80636cd5
nt!PsGetContextThread+0x226:
80636cd5 8bff mov edi,edi
80636cd7 55 push ebp
80636cd8 8bec mov ebp,esp
80636cda 51 push ecx
80636cdb 56 push esi
0: kd> u PsGetContextThread
nt!PsGetContextThread:
80636aaf 6840030000 push 340h
80636ab4 68d8f45280 push offset nt!IoSetFileOrigin+0x11cc6 (8052f4d8)
80636ab9 e8e5d3eaff call nt!CIsqrt+0x2d7 (804e3ea3)
|
能力值：
![]()
(RANK：50 )
|
-
-
8 楼
额您说的俺也不是很理解，下面根据俺可能错误的理解来回复：
首先SSDT里的函数全部是Nt开头的（和R3的Native API对应)，PsGetContextThread不会在SSDT中出现。不知道您的操作系统是哪个版本，不同版本SSDT号对应的函数会有差异。
或许是KD本身存在问题，可以先试试使用其它ARK工具（比如PCHunter,原Xuetr)之类的。
至于第一次回复中俺提出的方法，是通过使用WinDBG分析蓝屏转储文件来查看内核中各种数据/代码，此方法可以有效绕过不少反调试机制（比如TP会阻止WinDBG双机调试），首先参考微软的文章：http://msdn.microsoft.com/zh-cn/library/ff545499.aspx
设置好后就可以通过组合键在需要的时候生成内存转储文件（Dump file)。通过WinDBG分析转储文件，反汇编生成时的内核中的函数或者查看其它数据
|
|
|
|
