. NET Program debugging skills (i): Some methods of locating anomalies quickly

This article is mainly introduced. NET Program debugging skills (i): Some methods of fast locating anomalies, this article explains the localization of native exceptions, in the customer environment positioning. NET program exception two aspects of the content, the need for friends can refer to the

As a programmer, solving bugs is the work we often do in our work, even the ability to solve problems is an important embodiment of one's ability to work. Because it reflects a programmer's skill level, technical depth, experience, and so on.

So in the process of solving bugs, locating problems is very important. "Finding a problem is half the problem," he said.

This article describes the rapid positioning of exceptions (specifically. NET program exception) method. Includes locating exceptions in the native location, locating. NET program exceptions in the customer environment, locating Silverlight exceptions in the customer environment.

One: Locating native exceptions

It is easy to locate anomalies on our native machine. Assuming that we are all using Visual Studio, just check the common langeuage Runtime Exception (CLR Exception) in the Debug-> exception menu. The following figure:

There are 5 types of exceptions that can be found in the picture above, such as C + + exceptions, Win32 exceptions, and so on. For. NET program, we only focus on CLR exceptions.

The next step is to debug, when there is an exception in your program code, VS will automatically navigate to the location of the exception.

We can see the details of the exception, and we can see the stack information of the program in the Call Stack window. In the stack information we can see which class, which function in the error, the following figure:

There are two ways to debug a program, one is to start the program with VS, the other is to attach to the process.

When attaching to a process, do not choose the wrong type of program, I use the. net4.0 so the program type chooses the managed (4.0 version) code.

Another shortcut key attached to a process is ctrl+alt+p.

But if the exception is not thrown in your code, how do you position it?

You can turn on the options and Settings under the Debug menu to enable the "Only My Code" option to cancel the check. Then the exception in someone else's code can be thrown.

Two: Locate. NET program exceptions in the customer environment:

Our program will eventually run in the customer environment, the customer environment will not have a vs such development tools, then how to do?

We can use a very small command-line debugging tool, Mdbg.exe, which is installed with VS and can only Debug. NET managed code.

Mdbg.exe actually has a lot of functions, but this article only talk about it to locate the exception function, the subsequent article will talk about the use of Mdbg.exe Single Step debugging method.

Mdbg.exe command Details You can enter H (Help) or? Name to view, or you can look at the links below,

http://msdn.microsoft.com/zh-cn/ms229861 (vs.80). aspx#

Mdbg.exe also has multiple versions, depending on the CLR version.

C:Program Files (x86) Microsoft Sdkswindowsv7.0abinmdbg.exe for debugging

CLR2.0 (corresponding net2.0,3.0,3.5) program.

C:Program Files (x86) Microsoft SDKSWINDOWSV7.0ABINNETFX 4.0 ToolsMdbg.exe is used to debug CLR4.0 programs (to use. net4.0).

In addition Mdbg.exe has a dependent DLL called MdbgCore.dll. We can copy the corresponding version of Mdbg.exe and MdbgCore.dll directly to the client machine for use.

A friend who does not install vs will be able to copy a package of my own package Http://xiazai.jb51.net/201506/other/U8DebugSetup.rar, which in addition to Mdbg.exe there are some other components that we will use later in the article.

The default will be installed in C:Program Filesu8debug.

Mdbg.exe the use of the method is very simple, double-click to open it, and then enter a (attach, show the additional process), enter, then list all the processes can be attached.

The PID represents the process identity,

Enter a 11940 attachment to the Consoleapplication2.ex sample program.

Then the program will break execution, and we can do some setup at this time. Leave the program automatically interrupted when an exception is encountered.

Enter command CA (catch) to see which events the current debugger encounters will be interrupted.

You can see that exception corresponds to igonre all exception, which is to ignore all exceptions and not break when an exception occurs.

Enter the command CA ex so that the debugger will break when it encounters an exception.

Entering the CA command again will see that the exception value has changed to stop on all exception. Any exception encountered will be interrupted.

Enter command g to allow the program to continue execution.

When an exception is encountered, it is automatically interrupted to the debugger, as shown in the following figure:

In the command W (where, where the program runs) you can view the exception stack information

Third: Locate the Silverlight exception in the customer environment

If the customer's Silverlight application server is deployed in an extranet, then we can access the Silverlight site directly in the browser and then use VS to attach to the browser process to debug.

Debugging methods are the same as debugging normal. NET programs.

But if the client's Silverlight server is deployed in the intranet, then you can only debug on the client machine.

And Mdbg.exe can't help you, it can't debug the Silverlight program.

We also have another famous debugging tool, WinDbg. The volume is probably less than 20M, easy to install to the client, installation package you can go to the Internet to download themselves. The WinDbg is divided into 32-bit and 64-bit two versions,

Debug 32-bit program please use 32-bit WinDbg, the other is to use 64-bit WinDbg, specifically why we do not need to delve into, remember it.

Compared with the small and practical Mdbg.exe, the WinDbg is obviously more powerful, but it is also more complicated to use.

WinDbg can actually debug many types of programs, such as normal. NET program, C + + and so on. But this article only explains how to use WinDbg to locate exceptions.

First we use IE browser to open the Silverlight application, and then open the WinDbg attachment to the IE process to debug. The process can be attached via the attach to a procedure under the File menu or by using the F6 shortcut key.

After the attachment process is interrupted to the debugger, we need to make two settings.

One is to interrupt the debugger when an exception is set up by opening the event filter under the Debug menu and setting the CLR exception to enable.

Additional debugger extensions need to be loaded, and friends who have used WinDbg know that debugging. NET programs requires loading a debugger extension SOS.dll. This sos.dll also has a Silverlight version of the.

Location in Silverlight's installation directory C:Program Files (x86) Microsoft Silverlight5.1.10411.0sos.dll.

We then enter the. Load C:Program Files (x86) Microsoft Silverlight5.1.10411.0sos.dll in the command window to load it.

Then enter command g to reply to the execution of the program. When an exception occurs, it is interrupted to the debugger.

The exception is that we can use!PE (print exception) to view the exception information. The following figure:

If you want to view stack information, you can enter a command!clrstack

Through the above method can basically locate all. NET exception. This concludes the article.