Saturday, November 18, 2017

Installation and First Contact With the New WinDbg

These days it is being my first contact with the new Windbg. There are fantastic things in this new version, I am still discovering and enjoying it. I decided to write this short post about the particular installation of the new WinDbg and the way that I needed to configure VirtualKD’s vmmon to attach the new WinDbg to the selected running VM from the vmmon menu.

New Windbg’s Executables

We execute WinDbg from installation shortcut and we search the main process. The main new WinDbg process is DbgX.Shell.exe:

It is a .Net executable:

When I tried to execute this .Net executable from command line, it didn’t work. Thought I tried with admin cmd.exe, not worked. Access denied.

The installation creates another exe here:


It is zero bytes, and if you try, for example, to copy it, you can’t.

Really, it is not an executable. It seems to be an NTFS Reparse Point ( We try with Mark Russinovich’s junction tool (, but it doesn’t show any info because it seems not to be a Symbolic Link (

I have not found a tool or way to manage or get information about these files.

FIX: it is possible to use fsutil to query information about the reparse point. Thanks for the correction.

If we capture with Process Monitor:

We can see FSCTL_GET_REPARSE_POINT ioctl code. The target of the reparse point is DbgX.Shell.exe (C:\Program Files\WindowsApps\Microsoft.WinDbg_1.0.14.0_x86__8wekyb3d8bbwe\DbgX.Shell.exe).

Integration with VirtualKD

New WinDbg works perfectly with VirtualKD (follow this instruction to configure the environment), however this issue with the new windbg’s executables that I have explained brought me some problems to configure Virtual Machine Monitor menu to launch new WinDbg for the selected VM.

We can’t use the default WinDbg.exe / Kd.exe options because new WinDbg needs different parameters. So we need to choose the “custom” option:

It is not possible to call DbgX.Shell.exe directly, it happends the same thing that when I executed it from command line. We need to launch it throught the reparse point, WinDbgX.exe. Old windbg.exe accepted parameters with “-“, for example -k. New Windbg needs /k parameter to pass the connection configuration:

FIX: Again my mistake here, WinDbgX accepts -k too like the previous version.

You need to configure it in this way to launch new WinDbg directly from VirtualKD:

C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\WinDbgX.exe /k com:pipe,resets=0,reconnect,port=$(pipename)

Other Details

The new interface is very much elegant and comfortable, however there are some things that I think they could be improved.

For example, In the disassembly window, it is not possible to enter an address (or I have not found the way). You always see the current eip address. If you execute “.iframe” command, you can move to the ret address for the frame. But you can’t move freely to any address that you want in this window. It’s weird. You can use the “u” command to disassemble any address and see the results in the commands window, but it is always useful to be able to enter any address into the disassembly windows.

In addition, it seems you can’t open multiple memory windows. It is an option that is present in the old WinDbg, and it is very useful.

About scripting, it supports old scripts, but something has changed in the engine. Some scripts that work perfectly with old WinDbg, they stopped working with the new version. For example, an script was changing process context with “.process /i <process>;g;”, and this seems to be problematic with the new version.

However, this new version introduces a very much powerful scripting. I can’t comment too much about this new scripting, because I have not started with it yet and it deserves one or more entire posts for it.

No comments:

Post a Comment