Windbg

Resources

• One Moudle : https://stackoverflow.com/questions/68416828/reload-only-one-symbol-in-windbg

CheatSheet

• By repnz : https://github.com/repnz/windbg-cheat-sheet/tree/master
• By goodies : https://goodies.dotnetos.org/files/dotnetos-debuggers_cheatsheet.pdf

Commands

• Process & Threads
  • Listing

    ~ # For The Current Thread
    ~*k # Stack for the all Threads

• Modules
  • Listing

    lm

  • Loading

    .reload /f sechost.dll # one module

    • All

      !sym noisy
      .sympath srv*https://msdl.microsoft.com/download/symbols
      .reload /f
      !sym quiet

• Misc
  • Operations
    • Go

      g

    • BreatPoint

      bp kernelbase!CreateFileW # Break on specific function
      bl # list break points
      bc * # clear breakpoints

    • Unassemble

      u rip

    • Restart

      .restart

  • View

    du @rcx # when the rcx is unicode 

    • Handels

      !handel
      !handle 940 f # 1 + 2 + 4 + 8 = 15 [f]

  • Symbols

    x *!CreateWindowExW
    x *!*CreateWindowEx*

  • Manual Help

    !handle -? #inline terminal
    .hh !handle # offline manual

  • SDDT

    dd nt!KiServiceTable # Start of the table
    dd nt!kiservicetable+55*4 L1 # Specifc Function 
    u nt!kiservicetable+0543e80 # the Bytes was 0543e807 we take only 0543e80 why not 7 !! -> 7 is the parameters number exept the Stack parameters 

  • Object & Handels

    !object 0xFFFFDF8F77063310
    dt nt!_OBJECT_TYPE ffffdf8f6d32dbc0

Notes

General

• In modern Windows, kernel32 is mostly just a hollow shell that forwards calls to kernelbase, which is why we break on kernelbase
• The Service Dispatch ID always goes into the EAX register immediately before the syscall instruction.
• For graphical functions, that gateway is win32u.dll
• Valid Handle IDs are always multiples of 4.
• If the call stack does not contain symbols, you’ll need to configure symbols , File→Symbol File Path Enter the MS symbol server address SRV*c:\Symbols*https://msdl.microsoft.com/download/symbols

Filtering the "Wall of Text"

When x *!*ReadFile* returns 100+ lines, mentally filter the results based on the Windows API Architecture. Core OS tasks (like reading files) almost always flow downward through these three specific DLLs:

1. The Legacy Layer: KERNEL32.DLL

• What you see: KERNEL32!ReadFile
• Verdict: Skip. On modern Windows, this is mostly a hollow shell that just forwards commands down to kernelbase.

2. The User-Mode Engine: KERNELBASE.DLL

• What you see: KERNELBASE!ReadFile
• Verdict: USE THIS. This is where the actual user-mode logic happens. It is the absolute best place to set a breakpoint to inspect high-level data (like the text inside a file).

3. The Kernel Gateway: NTDLL.DLL

• What you see: ntdll!NtReadFile (or ntdll!ZwReadFile)
• Verdict: USE THIS. But only if your goal is to inspect the raw system call right before it jumps into the kernel (e.g., finding the Service Dispatch ID).

---

** Pro-Tip: Write Surgical Searches** Instead of using the massive *!* wildcard to search everything, target the module specifically to get a clean list of just 3 or 4 results:

• For the high-level function: x kernelbase!*ReadFile*
• For the low-level transition: x ntdll!*ReadFile*