Windows RT Store app Debugging
Windows RT devices are now available so I thought I’d do a few posts on debugging tools for Windows Store apps on Windows RT and the ARM assembly generated with Visual Studio 2012 native (C++) tools. Understanding ARM assembly is a useful skill for debugging and troubleshooting, particularly if you ever work with process dump files or otherwise debug where symbol files and source may not be readily available.
Visual Studio 2012 does not install on Windows RT so you can’t build and directly debug applications on the Windows RT device. This means you will need a second machine running Windows 8 and Visual Studio 2012 to compile Store apps for a Windows RT device and will need to use the Visual Studio Remote Debugger to debug your Windows Store apps on Windows RT.
Note that only Store apps are supported on Windows RT – you won’t even be able to build a classic non-Store app in Visual Studio 2012 if you enable ARM as the platform configuration.
Installing the Remote Debugging Tools
The remote debugging tools can be downloaded from the Microsoft Download Center – click the Remote Tools for Visual Studio 2012 and then the Remote Tools for Visual Studio 2012 (ARM) link. You can download and install this from the browser directly on the Windows RT device, or copy it to a USB thumb drive and install from the thumb drive on the Windows RT device. The ARM remote debugging tools package is also available on the Visual Studio 2012 DVD, as rtools_setup.arm.exe in the vs\Remote Debugger folder. Copy the exe to a thumb drive to move it to the Windows RT device.
The remote debugger setup will lead you through the setup dialogs to install and configure the remote debugging tools. The tools will install into the c:\Program Files\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger\arm folder on the Windows RT device.
Starting the Remote Debugger Monitor
The remote debugger setup will install a Remote Debugger tile on the Start Screen of the Windows RT device. The first time that you touch this tile it will start a configuration wizard. This will lead you through a series of dialogs that allow you to configure the Windows Firewall and allow debugging on Private, Domain, and/or public networks. You must be running as an administrator this first time as the firewall configuration is being modified.
After the configuration dialog, the Visual Studio Remote Debugging Monitor app will start on the Windows RT native desktop. If you have done remote debugging with Visual Studio in the past then you should be familiar with this app – it looks and works the same for all architectures. It needs to be running on the Windows RT device when you start the remote debugging session from within Visual Studio 2012. When the debugger connects a remote debug session you will see a connect message in this app.
Configuring a Project for Remote Debugging
This is different depending on your project type.
C# and VB.NET projects
- In the project properties dialog, verify that the Platform is set to Any CPU in the Debug tab. You could choose ARM here, but Any CPU is recommended and will work for any architecture.
- Change the Target device property to Remote Machine.
- In the Remote machine property, type in the Windows RT machine name or it’s IP address.
C++ and JavaScript projects
- In the main toolbar, drop down the Solution Platforms combo box. Select the ARM platform for C++. You can use Any CPU for JavaScript apps
- In the project properties, select the Debugging tab. Change the Debugger to launch to Remote Machine. (if not set already).
- In the Machine Name type in the Windows RT machine name or it’s IP address.
The machine name should work fine in most scenario’s. However, if you have trouble connecting with the machine name, try the IP address. The IP address can be easily determined by running the IPCONFIG utility in a Command Prompt on the Windows RT device. On the right-hand side of the screen, sweep in to bring up the Charm bar. Touch Search, the Apps, then type in CMD. Touch the Command Prompt tile that appears in the search app. Type ‘ipconfig’ in the command prompt to find the IP address. If you don’t know the machine name, you can find that with ‘ipconfig /all’.
Starting the Debugger
At this point you should be able to start the debugger with the F5 function key, or by selecting Start Debugging from the Debug menu. Your project should build, if out of date. Then you will see a message in the output window that the app is deploying to the remote device. The first time that you deploy to the Windows RT device, you will see a dialog related to installing a developer license on the Windows RT device. On the Windows RT device, you will see a dialog prompting you to acquire the developer license. Follow through the dialog instructions to sign in to your Windows account and acquire the developer license. This developer license is required in order to deploy test applications to Windows RT.
At this point, app deployment should continue. Your Windows Store app will be deployed and installed onto the Windows RT device and started under the remote debugger. You will now be able to use the Visual Studio debugger to remote debug your app on Windows RT.
User Accounts
Typically, you will start both Visual Studio 2012 and the Remote Debug Monitor on the Windows RT device under the same account. The easiest way to do this is to log in with your Windows account (previously called Windows Live account) on both machines.
However, if running Visual Studio 2012 under a domain account you have the problem of not being able to use the domain account on Windows RT -- Windows RT cannot be domain joined. You can resolve this by using a ‘shadow’ account on the Windows RT device to enable debugging from your domain account to the Windows RT shadow account. A shadow account is simply a local machine account on the Windows RT device with the same user name and password as the domain account.
For example, if running Visual Studio under a Contoso\Steve domain account, I can create a local account for Steve on the Windows RT device. In other words, with a machine named Win8RT, I would create a local account Win8RT\Steve. Make sure that both Contoso\Steve and Win8RT\Steve accounts have the same password and you should then be able to connect the debugger running under the Contoso\Steve account and the remote debug monitor running under Win8RT\Steve.
Comments
- Anonymous
February 18, 2013
The comment has been removed