General strategy for finding the causes of accidental freezes?

I have an application that randomly crashes, including the IDE, and it makes me crazy. This makes me wonder:

What is a good general strategy for finding the cause of accidental freezes?

+4
source share
5 answers

If you're lucky, you can run your code in the debugger until it hangs, and then stop the debugger to find the line of code violation. But if it were that simple, you probably would not ask for advice. :-)

Two strategies that can be used together are “divide and win” and “leave bread crumbs”.

Divide and Win: Comment on an increasingly significant portion of your code. If it still freezes, you have reduced the amount of code that can cause delays. Caution: in the end, you will comment on some code, and the program will not freeze. This does not mean that the last bit of code is necessarily responsible for freezing; it is somehow connected. Return it and comment on something else.

Leave the bread crumbs: Make your program, tell where it is and what it does when it is running. Display a message, add to a log file, create sound, or send a packet over the network. Is the execution path as you expected? What was the last thing he did before he froze? Again, keep in mind that the last message may have come from a different thread than the one responsible for freezing the program, but as you approach this reason, you will adjust what and where the code is written.

+4
source

If you want to check outside the running application, I would potentially use the sysinternals.com toolkit from Mark Russonivich, the perfmon tool allows you to track access to files / registry and check the trace for delays - and what access is at that time. It will show a stack of DLL calls at the same time that the correct characters can be useful for debugging external application problems causing delays. (I used it to find out that the I / O filter associated with the security bundle was the reason the application tried to delay the delays by 1.5 seconds.)

+5
source

You are probably doing something in the user interface thread when you shouldn't.

+2
source

I installed the UserDump tool, and follow these instructions to create a custom dump of the application ....

Once you have a user dump, you can use WinDbg or cdb to check for threads, stacks and locks, etc.

Often I find that freezes are caused by blocked mutexes or such things.

+1
source

A good overall strategy is to run the program before it freezes. Then attach a debugger to it and see what happens. In the GUI program, you are most interested in what the user interface thread does.

You say the application freezes with the IDE. This should not happen, and I assume that this means that the program loads the OS so much (perhaps the load on the processor or memory) that the whole system is struggling.

Try to start it until it freezes, returns to the IDE and click the Stop button. You may have to be very patient. If the IDE is really constantly stuck, you will need to provide more detailed information about your situation in order to get useful help.

0
source

All Articles