This is only a preview of the January 2002 issue of Silicon Chip. You can view 30 of the 96 pages in the full issue, including the advertisments. For full access, purchase the issue for $10.00 or subscribe for access to the latest issues. Items relevant to "Computer Tips":
Items relevant to "Touch And/Or Remote-Controlled Light Dimmer; Pt.1":
Items relevant to "A Cheap 'n' Easy Motorbike Alarm":
Items relevant to "100W RMS/Channel Stereo Amplifier; Pt.3":
Items relevant to "Build A Raucous Alarm":
Purchase a printed copy of this issue for $10.00. |
COMPUTER TROUBLESHOOTING
Tracking down software problems:
a step-by-step approach
What’s the first thing many people do when the
strike computer problems? Answer: they reformat the hard disk and reinstall everything. But
that’s the hard way of fixing problems and it
doesn’t necessarily guarantee a good result.
By STEPHEN DAVIS
I vaguely remember having read
somewhere that when someone asked
Tesla how he was able to understand
and invent complex electrical devices
he replied: “By breaking the concepts
underly
ing them down into simple
parts, understanding those simple
parts, and realising that complexity
has an underlying simplicity”.
An attitude like this prevents the
mindset of being overwhelmed when
confronted with problems that inevitably occur when using the complex
technology of today. And of all the
electronic devices that cause frustration, home computers would
have to be right up there, along
with setting up (and subsequently using) video recorders.
The added frustration that a
home computer user has is that
even the so-called professional’s
solution to a computer user’s software problems is often destructive – ie, reformat the hard disk
drive and start again or, at best,
reinstall Windows from scratch.
However, a little bit of knowledge
and some careful analysis may
be all that are required to save
your PC’s current setup from
obliteration.
It often amuses me that some
people who profess to be “au
fait” with computers often describe
themselves as software or hardware
orientated and then shy away from
gaining knowledge about that side of
computers they feel doesn’t interest
them. This is a mistake, because if
you are interested in solving com74 Silicon Chip
puter related problems, a reasonable
knowledge of both areas is necessary. After all, hardware faults can
masquerade as soft
ware faults and
vice-versa, so you have to be prepared
to deal with both possibilities when
troubleshooting.
The hardware and software in your
PC is inexorably linked and this must
be fully appreciated in order to solve
problems as they arise.
A typical software problem
A good example of a software problem is one that recently happened to
me. What follows is the step-by-step
method that I used to solve the problem. You can use the same procedure
to track down similar faults.
The problem occurred after I had
foolishly installed several programs
on my computer in quick succession.
It is inadvisable to install programs in
this fashion, because when software
problems or conflicts occur, they are
harder to track down – simply because
you don’t know which application
introduced the fault.
This was a classic case of me not
following my own advice and the
problem occurred as a result of it.
Everything seemed to be working
well initially until, about a week later, I tried to fire up Microsoft Visual
C++ (a component of Visual Studio)
and found myself staring at an error
message that said, “Msdev caused an
invalid page fault in MFC42.dll”. The
program would then exit gracefully
after my acknowledgement of the fault.
The first thing to do in a case like
this is to go on to the Internet and,
using a good search engine (I use
Google at present), do a search for the
above phrase. This has the potential
of giving you an exact reason for your
problem but in this case, nothing of
relevance came up. I then searched
the Microsoft Knowledge Base
using the above phrase but again
drew a blank.
Under these circumstances,
the best thing to do is to unin
stall and reinstall the program
to see if this fixes the problem.
The obvious disadvantage of this
technique is that it does not aid in
understanding why the fault was
there to begin with. However, at
the time, I was just eager to get
the program going.
Unfortunately (or perhaps
fortunately, otherwise this article
would not have been written),
the same error reared its ugly
head and continued to do so no
matter how often I uninstalled
and reinstalled the program.
My next step was to uninstall all the
programs I had installed subsequent
to Microsoft Visual C++ working correctly. After doing this, I cleaned the
Registry to delete any references to
these programs that may have been
www.siliconchip.com.au
What’s A DLL And How Do They Cause Problems?
So just what is a “dll” file and why
do they sometimes cause problems?
Since this explanation is for the layman and not for programmers, the
following is a simplification of what
actually occurs.
A “dll” is simply an enclosed set of
different procedures that a program
could call. For example, if I wish to
save a file to disk from my program,
I just simply call a set of instructions
(a procedure) within a dll (in this case
kernel32.dll) to do it. There are many
dlls for many varied functions within
Windows and programmers can also
write their own dlls.
When computers first started becoming popular, all programs were
self-sufficient, with the details of saving to disk, retrieving information, etc
included within each program itself.
However, it didn’t take programmers
long to realise that this was an inefficient way of doing things, because the
same code for saving to disk would
have to be included in every single
program. Why not have the code
required for saving to disk written
sepa
rately, outside each program,
so that all programs that save to disk
could easily access it? This would
save memory space and also the
programmer’s time.
All that the programmer would
need to know would be that if he
wants to save information to disk
he simply writes ‘savetodisk’ or its
equivalent, depending on what the
original program
mer called it. The
operating system would then track
down the dll containing this procedure
and the procedure itself would start
left behind (I used the shareware
program “Reg Vac” which has had
good reviews on the Internet). I then
reinstalled Visual C++ but the error
was still present.
It was time to look at the error more
closely by examining what it was
saying.
What’s a page fault?
A page fault is something that
occurs normally with programs running under Windows. When a piece
of information is paged out to virtual
memory (the swapfile) on the hard
drive (eg, due to lack of space in
www.siliconchip.com.au
operating. Thus the code for saving
to disk could be written to a separate
module and linked to any program
that required it – hence the concept
of a linked library.
However, what if we were doing
things on the computer that didn’t
require the “save to disk” procedure?
Memory would be wasted holding
code that was not going to be used.
Hence the concept of a dynamic
linked library (dll), where the actual
calling of a procedure from a program
is what first puts it into memory. Before it is called, it just sits as a file on
the hard disk drive.
To explain how dlls can cause problems, imagine a programmer writing a
simple piece of code for an arithmetic
program aimed at elementary school
children. The program introduces the
concept of the squaring of numbers
and because of the age group of the
children, only integers can be used
within the program.
Our programmer then turns this
piece of code into a dll because he
imagines other programmers may
find this code useful for their own
arithmetic programs. All they would
have to do is link this piece of coding
into their program and write “square
number” (depending on what the
programmer called it) and they would
get the required results – all based
on the efforts of the programmer who
originally wrote it.
Everything would be fine until
someone decided to include this dll
in a program for use by secondary
schools where real and complex
numbers are being explored. The
RAM), a page fault occurs whenever
the RAM is accessed and the required
information isn’t there. The page fault
then points the program to the area in
the swapfile where the information is
stored.
This information is then put back
into RAM to allow it to be accessed
by the data bus. At the same time, the
least-used information currently in
RAM is swapped out to virtual memory. An invalid page fault occurs when
the area of swapfile that is required
to be transferred back into memory is
not valid for the application. Further
information on this concept for people
programmer responsible for the dll
would still like programmers to be
able to write “squarenumber” and
get a result and so he would put out
version 2 of the dll, with the coding
altered to give a result other than an
integer when required.
So how would the dll know whether
to deliver an integer result or not? The
dll could look for certain bytes within
memory that signify one version or
the other of the program that uses it.
The program would have assigned
an area of memory for its own use
in order to place the flag bytes and
it would be the responsibility of the
operating system to prevent this area
of memory from being overwritten by
another program.
Now imagine the case of a version
2 dll overwriting the original dll on a
PC that uses the elementary program. The original program would not
have reserved an area of memory for
flag bits and so when the dll checks
for these flag bits, a protection fault
would result if this area of memory
has been grabbed by another program.
Basically, the Windows operating
system always preserves memory
integrity by terminating programs that
invade another program’s reserved
RAM.
This simplistic example explains
how software conflicts can occur due
to memory and dlls. It only takes a
small piece of programming that is
less than optimal to cause a cascade
of problems that leads, at best, to
the termination of one program or, at
worst, to a complete crash.
new to it can be found at: http://www.
howstuffworks.com/question175.htm
MSDev.exe is the Microsoft development environment execut
able
which, among other things, has to load
MFC42.dll – a Microsoft foundation
class dynamic linked library (see panel: “What’s A DLL And How Do They
Cause Problems?”). So it appeared
that the error was occurring whenever MSDev.exe attempted to load
MFC42.dll.
A Microsoft knowledge base article
at http://support.microsoft.com/support/kb/articles/q286/1/80.asp talks
about the various causes of invalid
January 2002 75
Computer Troubleshooting – ctd
page faults. The two that concern us
here are the possibilities that either
one of the two files is corrupted (and
therefore allocating memory in an
incorrect fashion) or that they are interfering with each other because of a
lack of synchronisation with respect
to memory.
This latter possibility could occur
if the dll being used was the wrong
version. Neither scenario seemed
particularly likely considering that
the Visual C++ had been installed and
uninstalled many times already but I
was running out of ideas.
As a result, I decided to install
Visual Studio on a friend’s computer,
first to see if the CD itself had somehow
become corrupted and second, to have
a closer look at these two files.
Visual Studio worked perfectly on
my friend’s computer and so I copied
both MSDev.exe and MFC42.dll onto
floppies and took them home. I
then compared these files with
those on my hard disk drive and
to my surprise, I found that the
version of MFC42.dll in my hard
drive’s c:\windows \system dir
ectory was 6.00.8447.0 whereas
the version on the floppy was
6.00.8141.0. So, it appears that
a newer version of the dll had
overwritten the older version (this
is normal behaviour) but poor programming had resulted in a dll that
was obviously not fully backwards
compatible with the older one (as it
should have been).
The next step was to replace the
version of the dll in the system directory with the version of the dll that
the program apparently needed. Using
correct computer procedure (ie, the
three “Bs” – backup, backup and backup), I tried to back up the version of
MFC42 that was in the c:\windows\
system directory but I got an error
saying, “Cannot delete MFC42.dll.
Access denied. Make sure the disk is
not full or write protected or that the
file is not currently in use”.
Suddenly a bell started ringing
(actually more a mental buzz – the
neurons were now firing). Obviously,
my previous attempts at uninstalling
and reinstalling Visual C++ would
have had no effect on this file if it was
being used by a TSR (a program that
76 Silicon Chip
runs quietly in the background) – ie,
the file could not be replaced or deleted while ever the TSR was running.
However, it did annoy me somewhat to
think that the programmer responsible
for the uninstall routine of the Visual
C++ module could have been a little
more explicit in messages about which
files were not being uninstalled.
Now that I knew what had happened, it was a simple matter of using
the three-finger salute (ctrl-alt-del) to
remove all of the background programs
except for Explorer and Systray and
then replacing one version of MFC
42.dll with the other. After rebooting
(to re-enable the TSRs), Visual C++
worked perfectly.
Norton’s clobbered
It was now interesting to observe
that the Norton Utilities portion of
Norton System Works 2001 no longer
worked. Instead, it simply displayed
a very unhelpful message which said
“Internal error”.
Of course, replacing the Visual C++
version of MFC42.dll in the c:\windows\system directory with the other
version (which I’d copied to another
floppy) allowed Norton System Works
to operate again – but at the expense
of Visual C++.
I wanted both programs to work,
so I thought about this problem and
eventually decided to leave the dll
required by Visual C++ in the c:\windows\ system directory and to place
a copy of the other dll in the “Norton
Utilities” folder where the executable
for this “sub-unit” of Norton System
Works was stored. In programming,
there is often a sequence required
for the program to find required files
and usually the folder utilised by the
executable itself is the first folder to
be searched.
This type of programming methodology is exemplified by the “path” environmental variable utilised by DOS
(ever heard of it?) during the dinosaur
era. In this case, the idea paid off and
I now have Norton System Works and
Visual Studio happily coexisting with
each other.
Be methodical
As the above story demonstrates,
it’s important to be methodical when
tracking down software faults. A technique I have used in the past is to put
pen to paper, list all the possibilities,
and then methodically follow chains
of logic.
I also frequently use the Internet
to gain knowledge about the problem
at hand. In the above case, I perhaps
could have found the source of the
problem sooner if I had done a search
on keywords such as “MFC42.dll”,
problems, incompatibility, etc. I would
have soon discovered that this dll is
one of a number known to cause what
is known as “dll hell” (do an Internet
search using this little phrase and see
what pops up).
Also, Norton Utilities is notorious,
particularly in some of its earlier
incarnations, for causing problems
with other software. However, in this
case, the problem is purely Microsoft’s
because MFC42.dll is a Microsoft file.
By now, some of you may be thinking that there is always a message at
the start of most installation routines
that says “Make sure other programs
are not running during this installation
routine” or words to that effect. Had
I diligently followed this instruction
and turned off all of the TSRs, the
problem would not have happened.
My excuse for not following this
instruction is that I had not thought
deeply enough about it to consider
applying this directive to background
running programs – and I doubt that
the majority of people installing
programs would consider it either.
However, doing things the long way,
or sometimes the wrong way, is not
something I necessarily regret if it
gives me a greater understanding of
my hobby.
And really, isn’t that what its all
SC
about?
www.siliconchip.com.au
|