Debugging a bad coding exception

A few days ago, ourProgramAn error occurred while performing the longevity test and reported "the file exist". However, in our local test environment, we did not try to reproduce the problem, finally, lock the target to the DLL of several other projects according to the log, and use reflector to decompile the review code. The root cause of the problem is the path. gettempfilename () throws an exception in some cases, and msdn writes:

The gettempfilename method will raise an ioexception if it is used to create more than 65535 files without deleting previous temporary files.

You see, no wonder we can't reproduce this. How many tests are required to create 65535 files. To sum up the difficulty of solving this problem, the DLL has some very bad exception handling methods. The following is an example:

Class Program
{
Private void test1 ()
{
Try
{
//... Encode Codes
Path. gettempfilename ();
//... Encode Codes
}
Catch (exception ex)
{
Throw new exception (ex. message); // it must not be written like this, because it will change the trace of exception, leading to difficult locating. At least it should also be written as throw NEX exception (MSG, ex );
}
}

Public void Test2 ()
{< br> try
{< br> test1 ();
}< br> catch (exception ex)
{< br> console. writeline (ex. tostring ();
}< BR >}

Static void main (string [] ARGs)
{
Program PRG = new program ();
While (true)
{
PRG. Test2 ();
Thread. Sleep (2000 );
}

Console. Read ();
}
}

Later, I was wondering if I could locate this problem if I used windbg? After some experiments, the answer is yes. Next time you encounter a trace that is unclear, you can try a similar method below.

1. First give a close-up when the program is running

We can see that the trace information at this time can only be located in test1, and if there are a lot of method calls in test1, it is difficult to continue positioning.

2. Open windbg, attatch the process, and set the breakpoint to stop when an exception occurs.

Here are some of the commands:

Sxe CLR: Enabling windbg to break on CLR exceptions

! Soe-derived: Break on all exception which derive from a specific type.

G: Go on

! PE: Print exception.

OK, pass! The PE command shows that the expected "the file exist" has appeared. What are you waiting for? print the current stack immediately.

Now let's look at how clear the trace information is, and we can immediately find that the gettempfilename () has a problem.

The other method is to directlyCodeThe main process is to decompile and locate the position of the code line.

 

The screenshot is as follows: