First of all, human observations (eye-witness accounts) are notoriously unreliable, even in situations when we are trying to look for something. In most situations where something goes wrong we aren't waiting for it to go wrong, which means we aren't looking. This only makes eye-witness reports less reliable. In addition, because we would (presumably) be in a pressure situation, we probably forgot half of what we did in the minute leading up to the issue, which is the most important period of time for evidence gathering. A different twist on this is that we will sometimes perform an action that we believe is unrelated to the outcome but is, in fact, integral to the outcome, unbeknownst to us. The action isn't reported because it isn't seen as relevant. All-in-all, people are horrible sources of information.
Add to that the fact that controls systems are generally closed environments that we have no direct knowledge of and (specifically in the OP's case) we have a machine that is likely new to the operators or, at least operating in a different way. The control system will be the odds-on favorite target for blame.
PLC-resident state and logic loggers and traps are a good idea if you are hunting a specific fault. It can be a little difficult to decide what to log some times but it can be extremely helpful.
As was stated before, if you want any real information out of the operators, both you and the operators need to be on the same page concerning what the machine or process should do in the first place. What the operators see as wrong may not be wrong, just different. Just as importantly, what the machine or process is doing may be what is intended but it is not what needs to happen based on operator experience. The only way to handle either of these is for the developer and the operator to agree on proper operation. That doesn't mean you need to necessarily bend to the operators picture of what the machine to do. But at least the operator knows what should happen.
I had a case years back in a previous life that highlights both of the previous points. We had a machine HMI that was written in C and run on a DOS machine. The HMI maintained the recipe information and was an integral part of the machine order change sequence. We would get random reports, usually on second shift, that order changes were not completing. We had no immediate idea why. This HMI would log fault and action data in a text file if desired. We had the plant start a log and then send us the text file after the next issue they had. Looking at the log file, all alarm and event logging just stopped about 30 minutes before the issue. Up until then everything was working just fine. It was like the program froze. If the program didn't acknowledge that the order queue shifted as part of the order change the order change wouldn't complete. We told the plant to check the HMI operational status the next time this happened. Turns out the operators were shutting down the HMI program and playing Gorillas while the machine was running. So this is a double whammy thing. The operators didn't understand that the HMI program was an integral part of the order change sequence (that isn't particularly intuitive). Also, we would not have suspected something like this if we hadn't seen the log file.
Keith