64-bit Insider

Volume I, Issue 10

The 64-bit Advantage

The computer industry is
Remotely Debugging an
changing, and 64-bit technology
is the next, inevitable step. The
Unmanaged
64-bit Insider newsletter will help
you adopt this technology by
Application in Windows 64-bit
providing tips and tricks for a
successful port.
Remote debugging has been around for quite some time;
Development and migration of 64- however, it is during this 64-bit era that remote
bit technology is not as
debugging will become an indispensable tool for the 64-
complicated as the 16-bit to 32-bit
transition. However, as with any bit developer. In a 64-bit development environment, not
new technology, several areas do everyone will have exclusive use of an Intel EM64T
require close examination and server or an Itanium server. More likely, many
consideration. The goal of the 64- developers will have to share a 64-bit server to complete
bit Insider newsletter is to identify
debugging tasks. Fortunately, this does not mean that
potential migration issues and
provide viable, effective solutions every developer will have to have a remote desktop
to these issues. With a plethora of connection to the server or that everyone will be running
Web sites already focused on 64- Microsoft® Visual Studio® to debug applications.
bit technology, the intention of Furthermore, in some 64-bit servers, such as the Itanium,
this newsletter is not to repeat
remote debugging is the only way to debug code from
previously published information.
Instead, it will focus on 64-bit Microsoft Visual Studio® 2005.
issues that are somewhat isolated
yet extremely important to
understand. It will also connect
you to reports and findings from
64-bit experts.

64-bit Insider Newsletter

Volume 1, Issue 10
Page 1/5
Using Remote Debugging
To understand how remote debugging works, we must first understand how the regular
debugging cycle is completed. Figure 1 presents a simplified version of an application’s
development process.

Write/Port Debug Release

Code Code Product

Fix Bugs

Figure 1 High-level representation of the application development process

When planning the development of 64-bit application, you might assume that it would be
ideal to complete all development tasks on a 64-bit server, such as the Itanium or the
Intel EM64T. But this is not always the case.

For example, consider a situation in which the next-generation

“Visual Studio 2005 is of your organization’s line of business application is going to
packed with a plethora run on an Itanium 2 server. Writing code on the Itanium server
of great new features. and using Visual Studio 2005 is not possible because the
And one of the most developmental suite is not compatible with the Itanium
valuable is the ability architecture. While the specifics as to why this is the case are
to remotely debug an beyond the scope of this article, generally, it has to do with the
application on fact that Itanium 2 computers are high-end servers and not
Windows 64-bit from meant to be used as development computers. But rest assured,
any 32-bit computer.” there are several options that you can use to write code for the
Itanium 2 server and debug the code, beyond using the
Platform Software Development Kit (PSDK) and a Windows
Debugger (WinDbg), both of which are two excellent tools.

Visual Studio 2005 is packed with a plethora of great new features. And one of the most
valuable features gives you the ability to remotely debug an application on a Windows®
64-bit computer from any remote 32-bit Windows® system. If you are currently
debugging 64-bit code in Visual Studio that is running on an EM64T, you are already
using remote debugging. The only way that a 32-bit application like Visual Studio can
interact at the debug level with a 64-binary is out-of-process; remember that 32-bit code
and 64-bit code cannot exist within the same process space. Even though you did not
have to set anything in your integrated development environment, Visual Studio makes
all the necessary changes so that you are remotely debugging without even knowing it.

64-bit Insider Newsletter

Volume 1, Issue 10
Page 2/5
Understanding Remote Debugging
Remote debugging is a great way (and in some cases, the only way) to debug your 64-bit
code. For example, remote debugging provides the capabilities you need to overcome the
challenges encountered in Itanium 2 development (introduced above). First, you can
write the code in Visual Studio on a 32-bit workstation. Then, to debug your application,
you can use the remote debugging server on the 64-bit computer in conjunction with the
remote debugger in Visual Studio. Your 64-bit server will now allow many developers to
connect concurrently to debug their applications—unless you are doing kernel mode
debugging, in which case you would not want anyone else working in the system.

Setting up Remote Debugging

Follow these steps to set up your remote debugging environment.
1. Install the 64-bit Debugging Tools on the 64-bit server. To access the installation
files, navigate to the Remote Debugger folder (under the vs folder) on the Visual
Studio installation DVD. You will need administrative privileges to complete this
task. Installation is easy and will place all the necessary files in your computer so
that it can work as a remote server.

Note If you have installed Microsoft SQL Server™ 2005 on your 64-bit server,
then the Remote Debugger is probably already installed. Debugging SQL Server
2005 will be covered in a future issue of the 64-bit Insider newsletter.
2. Start the remote debugger in the 64-bit server by navigating to Start > Programs
> Microsoft Visual Studio 2005 > Visual Studio Tools > Visual Studio 2005
Remote Debugger (either Itanium or x64, depending on your architecture).
3. Set up special permissions in the “Visual Studio Remote Debugging Monitor” by
creating several user accounts with debugging permissions granted.
4. Select Tools > Options from the “Remote Debugger Monitor.” From the dialog
box that opens, specify which users will be allowed to connect to your server
remotely. While the example in Figure 3 shows “No Authentication,” for security
reasons, you should never select this option in your server. For more information
about how to create the necessary accounts with the correct debugging
permissions, please visit:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/vsdebug/html/vxtskinstallingdcom.asp
Configuring the Remote Debugging Client
After you have finished setting up the remote debugger, you are ready to configure the
debugging clients so that they can access the server. Follow these steps to configure the
remote debugging client.
1. Open project properties, access the Debugging node, and then select Remote
Windows Debugger from the list. Figure 2 shows the dialog box, filled out with
information for a sample C++ application that needs to be debugged.

64-bit Insider Newsletter

Volume 1, Issue 10
Page 3/5
 Figure 2 Remote Windows Debugger settings

2. Fill out the following fields:

 Remote Command refers to the path of the executable on the remote server
where the application to debug resides. You only need to copy the binary. The
debugging symbols are not required on the server, but are required on the
client computer.
 Command Arguments contains the parameters you wish to send to the
application, if any.
 Working Directory refers to the project folder path, which is the default one if
you leave this option blank.
 Remote Server Name is the name of the server; this can also be the IP address.
 Connection refers to the authentication type used when connecting to the
server. The example does not use authentication.
 Debugger Type refers to the type of debugging you would like to use. You can
use the default in most cases.
 Attach determines whether to attach to a running process on the 64-bit server.
 SQL debugging refers to whether you are going to be doing any SQL Server
debugging.
3. Press F5 on your project to start debugging.

From this point on, you should be able to follow the same debugging procedure you
would otherwise follow if you were debugging a 32-bit application. For example, setting
up breakpoints and stepping in and out of methods haven’t changed. However, some
processes will look slightly different. For example, while debugging select Debug >
Windows > Registers from the Visual Studio menu. You will see that your registers are
64-bit in size. (See Figure 3.)

64-bit Insider Newsletter

Volume 1, Issue 10
Page 4/5
 Figure 3 Registers are 64-bit in size.

Summary
Remote Debugging is very similar to the usual debugging techniques used in previous
versions of Visual Studio. The main differences are found when setting up and running
the remote debugging server, and when configuring your project properties—both
activities have been addressed in this issue of the 64-bit Insider newsletter.

Remote debugging is not always required when building 64-bit applications, but it is
helpful if you must share a 64-bit server with other colleagues. In addition, when writing
an application in Visual Studio 2005 that will run on an Itanium 2 server, remote
debugging might be the only way to debug the application. Whatever your case may be,
we hope you find this newsletter helpful when setting up your development environment.

For More Information

Visual Studio 2005 Remote Debugging
http://msdn.microsoft.com/netframework/programming/64bit/remotedebugging/

How to: Set Up Remote Debugging

http://msdn2.microsoft.com/en-us/library/bt727f1t.aspx

How to: Debug 64-Bit Applications

http://msdn2.microsoft.com/en-us/library/ms184681(VS.80).aspx

64-bit Insider Newsletter

Volume 1, Issue 10
Page 5/5