Technical Training
VB.NET 2005Table of Contents
Debugging Windows Applications In Visual Studio.NET 2005
Debugging Windows Applications In Visual Studio.NET 2005 - Page 2
Debugging Windows Applications In Visual Studio.NET 2005 - Page 3Debugging Windows Applications In Visual Studio.NET 2005 Page - 3
Debugging Windows Applications In Visual Studio.NET 2005
.
.
.
Ads
To attach to a running process
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 FilesMyApplicationMYAPP.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.
VB.NET 2005
- VB.NET 2005 Free Training
- The .NET Framework Architecture Part 1
- The .NET Framework Architecture Part 2
- Application Class and Message Class
- Implementing Class Library Object
- Visual Studio.NET Namespaces
- .NET Assemblies
- Differences between VB.NET 1.0 and VB.NET 2.0
- Introducing VB.NET Windows Forms
- Visual Studio Windows Forms Designer
- Exploring the Forms Designer generated code
- Setting and Adding Properties to Windows Form
- Implementing Inheritance
- Event Handling In Visual Basic .NET
- Building Graphical Interface elements
- .NET Common Windows Forms Controls Part 1
- .NET Common Windows Forms Controls Part 2
- Common Controls and Handling Control Events
- DomainUpDown and NumericUpDown Controls
- Dialog Boxes in Visual Basic .NET
- Visual Studio Adding Controls to Windows Form
- VB.NET Validation Controls
- Working with Menu Controls
- VB.NET MDI Applications
- .NET Exceptions
- VB.NET Creating and Managing Components Part 1
- VB.NET Creating and Managing Components Part 2
- Simple Data Binding
- .NET Complex Data Binding
- .NET Data Form Wizard
- Data Manipulation with ADO.NET
- SQL Server Stored Procedures
- SQL Server Ad Hoc Queries
- Finding and Sorting Data in DataSets
- ADO.NET Object Model
- Working with DataSets
- Using XML Data
- Working with File System in .NET
- Creating Web Service
- Instantiating - Invoking Web Services, Creating Proxy Classes with WSDL
- Web Reference and Web Services
- Web Services - SOAP, WSDL, Disco and UDDI
- Web Application Testing in VB.NET 2005
- Web Application Tracing and Debugging
- Working with Legacy Code and COM Components
- ActiveX Controls and Legacy Code
- Windows Application Testing
- VB.NET Windows Application Testing
- Tracing VB.NET Windows Application
- Debugging Windows Applications In Visual Studio.NET 2005
- Deploying Windows Applications In Visual Studio.NET 2005
- Customizing Setup Project in Visual Studio.NET 2005
- Shared Assembly
- Microsoft .NET Creating Installation Components
- The Registry Editor in Visual Studio.NET 2005
- The File Types Editor







