【问题标题】:Windows kernel conditional breakpoint not evaluatingWindows 内核条件断点未评估
【发布时间】:2017-03-04 09:23:49
【问题描述】:

我正在通过 Visual Studio 2013 使用 Windows 内核调试器,我试图停止(中断)函数 (nt!KiSwapContext),但仅限于特定进程 (0x920)。

断点无条件工作bp nt!KiSwapContext

我确定当前线程的进程 ID 可以通过 dt dword poi(gs:[188h])+3B8h 找到

我已经确认了以下条件工作,看看我是否在正确的线程上:? poi(poi(gs:[188h])+3B8h)==0x920

但是,当我尝试设置条件断点时,无论我在 if/else 中放入什么,它都会中断。所以我猜它认为表达式是无效的,只是忽略它。我已经确认,如果我确实输入了一个无效的表达式,它只会在没有警告或错误的情况下接受它,并且总是在断点处停止。

我使用的表达式是:bp nt!KiSwapContext ".if (poi(poi(gs:[188h])+3B8h)==0x920) {} .else {gc}"

我也尝试使用j 条件语法,但无济于事。

关于我做错了什么有什么想法吗?

[编辑] 哦,作为奖励,我如何在 64 位处理器上使用 dword 而不是 qword 进行条件检查。 ? poi(poi(gs:[188h])+3B8h) 返回一个 qword 值。我知道我可以使用dd 来获取值,但我似乎无法弄清楚如何将其添加到条件中。类似? dword(poi(gs:[188h])+3B8h)==0x920? {dd poi(gs:[188h])+3B8h}==0x920

【问题讨论】:

    标签: windows debugging kernel windbg breakpoints


    【解决方案1】:

    windbg 允许你设置process specific breakpoints with /p
    你不应该与 gs 和 fs 寄存器混在一起

    kd> bl
    
    kd> !process 0 0 calc.exe
    Failed to get VAD root
    PROCESS 8113d528  SessionId: 0  Cid: 07a0    Peb: 7ffde000  ParentCid: 043c
        DirBase: 03d27000  ObjectTable: e15ba240  HandleCount:  28.
        Image: calc.exe
    
    kd> bp /p 8113d528 nt!KiSwapContext "?? (char *)(@$proc->ImageFileName)"
    kd> g
    char * 0x8113d69c
     "calc.exe"
    nt!KiSwapContext:
    804db828 83ec10          sub     esp,10h
    kd> g
    char * 0x8113d69c
     "calc.exe"
    nt!KiSwapContext:
    804db828 83ec10          sub     esp,10h
    

    根据需要使用dwo()和qwo()计算dword和qword

    kd> ? qwo ( ffb9cda8 + 70)
    Evaluate expression: -9142252815570161280 = 81203180`81203180
    kd> ? dwo ( qwo ( ffb9cda8 + 70))
    Evaluate expression: -4600296 = ffb9ce18
    
    confirmation
    
    kd> dd 81203180 l1
    81203180  ffb9ce18
    kd> dd ffb9cda8+70 l1
    ffb9ce18  81203180
    

    编辑

    我无法访问 x64 系统 atm,所以无法告诉您表达式中的错误是什么
    但总的来说,除非绝对必要,否则您应该避免硬编码

    在你的情况下没有必要

    windbg 为您提供硬编码的伪寄存器

    $thread to c++ Expression for CurrentThread * ie (nt!_ETHREAD *)

    所以$thread->Cid.UniqueProcess 是您使用 gsexxxxx 评估的内容

    考虑到这一点,您可以像这样设置断点

    bp nt!KiSwapContext " r?$t0 = @$thread->Cid.UniqueProcess ;.if( @$t0 != 0x740 ) {?@$t0;?? (char * )@$proc ->ImageFileName ;gc }"

    这个条件只会在 calc.exe 是当前进程中中断

    kd> g
    Evaluate expression: 404 = 00000194
    char * 0x81105c84
     "csrss.exe"
    XXXXXXXXXXX
    Evaluate expression: 4 = 00000004
    char * 0x8129196c
     "System"
    xxxxxxxxxxxxxxxxxxxxxxxxxxx
    Evaluate expression: 1404 = 0000057c
    char * 0x8114a4bc
     "vpcmap.exe"
    Evaluate expression: 480 = 000001e0
    char * 0x8112a98c
     "services.exe"
    Evaluate expression: 492 = 000001ec
    char * 0x811cc9ac
     "lsass.exe"
    zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
    Evaluate expression: 1116 = 0000045c
    char * 0xffaf9da4
     "explorer.exe"
    Evaluate expression: 644 = 00000284
    char * 0xffb74f14
     "svchost.exe"
    
    nt!KiSwapContext: <---------------------------Conditional broke here
    804db828 83ec10          sub     esp,10h
    
    kd> ? @$t0;?? (char * )@$proc->ImageFileName
    Evaluate expression: 1856 = 00000740
    char * 0x8110e76c
     "calc.exe"
    

    记住在非常热的路径上评估条件会让你忍受看着它爬行的难以忍受的痛苦

    nt!kiSwapContext 在几秒钟内被调用了数百次 你会发现你的性能下降非常明显 会话

    尽可能使用特定于进程或特定于线程的断点 不评估条件

    不,我不使用任何备忘单(谷歌说可用的很少)我更喜欢手动或在某些情况下在线 msdn 文档

    【讨论】:

    • 非常感谢!我一直在阅读有关 Windows 内核调试器的大量文档,并且在查找此类信息时遇到了真正的麻烦。你不会碰巧知道一个好的备忘单参考吧?还有关于它为什么不接受我的命令的任何想法?比如,里面有错别字吗?还是您认为只是尝试使用我的处理器编号破解来找到它会成为问题?
    • 再次感谢您。实际上,我只是通读了 MSDN 上有关内核调试的整个部分。无论如何,我需要知道的最重要的事情都是你给我的!在我习惯一些变量和命令之前,我可能会参考你的答案一段时间。
    • 另外,在你的新代码中,我认为@$t0 != 0x740 你可能打算将它作为==。而且我现在知道,我不应该将 bp 放入 KiSwapContext,而应该只使用“bu PROCESSNAME!*”(我认为这是语法)。
    • Sorry Processname!* 不正确它是 !symbol !=。它与==相反。我不喜欢为我想打破的情况写评估我放弃我不想要的----看看你的空白{},。 ,它会花费更多的时间来评估两个条件中的一个 if foo == blah dothis else dothat 比 if foo != Woow exit
    • 我想我只是注意到我原来的问题是什么问题。我有“==”而不是“=”来表示平等。该死的 MASM 语法:-)
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-05-16
    • 2018-07-17
    • 1970-01-01
    • 2013-12-02
    • 2011-08-04
    • 1970-01-01
    • 2019-09-23
    相关资源
    最近更新 更多