Fullscreen HTML5Med Res (??MB)HTML4

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 rein­stall 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 simplici­ty”. An attitude like this prevents the mindset of being over­whelmed 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 inad­visable to install programs in this fashion, because when soft­ware 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 poten­tial 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 in­stalled 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 pro­grammers, 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 ‘saveto­disk’ 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 pro­grams 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 program­mer 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 Micro­soft 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.micro­soft.com/support/kb/articles/q286/1/80.asp talks about the vari­ous 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 cor­rupted (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­ ec­tory 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 over­written 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 some­what 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 unin­stalled. 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 reboot­ing (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 uti­lised 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 me­thodical when tracking down software faults. A technique I have used in the past is to put pen to paper, list all the possibili­ties, 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 Micro­soft’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 under­standing of my hobby. And really, isn’t that what its all SC about? www.siliconchip.com.au