The Ways of Debugging Part 1: Finding the Possible Root Cause

Background

Debugging can be easy for someone, and very hard for the other. After many years of debugging experience, I find that debugging usually consist of 3 big steps, that is:

1. Finding the possible root cause,
2. Prove the possible root cause to find the real root cause, and
3. Fix the real root cause

Additionally, debugging hardware has many similarity with debugging software, in which also has the 3 big steps above.

Finding the Root Cause

Finding the root cause is the very first step in debugging. In my opinion, it is also the most determining step. The total time required for debugging usually be heavily determined by finding the root cause. It is harder to find the root cause rather than fix the system.

In order to find the root cause, the very first requirement is to understand the system you are debugging. I have once need to debug a system in which I do not understand at all, and it takes the time for me to understand the behavior of system first. Only after that then I can finally continue to find the possible root cause.

Moreover, don't be surprised. Sometimes user will actually submit a bug, without steps to reproduce (especially in entrepreneur system, where the user usually know little of software engineering), complaining about a behavior that is already behave as designed. Without any documentation (that's right, no documentation at all!) about how the system behave, I need to find a person who know the system's behavior, to determine whether it is a bug or not. This is, why at most of the time, usually the tester can find the possible root cause easily, because they know well how the system behave.

Understanding the system first can also be very critical for finding some technical flaws. There flaws are such as race conditions, replication issues, different regional setting, different input format, hacks or security flaws, etc. Right, bad system design can be a root cause for bugs, with additional factor like not understanding the system, it will give you a headache.

Another requirement for finding the root cause is having decent technical knowledge about the platform or programming platform the system use. Some platform used by the system such as the database and application, usually has different behavior between each other. Say, for example, java mark the class and method as virtual by default, and in C# you need to specify with the "virtual" keyword.

Conclusion

Understanding the system and having knowledge about the platform will give you significant boost in time needed to find the possible root cause. I have experienced that I have once finding a possible root cause for a bug in system for only several minutes. It is, of course are made possible by the having knowledge of the system.

Much or less, documentation about how the system behave will help newcomers or debugger to find the possible root cause. Not only it will help to find the possible root cause, the handler can instantly know whether the bug raised by user is actually the system's design or not, or they need to configure something in for the user in order to able to do the required action.

Debugging Hardware Problem

Today, I boot the PC. The boot process goes smoothly until the windows trying to load. Suddenly a blue screen appear and the computer restarted.

If you ever have a pc for 3 years or more, you may experience similar situation as well. PC unable to boot, sudden restart in middle of work, or something like that may happen due to hardware failure.

An experienced one already know that hardware problem can be happened in many parts of hardware, such as CPU, RAM, hard disk, VGA, motherboard, power supply, etc. Similar with software debugging, finding a part of hardware which is the root cause can be a trouble. I find the debugging hardware problem is similar with one in software.

During the booting after my PC restarted, I try to run the windows in safe mode. Strangely, it can run well. Some common applications such as office and browser can be run normally, with the minus of good display and network support due to safe mode.

Normally, you cannot even able to boot at all when the CPU or RAM get any trouble. From this point, I believe that the RAM and CPU is still in good shape, eliminating two error possibilities. Troubled power supply normally cannot affort to boot the system too and not causing blue screen error. So, we get another parts eliminated, leaving both motherboard and VGA alone.

Both parts become the "possible root cause" which cause the error. From this forward, I begin to test the "possible root cause" to be proven. This step is meant to prove whether the possibility is actually the real root cause.

Luckily, my possibility is being strengthened by windows error message in safe mode, showing bcc code 116. After simple searching in Google (thanks Google), I can easily found some article mentioning bcc code 116 related to video graphic error. Now only one thing to prove: whether the system will boot up without using the graphic card.

So I start to reach device manager, disabled the display adapter, and begin restarting the PC. The result is, viola! The system successfully loaded. The application runs well, the browser connected to the internet, and nothing has problem except a poor - low resolution display. And a little lag because the rendering are not being done in graphic card anymore.

The suspect left to motherboard or VGA, which I haven't found the cause yet. That is because I do not has spare change for it. But the bigger suspect is VGA, because it is older than the motherboard.

Conclusion

Finding the cause of hardware error is very similar with debugging software. It is started by finding the possible root cause, proving the possibility, and then fixing the problem. Experience and knowledge also help in both cases, to speeding the discovery of possible root causes. And for both cases also, you need to know how the system behave / working, or you will need additional time to find how the system work.