MS error messages

[Ed Cryer]

People ask me why the error messages can't be more specific; why do they
get a long string of letters & nos, and when they look them up they are
told it could be either a or b or or ....

Well, I've tried to answer it. But I'd appreciate comments from people here.

I'll give my own experience with running SP1.
It failed with an error code. I look that up and it could be a .....etc.
I solved it by enabling automount for the hard drives and starting SP1
again.
So then, why couldn't the thing have simply halted and asked me a
question; something like, "We need to mount a volume, but can't - should
we enable automount?".

My answer:- The updates use standard MS house-keeping routines held in
dll's (dynamic link libraries), and sometimes a routine will call
others. And by the time control reverts to the top level updating
program the exact error code has been obscured or partly obscured. Why?
Because the routines were written not specifically for this particular
update, but as general-purpose routines. Also, sometimes the specific
error code might be available but it could be one of thousands and the
programmers would have to include reams of coding to cater for each one
and thus provide very bloated updates.

Am I there? Or close?

Ed

 

[charlie]

People ask me why the error messages can't be more specific; why do they
get a long string of letters & nos, and when they look them up they are
told it could be either a or b or or ....

Well, I've tried to answer it. But I'd appreciate comments from people
here.

I'll give my own experience with running SP1.
It failed with an error code. I look that up and it could be a .....etc.
I solved it by enabling automount for the hard drives and starting SP1
again.
So then, why couldn't the thing have simply halted and asked me a
question; something like, "We need to mount a volume, but can't - should
we enable automount?".

My answer:- The updates use standard MS house-keeping routines held in
dll's (dynamic link libraries), and sometimes a routine will call
others. And by the time control reverts to the top level updating
program the exact error code has been obscured or partly obscured. Why?
Because the routines were written not specifically for this particular
update, but as general-purpose routines. Also, sometimes the specific
error code might be available but it could be one of thousands and the
programmers would have to include reams of coding to cater for each one
and thus provide very bloated updates.

Am I there? Or close?

Ed

One of the many reasons is that the "normal" copies of windows do not
have the more extensive debugging features of versions used in
development. Win 7 has some improvements in error and fault isolation,
but - - A gamer trying to get the last bit of speed and so forth may
disable a good part of the logging and error reporting.

The difference between versions can be a two edged sword, in that a
program or routine may run perfectly using the development version, and
then mysteriously crash or misbehave when it runs in the "normal"
versions. An error code may eventually be generated do to an event that
actually occurred several modules (Dlls, etc) back up the chain.
"Parallel Processing" using multicore CPUs can add more complexity and
confusion to the situation.