Windbg + winrt (woa windows on arm) kernel debug

I want to debug the AP and driver on Woa.

Currently, windbg does not have an arm version, so it cannot be debugged as easily and quickly as x86 and x64 platforms. Therefore, we have to try it through remote debug.

First of all, we thought of using windbg to debug the kernel of the local machine. In woa wdk, we really had the windbg arm version. We were very excited to install it. When we opened the kernel debug, we found that local was not supported at all, it always shows that you need to run "bcdedit/debug on" and "reboot". I tried it many times and kept repeating this prompt. Failed to enter kernel debug.

The second thought was the use of USB debug cable, dual-host interconnection, through windbg for debugging, did not expect woa does not support this method. The reason is as follows. After the debug mode is enabled, the connection fails.

The last thought was to use remote debug of vs2012, but the remote debugger supporting arm was not found in the vs2012 directory, only x86 and x64.

All right, the above method won't work, so we have to collect it on the network. According to the video of the Win8 press conference, we can directly use USB Direct cable for interconnection. We need to find a special port on Woa, in debug mode, this port is regarded as a USB debug target. After the two machines are interconnected, the target machine is regarded as a USB debug target, on the source machine, you can see a mocrosoft USB debug target through devcie manager. The source machine here is the win7 system, and the system can automatically identify this device. Other systems can try to manually load the driver usb2dbg. sys. Open windbg and select Kernel
Debug-> USB can be smoothly connected to the target machine.

OK. Enable windbg on the source machine. It indicates that connect is successful,... But there is no log. Why? It seems that arm is not so easy to show logs. An article on OSR describes how to enable log on the target machine. Reference: http://www.osronline.com/article.cfm? Article = 295

Getting dbuplint output to appear in Vista and later

OSR staff | published: 11-may-04 | modified: 25-Jan-13

The problem: Your dbuplint or kdprint messages don't appear in windbg (or kD) when you run your driver on Windows Vista, Windows 7, or Windows 8.

The reason? Versions of Windows starting with Vista automatically map dbuplint and friends to dbuplintex. Now, you may recall that dbuplintex allows you to control the conditions under which messages will
Be sent to the kernel debugger by filtering messages via a component name and level in the function call and an associated filter mask in either the registry or in memory.

Dbuplint and kdprint are mapped to component "tables" and level "dpfltr_info_level". Of course xxx_info_level output is disabled by default. So, by default, your dbuplint/kdprint doesn't get sent
To the kernel debugger.

 

How to fix it? Two choices:

• Enable output of dbuplint/kdprint messages by default-- Open (or add, if it's not already there) the key "HKLM \ System \ CCS \ Control \ Session Manager \ debug print filter". Under this key, create
  A value with the name "default" set the value of this key equal to the DWORD Value 8 to enable xxx_info_level output as well as xxx_error_level output. or try setting the mask to 0xf so you get all output. you must reboot for these changes to take effect.
  Note... don't set the value named "(default)" -- you actually have to create a new value with the name "default" and set that to whatever value you want (0xf, for example ).

• Specifically change the component filter mast for dpfltr. Starting with Windows Vista you need to set the mask value for the DWORD at kd_default_mask ("Ed kd_default_mask"). You can specify
  8 to enable dpfltr_info_level output in addition to dpfltr_error_level output, or 0xf to get all levels of output.

See the wdk documentationReading and filtering debugging messages(Follow the path: driver development tools \ tools for debugging Drivers \ Using debugging code in a driver \ debugging code overview)
For the complete details on the use of dbuplintex/kdprintex. Or look atDebugging tools for WindowsDocumentation (Appendix A) on dbuplintex.

Tweet

I tried the above method and still could not generate logs. Finally, I ran the following command in windbg to see the log:

Ed kd_dpfltr_mask 0xff

So far, windbg + woa smoothly enters the kernel debug mode.