Microsoft KB Archive/312400

= HOW TO: Troubleshoot Third-Party .NET-Connected Language Applications =

Article ID: 312400

Article Last Modified on 5/13/2007

-

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:  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. At the command prompt, type the following command, and then press ENTER to start the runtime debugger (Cordbg.exe):

cordbg.exe

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

path

 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:  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. 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  /output:

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.</li> 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=  ...]

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.</li> At the command prompt, type the following command, and then press ENTER to start the runtime debugger (Cordbg.exe):

cordbg.exe

</li> In the debugger environment, use the run command to associate the debugger with an executable file that you want to debug.</li> 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.</li> 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.</li></ol>

<div class="references_section">