Coming from WinDbg

ntoseye speaks WinDbg’s command language, so most of what you type in WinDbg works unchanged. This page lists what carries over, what is spelled differently or missing, and what ntoseye adds.

What carries over

  • Command names and syntax. bp, kn, dt, !process, lm, u, the d* and e* families, .reload, .sympath, !analyze, and so on. The command reference lists every one.

  • MASM expressions with WinDbg’s hexadecimal default radix: poi(), by/wo/dwo/qwo, @rax, $ip/$proc/$thread and the other pseudo-registers, @$name, separated addresses like fffff803`1a2b3c4d. See Expressions.

  • The breakpoint grammar: pass counts, if <expr> conditions, do "<commands>" actions with a trailing gc, /1, /p, /t. See Breakpoints.

  • Symbols. Microsoft’s symbol server is the default, and the cache under ~/.ntoseye/symbols uses the symstore layout that WinDbg reads too.

  • .kdfiles reads WinDbg’s driver replacement map files. See Driver replacement.

Spelled differently, or missing

In WinDbg

In ntoseye

dx, ??, @@c++( )

Typed MASM expressions: ev ((nt!_EPROCESS*)@$proc)->UniqueProcessId, or dt. Member access yields the field’s value, not its address. There is no C++ evaluator, so pointer arithmetic is never scaled.

!name for a symbol in any module

module!name. A leading ! negates here, and !name alone reports the ambiguity.

.foreach, !for_each_process

The Python SDK or a custom command.

x exact wildcard match

x is a fuzzy search: * and ? still glob, and ^, $, ', !, and spaces refine it.

as Name Text with ${Name} substituted in later commands

as defines a command alias: as ubp bp ${1}; g, then ubp nt!NtCreateFile. ${1}, ${2}, … and ${*} are the alias’s arguments.

.process /i (invasive switch, then g)

.process switches immediately, with or without /i: ntoseye reads any process’s memory through its page tables. attach <pid> is the same.

bsc, c, m, .detach, qd

Not available. Change a condition with bpc; q exits.

~ lists threads of a user-mode process

~ lists processors (vCPUs), ~Ns selects one. Windows threads are threads and !thread.

Behaves differently

  • Breakpoint scoping is a filter. bp /p <pid> and /t are checked by ntoseye when a breakpoint hits; the breakpoint itself is global, so a breakpoint in a shared DLL traps every process that runs it, and hits outside the scope are resumed silently. Breakpoints in shared pages explains the cost. /c <processor> scopes to one processor and has no WinDbg equivalent.

  • Some backends need no debugger in Windows. Over the gdb and memory backends Windows boots normally, without bcdedit /debug, so it does not know it is being debugged and behaves as it does in production. See Choosing a backend.

Only in ntoseye