If you are trying to understand an error, you may want to look up the error code to see what it means instead of just shrugging
A customer had a debug trace log and needed some help interpreting it. The trace log was generated by an operating system component, but the details aren’t important to the story.
I’ve attached the log file. I think the following may be part of the problem.[07/17/2005:18:31:19] Creating process D:\Foo\bar\blaz.exe [07/17/2005:18:31:19] CreateProcess failed with error 2
Senior Test Engineer
What struck me is that Bob is proud of the fact that he’s a Senior Test Engineer, perhaps because it makes him think that we will take him more seriously because he has some awesome title.
But apparently a Senior Test Engineer doesn’t know what error 2 is.
There are some error codes that you end up committing to memory because
you run into them over and over.
Error 32 is
error 3 is
and in this case,
error 2 is
And even if Bob didn’t have error 2 memorized, he should have known to look it up.
Error 2 is
ERROR_FILE_NOT_FOUND. Does the file
No, it doesn’t.
Bob seems to have shut off his brain and decided to treat troubleshooting not as a collaborative effort but rather as a game of Twenty Questions in which the person with the problem volunteers as little information as possible in order to make things more challenging. I had to give Bob a nudge.
Can you think of a reason why the system would be looking at
D:\Foo\bar\blaz.exe? Where did you expect it to be looking for
This managed to wake Bob out of his stupor, and the investigation continued. (And no, I don’t remember what the final resolution was. I didn’t realize I would have to remember the fine details of this support incident three years later.)