WinDbg kernel debug

Hi, All,

I category the windbg debugging use case:

  1. user mode
    the windbg and the debugee should running on the same PC
    there are case:
    a. in windbg open the executalbe
    b. attach to the executable

  2. kernel mdoe
    current support NET, USB3, USB2, COM, 1394, it is really kernel debug, support p and t
    while the other is
    local kernel debug, therefore the windbg is running on the debugeed system
    but lk debug have limited command support

  3. dump file debug/analyzing

Questions:

  1. what is connect to remote session and remote stub usage?
  2. about Windbg x86 and x64

a. the host pc is win7 64, the target is Win8 or Win8.1 32/64 with bcdedit /debug on
I found in host, both x86 and x64 could be used for debugging target
So in this case, no matter target, and no matter host, both x86 and x64 is useful.

b. host pc is win7 64, bcdedit /debug on
x86 could not be used for kernel debug, while x64 is ok. why this case happen?

c. for user mode, host pc WIN7 64
both x86 and x64 windbg could used to debug a .exe file

If you are analyzing a dump file, you can use either the 32-bit debugging tools or the 64-bit debugging tools. (It is not important whether the dump file is a user-mode dump file or a kernel-mode dump file, and it is not important whether the dump file was made on an x86-based or an x64-based platform.)

If you are performing live kernel-mode debugging, you can use either the 32-bit debugging tools or the x64 debugging tools. (This situation applies to both x86-based and x64-based targets.)

Here what’s the difference between platform, and targets?

> b. host pc is win7 64, bcdedit /debug on

x86 could not be used for kernel debug, while x64 is ok. why this case happen?

I think all allowed mixes of 32/64bit debuggers and debuggees are well-described in the docs.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

workingmailing@163.com wrote:

If you are analyzing a dump file, you can use either the 32-bit debugging tools or the 64-bit debugging tools. (It is not important whether the dump file is a user-mode dump file or a kernel-mode dump file, and it is not important whether the dump file was made on an x86-based or an x64-based platform.)

If you are performing live kernel-mode debugging, you can use either the 32-bit debugging tools or the x64 debugging tools. (This situation applies to both x86-based and x64-based targets.)

Here what’s the difference between platform, and targets?

You ought to be able to figure that out.

A “target” is a system that is being debugged. It has the kernel
debugger enabled, to which a remote machine running windbg can connect.
That’s all.

“Platform” is just a generic word for the operating system on a machine.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

workingmailing@163.com wrote:

I category the windbg debugging use case:

Why are you doing this?

Questions:

  1. what is connect to remote session and remote stub usage?

Windbg has a client/server ability, where you run a small windbg server
on the machine that would ordinarily be the “host”, and the windbg
client on a machine far across a network. The client machine sees the
user interface.

Note that there are THREE computers in this case. The target machine
(the one being debugged, with the kernel debugger enabled), the host
machine (connected by RS232 or 1394 or local Ethernet), and the remote
client where the human being sits.

The diagram here explains this:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh451173.aspx

It’s also possible to do user-mode debugging like this, although I’m not
sure how useful that is.

  1. about Windbg x86 and x64

a. the host pc is win7 64, the target is Win8 or Win8.1 32/64 with bcdedit /debug on
I found in host, both x86 and x64 could be used for debugging target
So in this case, no matter target, and no matter host, both x86 and x64 is useful.

Right. You don’t have to worry about this. Seriously. Any combination
will work.

b. host pc is win7 64, bcdedit /debug on
x86 could not be used for kernel debug, while x64 is ok. why this case happen?

Are you talking about “local kernel debugging”? That’s just a weird
special case. In general, on a 64-bit system, you should run the 64-bit
windbg.

c. for user mode, host pc WIN7 64
both x86 and x64 windbg could used to debug a .exe file

Here is the ONLY case where I sometimes think about which debugger to
use. All processes on a 64-bit system start out as 64-bit processes and
then switch over to 32-bit if needed. You can certainly use the 64-bit
windbg to debug a 32-bit executable. When you do so, the debugger
starts up controlling the 64-bit loader. When you press F5, you get
another startup breakpoint when the process switches to 32-bit. That
doesn’t cause any problems at all (except for one extra keystroke), but
sometimes I will run the 32-bit windbg just to eliminate that first step.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

thank you very much.

You are really a expert on Windwos, but also on Windows debugging.
I got to known the initial/startup break for process from <>book.
Here you cite this works, it seems that you are also expert on windbg principles of windows.

I am very appreciate the debugging system design by Windows.
Windbg is early than Windows NT.
From the EPROCESS, PEB, there are debugport, and beingdebugged member, we can find, windows pay much attention to the debug.

This is a far more advance than Linux.

workingmailing@163.com wrote:

I am very appreciate the debugging system design by Windows.
Windbg is early than Windows NT.

That depends on how you look at it. The kernel debugger itself (the
target portion) was present in NT nearly from the beginning. The
debugger UI, naturally, followed shortly thereafter.

However, the command interface we see was derived rather directly from
wdeb386.exe, which was the kernel debugger for Windows 3.0 (and, I
presume, Windows 386 before that, although that was before I got here).


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.