HOW TO: Troubleshoot Third-Party .NET-Connected Language Applications (312400)


The information in this article applies to:

  • Microsoft .NET Framework 1.1
  • Microsoft .NET Framework 1.0
This article was previously published under Q312400

SUMMARY

This article describes how to troubleshoot third-party applications that are created for the .NET Framework.

Microsoft Visual Studio .NET features a plug-in architecture that permits you to integrate third-party compilers in the Visual Studio .NET environment to produce applications that are created for the Microsoft .NET common language runtime. Because you create these applications by using third-party intermediate languages, you can use the .NET debugging tools. You can also use the .NET tools to decompile and troubleshoot issues in these applications.

MORE INFORMATION

The information in this article uses Cordbg.exe as the debugger. Most debuggers provide capabilities and features similar to those that Cordbg provides. For more information, see the documentation of the debugger that you are using. For more information about Cordbg, visit the following Microsoft Web site:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrfruntimedebuggercordbgexe.asp

This article also discusses how to troubleshoot a third-party .NET-connected application by using Cordbg. Although you can debug an application without using the original source files and the debug symbols file, you must have sufficient information about the operation codes of the microprocessor and the function parameter passing conventions for the processor family.

Acquire Source Code and Debug Symbols for the .NET-Connected Assembly

If your third-party .NET-connected application provider can give you the debugging symbol information or the source code files of the application, access to these files makes troubleshooting the application easier.

When you have access to the symbol files, put the symbol files in a specified location in your file system. To do this, follow these steps:
  1. Click Start, point to Programs, point to Microsoft Visual Studio .NET (for Microsoft Visual Studio .NET 2002) or Microsoft Visual Studio .NET 2003 (for Microsoft Visual Studio .NET 2003), point to Visual Studio .NET Tools, and then click Visual Studio .NET Command Prompt or Visual Studio .NET 2003 Command Prompt.
  2. At the command prompt, type the following command, and then press ENTER to start the runtime debugger (Cordbg.exe):

    cordbg.exe

  3. In the debugger environment, type the following command, and then press ENTER to specify the path for the symbol files:

    path path of the symbol files

  4. Now when you start a process that has to be debugged, then the debugger looks for debug symbol files in the path specified through the path debugger command.

Generate Debug Symbols for an Existing .NET-Connected Assembly

If you do not have any source code or debug symbols information, you can still debug at the Microsoft intermediate language (MSIL) level. To generate the debugging symbol information and the intermediate language code to run the debugger against, follow these steps:
  1. Click Start, point to Programs, point to Microsoft Visual Studio .NET (for Microsoft Visual Studio .NET 2002) or Microsoft Visual Studio .NET 2003 (for Microsoft Visual Studio .NET 2003), point to Visual Studio .NET Tools, and then click Visual Studio .NET Command Prompt or Visual Studio .NET 2003 Command Prompt.
  2. Use the MSIL Disassembler tool (Ildasm.exe) to decompile the .NET-connected assembly to the MSIL code. To do this, type the following command at the command prompt, and then press ENTER:

    ildasm executable file name for a third-party application /output:specfiy a file name that has the file name extension *.il

    Note If any resource files are embedded in the .NET-connected assembly, they are stored in separate files that have the *.res file name extension.
  3. Recompile the MSIL code that the Ildasm tool generates to a .NET-connected assembly. Use the debugging symbols that the Ilasm tool generates. To do this, type the following command at the command prompt, and then press ENTER:

    ilasm /DEBUG /RESOURCE=resource file name (*.res) [/RESOURCE=resource file name (*.res) ...] file name of the MSIL code that was generated for the application (*.il)

    Note The Ildasm tool generates the MSIL file (that has the *.il file name extension) and the resource files (that have the *.res file name extension) when you do step 2.
  4. At the command prompt, type the following command, and then press ENTER to start the runtime debugger (Cordbg.exe):

    cordbg.exe

  5. In the debugger environment, use the run command to associate the debugger with an executable file that you want to debug.
  6. Use the break command to set a breakpoint at any of the symbols that are defined in the executable, and then use the go command to continue the current process.
  7. When the debugger hits the breakpoint, notice that the step where the debugger stops refers to the intermediate language code instead of to the instruction codes that are associated with the microprocessor where the process is running.

    This behavior is helpful when you debug because there are fewer instructions in the MSIL code than there are in the instruction codes of the microprocessor family and the instructions are not as complex. Also, the MSIL code does not change, regardless of the processor where the process is running.

REFERENCES

For more information about the MSIL Disassembler tool (Ildasm.exe), visit the following Microsoft Web site:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpconmsildisassemblerildasmexe.asp



For more information about the MSIL Assembler tool (Ilasm.exe), visit the following Microsoft Web site:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpconmsilassemblerilasmexe.asp

Modification Type:MajorLast Reviewed:7/13/2003
Keywords:kbDebug kbhowto KB312400 kbAudDeveloper
©2003 Microsoft Corporation. All rights reserved.