Verify that those inputs are as expected.
This post is part of a series describing the generic, high-level troubleshooting process. Do not use if you are allergic to troubleshooting, blogs, or learning.
Previous Posts:
What is Troubleshooting?
Simplified Troubleshooting Overview
Step 1. Understand the correct inputs and outputs of the “black box.”
Step 2. Determine which output(s) are incorrect.
Step 3. Figure out which input(s) affect that output(s).
Next Posts:
Step 5. Analyze the path(s) from input(s) to output(s).
Step 6. Check all connections.
Step 7. What are the devices in those path(s) that change the data?
Step 8. Eliminate the devices that could not cause this output.
Step 9. Test the remaining devices.
Step 10. Repair/Replace faulty device(s).
Step 11. Fully test the system.
Step 4. Verify that those inputs are as expected.
In this step, we verify that the inputs to the system are correct. If you find an input that is not as expected, then maybe the issue is upstream of this equipment, or there is no issue at all. It is not unusual to find the the problem is:
- Not a problem
- Someone had an input set wrong
- There was a misunderstanding of how it is supposed to work
- In a completely different box
- An upstream output is wrong, giving this box a wrong input
- A downstream input has an issue affecting the output of this box (as discussed in Step 2)
You need to do everything that you can to verify that the issue is actually with the equipment that you are analyzing. If you don’t you could waste time troubleshooting in the wrong place. If you realize that the issue is in another box, move your analysis to the other box, and start over at Step 1. Only once you have personally verified that the inputs are correct, the output is incorrect, and the issue it not downstream, can you actually say that there is an actual issue with the equipment that you are troubleshooting.