Editing Category:Common Issues (section)

== Troubleshooting Basics (generally small electronic components)  ==

=== Introduction ===
This article is a starting point that can and should be expanded and elaborated on. Please be aware there might be omissions or oversights, and not all instructions may apply to your specific issue or device.
Before all, apply a generous amount of judgement.

=== General Advice ===

* Try the easiest thing first.<ref name=":0"> https://www.youtube.com/watch?v=ic5R4C5HRUg </ref> Check power source.  Reboot.
* Don't trust the other guy (the one who worked on it before you).<ref name=":0" />
* 90% of problems are human error or oversight.<ref name=":0" />

* Build a conceptual map of how the device should work, and how the parts that do work connect to the ones that don't.
* Verify the problems that it got returned for. Run self tests if possible. Verify for yourself that the user properly identified what the issue is{{---}}they likely have worse troubleshooting skills than you and may make mistakes.
* Get enough sleep. If something doesn't make sense, move on and come back after a rest with a clear mind. 9 times out of 10 you will find what you were missing before.

=== Formalized Troubleshooting Framework ===
These "best practice" steps have proven themselves in many real world situations.
The first steps are analytical and preventive actions that can (should...) always be taken, regardless of what the issue on hand is.

* Make a conceptual map/block diagram of the intended functionality and how different parts of the system interact.
** See if you can obtain any documentation for the device, from user manual to service manual. Having anything at all can help you understand how the device is intended to work, regardless of your expectations.
** Often times, block diagrams are included in operators manuals in the troubleshooting section, and almost always in the service manual. They may also be included on schematics. These should be your bread and butter for approaching unique problems.

* Document the case as presented by the client.
** Verify that the user has done the troubleshooting properly{{---}}they may misunderstand how something is supposed to work, and lead you down the wrong path.
** See for yourself that the issue the user is experiencing is what they think it is. This could change how much they are willing to pay, especially if they underestimate what they think is wrong.
* Note the failure and repair history of the equipment.
* Analyze and document the current state of functionality as positives or negatives.
** Use the block diagram you constructed earlier to verify that each stage of the device is working as it should. When you find where something is wrong, you know that all of the previous stages work correctly and you won't have to waste time backtracking.
** Make notes of all the areas that are misbehaving{{---}}they may be correlated. Take a step back and see if the problems could be related{{---}}do they share any functionality?
** Approach this as methodically as possible.

Now you have a dossier for the equipment that you can refer to for your technical analysis.

Before you begin working on anything, do the following:

* Disconnect the equipment from power.
* Remove all batteries and anything extraneous (hard drives, optical drives, etc)

This will minimize the risk of cumulative and/or collateral damage, as well as ensure that no other parts of the system are interfering with what you're working on. If you find that it works but stops working when you add sub-components back in{{---}}there is your clue. The key in this whole process is to approach everything as methodically as possible. It will save you a lot of time and headache when you will be able to easily follow your previous steps and verify to yourself/others what the problem is. If you can't understand or explain what you did, the problem likely isn't fixed (at least permanently).

=== Initial Overview and Analysis ===
First things first{{---}}try to boot it up. Does it turn ON? If no, and this matches the problem that the user brought it in for, then you're good. You can probably just open it up and start taking a look. If that isn't what they brought it in for, make sure the user knows that there may be some additional issues. Primary troubleshooting in this area is changing out the power supply with a known working one, and checking external fuses if applicable. If that doesn't fix it, you will need to start opening things up.

[[Visual inspection|Start with a complete visual inspection.]] Look for corrosion, rust, burn marks, or a smell of smoke . You don't have to do this under a microscope but be sure to be thorough{{---}}small part failures can be just as consequential as large part failures. There may not be a singular fault: some defects are compound, involve multiple components, can be on both sides of a board, etc. 

The most primitive block diagram you can create for the device consists of the power supply and whatever functionality the device has. Obviously, if the power supply is bad, then you will not be able to do anything. Therefore, in many cases, this is the best place to start. With a power supply that shows voltage and current, check what the machine draws. If it's drawing close to 0{{nbsp}}mA, it's likely that a fuse or some other completely obvious component failure has occurred (like a trace being blown open) because no power is getting into the device. If you find that the device is drawing excessive current, it's likely you have some shorted component. It's possible for this to be caused in the power supply, but it's also possible this is happening in another place on the board. If possible, disconnect the power supply and see if the power drawn is still excessive. If you find that the power supply is only dragged when other parts of the system are connected, then your problem is elsewhere. if the problem persists, then you know you have to start poking around the board. Approach this methodically{{---}}check each power rail to see if the test points measure appropriately, and if they don't, check to see if the rail is shorted to ground.  At this point, this is all work that you can do without a schematic or drawing of the device{{---}}you should be able to identify basic blocks of the system just by visually looking it over (lots of caps/transformers is the power supply, etc). After this brief look, you should have a good idea of where the problem is likely to be and can be addressed from a more informed position. 

=== Document your findings. ===
A simple sketch/diagram of where the visually-damaged components are is enough, and is useful further on in the process and to communicate with the user. Always make a note of any parts you removed or swapped out with the designation so that you can remember to replace them later when you are done fixing the issue.

If visible defects are found, verify individual components and adjacent/connected components with electronic measurements to determine which ones are faulty and to what extent. A component may look bad, and be working fine, such as a connector that is slightly bent but is not otherwise compromised.
If no visible defects are found, proceed to doing measurements on the electronics.