I’d post the full error message instead of just complaining about its being unhelpful and philosophizing about cargo cults. The point about intellectual laziness is well taken, but the surrounding sermon strikes me as lacking much force.
The first words with which he describes the problem are “doesn’t run”. This, like its even commoner cousin “doesn’t work”, is overly generic. Exactly how a failure manifests is often the first vital clue to figuring out the causes.
Googling an error message is a good idea (default assumption: if it happened to me, it might have happened to someone else), but stopping there is a less effective one. Effective debugging involves squeezing all the information out of the failure that you can get: details of the error message, traces in system logs before, during and after the failure, and so on.
The failure might have to do with manifests, or that could be a red herring. Effective debugging avoids spending lots of time on potential red herrings.
The thing he tried, specifically, might not have been the best idea—as I recall Windows emits quite specific error messages when DLL dependencies are not satisfied, so a vague message that “likely has to do with a bad manifest” would not immediately send me in that direction.
Reproducing the failure can be useful, varying initial conditions—try a clean install of Windows 2003, try one that has had a bunch of stuff installed—characterizing it as a systematic or erratic error. Also trying to understand the relevant differences between Windows 2003 and other versions—it’s axiomatic that the different behaviour has to originate in some difference, but the difference might be in the environment rather than in the executable being produced.
I’d post the full error message instead of just complaining about its being unhelpful and philosophizing about cargo cults. The point about intellectual laziness is well taken, but the surrounding sermon strikes me as lacking much force.
The first words with which he describes the problem are “doesn’t run”. This, like its even commoner cousin “doesn’t work”, is overly generic. Exactly how a failure manifests is often the first vital clue to figuring out the causes.
Googling an error message is a good idea (default assumption: if it happened to me, it might have happened to someone else), but stopping there is a less effective one. Effective debugging involves squeezing all the information out of the failure that you can get: details of the error message, traces in system logs before, during and after the failure, and so on.
The failure might have to do with manifests, or that could be a red herring. Effective debugging avoids spending lots of time on potential red herrings.
The thing he tried, specifically, might not have been the best idea—as I recall Windows emits quite specific error messages when DLL dependencies are not satisfied, so a vague message that “likely has to do with a bad manifest” would not immediately send me in that direction.
Reproducing the failure can be useful, varying initial conditions—try a clean install of Windows 2003, try one that has had a bunch of stuff installed—characterizing it as a systematic or erratic error. Also trying to understand the relevant differences between Windows 2003 and other versions—it’s axiomatic that the different behaviour has to originate in some difference, but the difference might be in the environment rather than in the executable being produced.