Debugging, debugging, debugging...

A. How to hostCodeAnd the unmanaged CLR environment for simultaneous debugging?

The steps are far simpler than you think, and more importantly, easier than windbg. Example:

1.	Open a C # project and open the Properties window of the project.
2.	Select enable unmanaged code debugging on the debug page
3.	Set the breakpoint at a statement, F5 re-compile, run, and hit the breakpoint
4.	Open the immediate window and enter! Load SOS. dll load CLR debugging extension (this SOS. dll is provided by. NET Framework 2.0 SDK)
5.	Then you can enjoy it in the immediate window! Dumpstackobjects ,! Dumpclass ,! Dumpmt. Let's have a look at the inside of CLR .! Help is help
6.	Using this method, the debugging of managed code is no different from that in normal times.

B. Can I use Visual Studio 2005 to debug the managed code compiled by rotor 2.0?

No. The rotor does not fully support debugging the hosted code. It can only use its own cordbg for debugging (it was accidentally found that the cordbg version of the rotor is actually higher than the SDK 2.0, one is 2.0.50826, one is 2.0.50727 RTM .... -_-B)

C. Can I use Visual Studio 2005 to track and debug unmanaged rotor code?

Although you cannot directly use vs2005 to debug the managed code compiled by the rotor, debugging the rotor itself is acceptable! The steps are not very complex:

1.	use NotePad to edit the SOS compiled by the rotor. DLL. manifest file (for example, D: \ rotor2 \ binaries. x86chk. rotor \ SOS. DLL. manifest)
2.	copy ... enter the paste in c: \ Program Files \ Microsoft Visual Studio 8 \ common7 \ ide \ devenv.exe. saved in the section of the manifest file
3.	Assume that the full path name of the hosted test file compiled in rotor2 is D: \ rotor2 \ samples \ hello.exe.
4.	Enter "devenv/debugexe Clix D: \ rotor2 \ samples \ hello.exe" in the rotor console to start vs2005 and load Clix
5.	F5 start. wait a few seconds to make sure that the environment is started when the rotor is running. Then press Ctrl-alt-break to seize the interrupted Clix execution.
6.	Open the immediate window and enter! Load D: \ rotor2 \ binaries. x86chk. Rotor \ SOS. dll, and load the CLR debugging extension compiled by the rotor.
7.	A good show has begun! Fast single-step tracking, input> CMD /! Threads /! Try dumpstack!

D. "wait a few seconds, make sure that the environment is started when the rotor is running, and then press Ctrl-alt-break to seize and interrupt its execution." What does that mean?

That is to say, when debugging a rotor, it is critical to set breakpoints reasonably and timely. For simplicity, you can use a console in the simple example above. the Readline statement temporarily locks the execution of the process. After it is started, wait a moment and press Ctrl-alt-break to return to the debugger. This ensures that the environment of the rotor is loaded when it is interrupted.

To be more professional, you can also set environment variables to enable the auxiliary debugging mechanism of the rotor, such as complus_breakoneeload and complus_jitbreak. This is more accurate and convenient than the "speculative breakpoint, I will not talk about it here. For more information, see the debugging documentation provided by the rotor.

references:
[1] drill. net Framework Internals to see how the CLR creates runtime objects, msdn magazine, May 2005
[2] SOS: It's not just an ABBA song anymore, msdn magazine, msdn magazine, Jun. 2003
[3] SOS debugging with the CLR, Jason Zander's blog, Oct. 2003