I've had to do this just a few times in the past several years, and I keep forgetting to blog it... but here goes. If you have a hanging issue in your application, it's easy to debug by attaching to the process through VS.NET. But what if the hanging only happens on a deployed machine without VS.NET installed? You can use cordbg.exe as follows...

- copy the below files from a developer's machine (with VS.NET or .NET SDK installed) to the machine with the issue
 msvcr71.dll
 msvcp71.dll
 msdis140.dll
 cordbg.exe.config
 cordbg.exe

- the user should have a hanging .NET app currently running. If not, have them run the app and recreate the problem.

- find the PID for the app by looking in task manager (you many need to add the PID column in to view it by selecting View/Select Columns from the menu)

- start cordbg.exe from a command prompt.

- attach to the .NET process... at the (cordbg) line, enter
 a {pid}
 where {pid} is the process id you found from task manager

- you can enter "sh" to show the source code lines of the current breakpoint.

- List the loaded modules in the process using the l mod command.
 The command line is shown below:
 (cordbg) l mod

- Display and examine the call stack trace for all current threads using the *w command. This should show what line the process is hanging on (assuming the PDB file is present for the hung assembly). Specify an argument of 200; this lists up to 200 levels of stack trace.
 (cordbg) *w 200

- Now detach from the process, and quit the debugger:
 (cordbg) de
 (cordbg) q