1
kd> u win32k!impPsIsThreadTerminating+0xe4-c L5
    |   \              \                \  \   \
   /     \              \                \  \   \
  /       \              \                \  \   \
disassemble\              \                \  \   \
        ModuleName      SymbolName      Offset \   \
                                              ???   \ 
                                                   ObjectCount

So How to intepret -c ?

2

without any supporting context the -c will be treated as 0xc and it will be subtracted from the address
resolved by win32k!impPsIsThreadTerminating+0xe4

be aware the 0xe4 is will be properly relevant most of the times only if you have an unoptimized build.

because after optimization functions can and will be divided into chunks by the compiler

and the least probable paths of code flow will be placed either before or after the function

suppose win32k!impPsIsThreadTerminating resolves to 0x000000007fffff00
then if it is an unoptimized build
win32k!impPsIsThreadTerminating+0xe4 will resolve to 0x000000007fffffe4

now 0xc will be subtracted from this address and the unassemble command will unassemble 5 instruction from this address

0:000> ? vect!main
Evaluate expression: 140699673489328 = 00007ff7`320eefb0

0:000> ? vect!main+e4
Evaluate expression: 140699673489556 = 00007ff7`320ef094

0:000> ? vect!main+e4-c
Evaluate expression: 140699673489544 = 00007ff7`320ef088

0:000> u vect!main+e4-c l5  <<<<<<<<<<<<<


00007ff7`320ef088 30488d          xor     byte ptr [rax-73h],cl <<<< see address
00007ff7`320ef08b 4c2448          and     al,48h
00007ff7`320ef08e e81a63ffff      call    vect!ILT+17320 (00007ff7`320e53ad)
00007ff7`320ef093 eb0a            jmp     vect!main+0xef (00007ff7`320ef09f)
00007ff7`320ef095 488d4c2430      lea     rcx,[rsp+30h]
| improve this answer | |
  • the command really was from thirdparty, and what I really don't understand is if it already specified an offset +0xe4 why would it add -0xc afterwards? – Sajuuk Jul 17 '19 at 3:37
  • the offset 0xe4 is resolved by windbg from the accompanying pdb file (nearest offset to a known symbol the -c is added by the one who disassembled this he/she obviously had peeked around and saw the 0xe4 is not correct but the compiler had moved it by 0xc (its MAYBE I DONT KNOW I HAVE NO CONTEXT TO BASE THIS STATEMENT ON) so manually added the 0xc probably – blabb Jul 17 '19 at 6:01
  • thanks, I'll accept your answer after 2 days if no other answer was given. – Sajuuk Jul 17 '19 at 8:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.