.

.

.

1. From the Debug menu, choose Attach to Process. (If no project is open, choose Attach to Process from the Tools menu.)

2. In the Attach to Process dialog box, find the program you want to attach to from the Available Processes list. If the program you want to debug is running on another machine, you must first select the remote machine

3. Click the Attach button.

The Available processes list is displayed automatically when you open the Processes dialog box. Processes can start and stop in the background while the dialog box is open, however, so the contents may not always be current. You can refresh the list at any time to see the current list of processes.

You can be attached to multiple programs when you are debugging, but only one program is active in the debugger at any given time. You can set the active program in the Debug Location toolbar.

All Debug menu execution commands affect the active program. You can break any debugged program from the Processes dialog box.

Deal With Attach Errors

When the Visual Studio debugger attaches to a running process, the process can contain one or more types of code. The code types the debugger can attach to are native, managed, T-SQL, and script. These code types are displayed and selected in the Attach to Process dialog box.

Please Note: For the debugger to attach to code written in Managed C++, the code needs to emit DebuggableAttribute. This can be added to the code automatically by linking with the /ASSEMBLYDEBUG linker option.

Sometimes, the debugger can successfully attach to one code type, but not to another code type. This might happen if the users are trying to attach to a process running on a remote machine. The remote machine may have remote debugging components installed for some code types but not for others. It can also happen if the user tries to attach to two or more processes for direct database debugging. (SQL debugging supports attaching to a single process only.)

If the debugger is able to attach to some, but not all, code types, the user will see a message box with a message similar to this:

The requested attach was not completed successfully.

Program types successfully attached are:

• Common Language Runtime
• Native (Win32)
• Microsoft T_SQL

Program types that failed to attach are:

• Script

If the debugger successfully attaches to at least one code type, you can proceed to debug the process. The user will be able to debug only the code types that were successfully attached. The example message above shows that the script code type failed to attach. Therefore, the user would not be able to debug script code within the process. The script code in the process would still run, but the user would not be able to set breakpoints, view data, or perform other debugging operations in the Script.

If more specific information is required about why the debugger failed to attach to a code type, the user can try reattaching to only that code type.

To obtain specific information about why a code type failed to attach

1. Detach from the process.

• From the Debug menu, choose Detach All.

2. Reattach to the process, selecting only a single program type.

1. In the Attach to Process dialog box, select the process in the Available Processes list.
2. Click the Select button.
3. In the Select Code Type dialog box, select Debug these code types and the the code type that failed to attach. Clear any other code.
4. Click OK. The Select Code Type dialog box closes.
5. In the Attach to Process dialog box, click Attach.

This time, the attach will fail completely, and a message box will be displayed with a specific error message.

Debugging a Remote Process

Applies to Native Only.

COM applications perform a number of tasks outside of the programmer's direct control. Communication between DLLs, usage counts on objects, and Clipboard operations are just a few of the areas where the user might encounter unexpected behavior. When this happens, the first step is to track down the source of the problem.

A COM server and container can be debugged using two projects within the same solution. Set appropriate breakpoints in each project and debug. When the container makes a call into the server that hits a breakpoint, the container will wait until the server code returns (that is, until you finish debugging it). Calls can be traced that go across process boundaries.

Debugging a COM container is similar to debugging a standard program. One difference is when event is debugged it generates a callback (such as dragging data over the container application). In this case, breakpoint must be set in the callback function.

The Visual Studio debugger supports stepping across and into containers and servers. This includes the ability to step across remote procedure calls (RPC).

A remote procedure call (RPC) can be used to debug COM client/server applications. RPC must be enabled for debugging to use it. With RPC debugging enabled, when the user steps into the server call from the client, the debugger attaches to the server and lets its code be debugged. Once the debugger is attached, all debugger features can be used with both the client and server processes.

To enable RPC debugging
1. From the Tools menu, click Options.
2. In the Options dialog box, click the Debugging folder.
3. Click the Native page.
4. Select the RPC debugging check box.

Note To debug RPC calls, you must have Administrator or Power User privileges.

Debugging the Code in DLL files

Native Only

When you debug a DLL, you can start debugging from:

• The project used to create the executable that calls the DLL.
  - or -
• The project used to create the DLL itself.

If the project used to create the executable is available, it is useful to start debugging from that project. A source file can be opened for the DLL and breakpoints in that file can be set, even though it is not a part of the project used to create the executable. If debugging is started from the project that creates the DLL, the user must specify the executable that must be used in debugging the DLL.

To specify an executable for the debug session

1. In Solution Explorer, select the project that creates the DLL.
2. From the View menu, chooseProperty Pages.
3. In the Property Pages dialog box, open the Configuration Properties folder and select the Debugging category.
4. In the Command box, specify the path name for the container. For example, C:\Program Files\MyApplication\MYAPP.EXE.
5. In the Command Arguments box, specify any necessary arguments for the executable.

If the executable is not specified in the ProjectProperty Pages dialog box, the Executable for Debugging Session Dialog Box appears when debugging starts.

In this lesson we have examined the process of using the testing and debugging tools for a Windows application. In the last lesson of this series we will be studying how to deploy a Windows based application.

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Show/Hide comments

Show/Hide comment form