M06 Remote Debugging

8/6/2019 M06 Remote Debugging

1/11

Remote Debugging


2/11

2 Remote Debugging

Information in this document, including URL and other Internet Web site references, is subject to

change without notice. Unless otherwise noted, the example companies, organizations, products,

domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,

and no association with any real company, organization, product, domain name, e-mail address,

logo, person, place or event is intended or should be inferred. Complying with all applicable

copyright laws is the responsibility of the user. Without limiting the rights under copyright, no

part of this document may be reproduced, stored in or introduced into a retrieval system, or

transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or

otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual

property rights covering subject matter in this document. Except as expressly provided in any

written license agreement from Microsoft, the furnishing of this document does not give you any

license to these patents, trademarks, copyrights, or other intellectual property.

2006 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, Windows 2000, Windows XP, and Windows

Server 2003 are either registered trademarks or trademarks of Microsoft Corporation in the United

States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their

respective owners.


3/11

Remote Debugging 3

Introduction

Topic ObjectiveSet the stage, explain whywe need remote debugging.

Lead-inAll of you likely work withnumerous remote accesstechnologies every day:Remote Desktop orTerminal Services, Outlookaccess via RPC overHTTPS, perhaps a variety ofhardware remote solutionslike Dells DRAC, HPs RMI,or IBMs RSA boards. In thismodule we will talk aboutdebugging in WinDbgremotely

In many cases it is not possible for person at the console of the computerrunning the Windows Debugger (windbg.exe) to successfully debug the

problem. This can be the case regardless of whether you are debugging aprocess in user mode or a whole server via kernel mode debugging. It also does

not matter if you are live debugging or working with a memory dump file.

Delivery TipMany customers requestthat Microsoft send anengineer onsite just to setup a user mode or kernelmode live debug sessionthat the Microsoft CriticalProblem Resolution teamwill remotely access via Live

Meeting.

The ability to remote outaccess to a debuggingsession for help fromMicrosoft or other vendorsvia the .server command orby accessing a Live Meetingsession is a key componentof this workshop thateliminates the COST andTIME associated withcustomers having to wait fora field engineer to arrive justto connect a debugger andremote it out for CPR.

Microsoft customers canwork with PSS via theMSSUPPORT Live Meetingconference center, availableon the web at:http://www.microsoft.com/ra

Here are some examples:

Physical Access

The computer being debugged might be in a server room which requires

additional physical security or might be an uncomfortable workingenvironment. Server rooms are often cold, noisy and chair-less. You might notwant to spend an extended period of time at the computer. In this case you can

connect the debugger at the server, but then move somewhere else to remotelyperform the work.

Geographic Location

It is possible that the problem machine is in a different part of the country (oreven in a different country) than the person best suited to perform the

debugging. One such scenario is when a Microsoft Support Engineer isdebugging a problem for a customer who could be located anywhere in theworld. We need to allow the Support Engineer to do the work without actually

being at the remote site.

Collaboration

As with any non-trivial problem, it can be more productive if more than oneperson is working on debugging a problem. By using remote debugging youcan enable collaboration between two or more people.


4/11

4 Remote Debugging

Connecting v ia Modem

Topic ObjectiveGive some history.

Lead-in

One of the earliest methodsof remote debuggingactually involved connectingthe TARGET computer to anexternal modem and havingthe remote debugger dialinto the device

One of the earliest methods of remote debugging involved connecting to akernel debugging session via modem. This was done by connecting an external

modem to the COM port that was specified in the boot.ini with the /debugparameters that were discussed in the kernel mode troubleshooting module. The

remote computer would then dial in to the modem and debug across thatconnection.

Delivery TipThis technique is rarelyused in the US anymore, butwe felt it was important toinclude for customers inareas where slow links and

dial-up are still commonlyused technologies.

This also gives somecontext around why todaywe kernel debug over NullModem cables.

To use this method of remote debugging to debug a user mode problem, a

debugger like windbg.exe was run on the target computer with the -d switchand attached to the specific user mode process to be debugged. The -dspecifies that all input and output for the user mode debugging should be routed

over the kernel debugging connection. There are some complicated differencesbetween kernel mode debugging and user mode debugging over a kerneldebugging connection, but this method of remote debugging is not commonly

used today.

The main drawbacks to this approach are that it is slow and requires a phone

line in close enough proximity to the target computer to connect a modem.

For more information about setting up a remote debugging session using amodem, see Microsoft Knowledge Base article 148954.


5/11

Remote Debugging 5

Remote Access to the Windows Debugger

Topic ObjectiveWhat do we use today forremote access?

Lead-inWe will generally separateremote access to theWinDbg session into twocategories, using thecommand built into WinDbgfor remote access, andusing any other remotecontrol technology you canthink of to remotely accessand control the computerrunning WinDbg

There are many ways to remotely control the Windows Debugger (windbg), butthey all fall into one of two categories. One approach is to use the remote

debugging capability built into windbg, which is used via the .server commandin the debugger. Another option is to remotely control the whole computer that

is running windbg with a remote control technology like Terminal Services,Remote Assistance, or Microsoft Office Live Meeting. Both of these situationscan be used for either user mode or kernel mode debugging.

No matter which approach you take, the local windbg.exe process is the onedoing the debugging work, accessing the symbol files, etc., and the remote

computers that are running either other instances of windbg or other clients likethe Remote Desktop Client.

Delivery Tip

The target audience for thiscase is ServerAdministrators and SeniorHelp Desk Technicians..Server will be new to mostpeople, but everyone islikely to already understandwhat is meant by otherremote control technologies.


6/11

6 Remote Debugging

.server

Topic ObjectiveIntroduce .server

Lead-in

The Windows Debuggerprovides its own remoteaccess support via the.server command, whichallows you to specify eithera TCP Port or a named pipeto listen for connectionson

The Debugging Tools for Windows help file (debugger.chm) containsinstructions for using the .server command in windbg.exe to open a TCP port or

named pipe for a remote user to connect and control the debugger. This featurehas many different options, but we have focused on the two most commonly

used parameters, tcp:port=XXXX and npipe:pipe=XXXX.

Once your debugger is configured to receive connections, other people can runwindbg on their own computers and use a connection string to specific that their

debugger should connect to the TCP port or named pipe on your windbginstance.

Activating the Debugging ServerThere are two ways to activate the Debugging Server. It can be activated when

the debugger is started by using the -server command-line option. It can also beactivated after the debugger is running by using the .server command.

The debuggers support two different transport protocols: TCP and NPIPE.

windbg.exe -server tcp:port=SocketNumber

windbg.exe -server npipe:pipe=PipeName

-or-

.server tcp:port=SocketNumber

.server npipe:pipe=PipeName

Activating the Debugging Client

Once the server has been activated, you can start the Debugging Client on thelocal computer and connect to the debugging session.

The protocol of the server must match the protocol of the client. There are two

ways to start a Debugging Client: by using the -remote command-line option, orby using the WinDbg graphical interface.


7/11

Remote Debugging 7

windbg.exe -remote tcp:server=ServerName,port=SocketName

windbg.exe -remote npipe:server=ServerName,pipe=PipeName

-or-

Open windbg.exe and select Connect to Remote Session from the Filedropdown menu (Ctrl+R). In the window that opens, enter a connection string

like:

tcp:server=ServerName,port=SocketNumber

npipe:server=ServerName,pipe=PipeName

NOTE: The remote windbg.exe process that acts as the debugging client does

not actually do any work. It is simply sending commands to the serverwindbg.exe process and receiving output back from it. Symbol files must be

accessible to the server windbg.exe process. Symbol files cached locally on theremote computer are not accessible in the debugging session.

Delivery TipBe certain that everyoneunderstands that debuggingsymbol files are onlyaccessed by the windbg.exeSERVER in the case ofusing .server.

Any symbol files stored onthe debugging client oraccessible on the remotenetwork of the debuggingclient that are not accessiblefrom the windbg.exeSERVER process are notable to be used.


8/11

8 Remote Debugging

Mini-Lab

In this demonstration, the .server command will be used to listen for remoteconnections on TCP Port 9999 and a second instance of WinDbg on the same

machine will be started to connect to the remote port.

Click on the Start button and navigate to All Programs DebuggingTools for WindowsWinDbg

From the File drop-down menu choose Open Executable.

In the Open Executable dialog box, browse to C:\Program

Files\Internet Explorer and open iexplore.exe

In the WinDbg command window, run the command: .servertcp:port=9999

Now we will start a second instance of WinDbg and connect to the serverprocesss TCP Port you just opened.

Click on the Start button and navigate to All Programs DebuggingTools for WindowsWinDbg

From the File drop-down menu choose Connect to Remote Session.

In the Connection String text box, type: tcp:port=9999,server=localhost

Click Ok.

Once you are connected from the second WinDbg instance, run someof the debugger commands we have learned in this workshop.

Obviously there is no practical use case for connecting from one process toanother on the same workstation, but this example illustrates use of the .server

command.


9/11

Remote Debugging 9

Remote Access to the Computer

Topic ObjectiveTalk about othertechnologies for remoteaccess.

Lead-inBecause .server dependson a direct TCP connectionor a named pipe, it generallyrequires that the remotecomputer be on the samecorporate network or at leastRASed into the corporatenetwork. Working aroundfirewalls, over the Internet,or to meet other needs, it isalso possible to remotelycontrol the computer

running WinDbg via anynumber of technologies

Another option is to use any technology that allows you to connect remotely tothe computer running the Windows Debugger (windbg.exe). Some examples of

this are Microsoft Office Live Meeting, Terminal Services or Remote DesktopConnection, Remote Assistance, Microsoft NetMeeting (conf.exe), WebEx,

pcAnywhere, or a hardware solution like an HP Remote Management Interface(RMI), Compaq Remote Insight Board (RIB-LOE), Dell Remote Access Card(DRAC), or IBM Remote Supervisor Adapter (RSA).

Live Meeting is probably the remote collaboration tool most commonly used byMicrosoft Support Professionals to remotely debug systems. By running

windbg.exe and starting the debug, then following the instructions at eitherhttp://support.microsoft.com/ra or provided to you by your Microsoft SupportProfessional, you can provide remote access to your debugger session to any

computer on the Internet over TCP Port 443.

Delivery Tip

Dont beat people up withthis page this should beimmediately obvious to mostparticipants.

Note: Sharing or remotely controlling the Windows Debugger over Live

Meeting, Remote Assistance, or another similar technology is no different thansharing any other application that is running on your computer.


10/11

10 Remote Debugging

Variety of Ways to Connect

Topic ObjectiveIllustrate that you dont needto settle on just one way toremotely control a

debugger

Lead-inNow that weve talked abouta few different ways toremotely control adebugging session, lets talkabout how you can mix andmatch these technologies tomeet your requirements forremote troubleshooting &debugging

Now that you understand the many technologies for remotely accessing theWindows Debugger, you can pick and choose the proper mix of technologies to

meet your needs.

For example:

If you were going to kernel debug a server via null modem cable and did notwant to sit in the server room to do so, you could connect the crash cart to theserver as discussed in the kernel mode troubleshooting module, and then open a

TCP port like 9997 with the command .server tcp:port=9997. Once back at

your desk you could connect remotely to WinDbg on the crash cart bylaunching the Windows Debugger via the command line windbg.exe -remotetcp:server=CrashCartName,port=9998.

Once connected, if you wanted to get help from a Microsoft Support

Professional, from your computer at your desk you could go tohttp://support.microsoft.com/ra to use Microsoft Office Live Meeting to share

the Windows Debugger application on your computer with your SupportProfessional over the Internet.


11/11

Remote Debugging 11

Review

Topic ObjectiveReview!

Lead-in

Lets review the topic wecovered in this module

Review Questions:

Delivery TipAnswer 1: Allows you tospecify a TCP Port orNamed Pipe that thewindbg.exe process willlisten on for otherdebuggers to connectremotely.

Answer 2: Yes!

Answer 3: The windbg.exeinstance that is actuallyattached to the TARGETServer (kernel mode) orTARGET Process (usermode) is the debuggeractually doing thedebugging and is theprocess that accesses thesymbol files. This is thedebugger that executes allcommands that are sent to itby other windbg.exeprocesses or othercomputers via Live Meeting,etc.

1.) What does the .server command do in WinDbg?

2.) Is it possible to use Remote Desktop or Live Meeting to remotely

control an instance of the Windows Debugger (windbg.exe)?

3.) In a remote debugging scenario, either with .server or anothertechnology like Live Meeting, which computer accesses the symbolfiles?

Documents

M06 Remote Debugging