Qualitas
BugSight™ "The Windows Bug Illuminator"
Version 0.83
Qualitas
BugSight™ BugSight is a program to help you find bugs in Windows programs as they run.
Bugs are a fact of programming life. As developers, we try to avoid putting them into our code; as users we try to work around them. While there are many, many errors developers can and do make when programming, certain kinds of errors when made in a Windows program are surprisingly easy to catch (although, fixing them might be another matter).
With some bugs in Windows programs, you might open a window and it doesn't look right. You open it the next time, and the problem seems to be fixed. You click on a button and nothing happens. Click on it again, and it works.
To complicate matters, every piece of software works differently on each different system. No two systems are alike because they change based upon how each person uses them. What works on the developer's machine might not work on yours, which is one reason why software gets released with bugs.
But wait a minute: if a program has bugs (even lots of them), how come it still seems to work? That's because not every bug is serious. You can liken program bugs to bacteria in your body, only some of which are harmful. Most bacteria aren't even noticed, some give you a mild fever, and some send you to the emergency room of your local hospital. There are lots of different bugs.
So what can you do about this? You might be amazed to learn that there is a mechanism built into the DOS-based retail versions of Windows (but removed from the retail versions of NT/2000/XP) which allows the end user to see a certain class of bugs in any and all running programs. These bugs are called Windows API Parameter Errors.
An API (Application Programming Interface) is a published specification on how to write a program that communicates with another program. In this case, Microsoft has published an API for programmers, which tells them how to communicate with Windows. Programmers around the world use this API to make their programs work in that environment. Unless you are a Windows developer, you would have no interest in this API, nor would you even need to know of its existence. However, its misuse by Windows developers can cause you grief.
The Windows API consists of a large number of structures as well as subroutines that can be called, often with various pieces of extra information. For example, one such subroutine is GetParent that takes one piece of extra information (a window handle) and returns the window handle of the parent window. That is, there is a hierarchy of windows in Windows in which each window has a parent (except for those at the root). The GetParent routine returns the parent window handle for a given window handle.
A window handle is just a number, but not all numbers are valid window handles. Windows checks each incoming purported window handle and returns an error code if it's invalid. The many releases of Windows up to and including Windows ME have a mechanism built into them where a program can hook into the system and be called whenever an invalid argument is passed to any of the Windows APIs. Unfortunately, this mechanism was removed from the retail versions of WinNT, Win2000, and WinXP.
BugSight is the first such end-user accessible program to perform this service; that is, it hooks into the system and reports on the many things going on under the hood, such as API Parameter Errors, as well as much more. Finally, there is a way to quantify certain types of bugs in the Windows programs you run every day. You knew they were there all along - now you can put your finger on them.
Why are there any such bugs in commercial (not to mention non-commercial) products? When Windows programmers develop code, they test it in various environments, however the simplest of bugs can be overlooked. One reason is that the tools for checking for these bugs are not easy to use. Windows debuggers are notorious for being cranky. There is another tool available to Windows developers called the "checked" build. This separate build of certain Windows components is available to developers and it is where Microsoft places all of the API Parameter checking. However, when you run a "checked" build, you can easily be overwhelmed by the flood of messages, some about errors, but many others just meant to be informative. Finding your own bugs in the haystack isn't easy; hence such tools tend not to be used, and bugs proliferate.
Download the program from our website.
Unzip the files into their own directory (say C:\BugSight). The files included are one each of .EXE, .DLL, .VxD, and .HLP, all with the name BugSight, and the Internet update program BSUpdate.EXE, along with a helper program UNZIP32.DLL. After running the program, a .INI file is created in the same directory. To start the program, run the .EXE file, usually by placing a reference to it (C:\BugSight\BugSight) in your AUTOEXEC.BAT file, and then reboot.
Note that this line must be placed in the AUTOEXEC.BAT file run outside of Windows before Windows starts up. There is a separate AUTOEXEC.BAT file used for each DOS window run under Windows - that's not the one we mean. Typically (that is, almost always), the file to be modified is C:\AUTOEXEC.BAT.
Also, while BugSight can be made to work in WinME, successful installation requires the user to append a line to their AUTOEXEC.BAT file. As various writers have ably described before, MS has (in their infinite wisdom) made this previously trivial task quite difficult, requiring the user to patch the OS in order to restore that capability. I have successfully applied the above patch to a copy of WinME and seen BugSight work as expected in that environment. If you choose to go that route, do so cautiously and at your own risk. Unbelievable.
If you need to disable the program temporarily after it is installed (but before you have started Windows), run the .EXE file (outside Windows) with an argument of /DISABLE. To re-enable the program, use /ENABLE.
After Windows is running, run the .EXE program again (this time it'll run as a Windows executable) to see what's happening in your system. You might want to run BugSight from your Windows StartUp group (click on Start | Settings | Taskbar & Start Menu, then on Start Menu Programs, and Add).
As all files are in the same directory, just delete the entire directory, and remove the one line entry you made in your AUTOEXEC.BAT file. If you put a reference to the .EXE file in your Startup group, remove that, too.
The program screen displays several types of messages:
Faults
Parameter Errors
Log Errors
Messages from the underground
These messages tell you about problems and other events occurring in your system. Some of these events represent bugs in the programs you run every day.
The Fault, Parameter Error, and Log Error messages also include
The Fault message includes the type of fault along with the context in which it occurred.
A typical Fault message is
Fault: BuggyApp (C:\BuggyApp\BuggyApp.EXE)
General Protection
Fault
Type: PM, LAST
This type of message is comparatively rare.
The Parameter Error message includes more detailed information about the error on two more lines such as
A typical Parameter Error message is
ParamError:
Wucrtupd (W:\SYSTEM\WUCRTUPD.EXE)
user.exe @ 16D7:02AB
(DESTROYICON32+12)
Invalid HWND = 0000
This means that this Parameter Error occurred while task Wucrtupd was running during a call to the Windows API DestroyIcon32 to which was passed an Invalid HWND (Window handle) the value of which was 0000 (which, as it turns out, is never a valid window handle).
If the given offset (in the above example it's 12) is large (say, 30 or more), the API name might not be accurate. That is, BugSight knows the entry points of all of the external named APIs in the files that report API errors. When an API Parameter Error occurs, BugSight is given the address of a point somewhere after the API entry point. BugSight compares this address with all of the known addresses and finds the entry point nearest to and preceding the given address. If the actual entry point isn't known to BugSight, but closely follows one which is known, we will identify it by the known name. For example, the API GETDRIVERINFO is only 46 bytes long (at least in Win98SE) and precedes another one whose name is not known. An error message that indicates that the API is GETDRIVERINFO+58 is actually in the next API entry point, but the file (user.exe) which owns the unknown entry point doesn't export its name.
Sometimes BugSight doesn't display an API name at all because the address we're given is just too far from any known entry point.
A typical Log Error message is
LogError:
WINOLDAP (W:\SYSTEM\WINOA386.MOD)
RegisterClass()
failed -- already registered.
This particular error (RegisterClass failed) is harmless, the kind you can ignore.
More serious Log Errors are of the form
LogError:
BuggyApp (C:\BuggyApp\BuggyApp.EXE)
LocalAlloc()
failed.
Other messages have no particular format, as they are whatever the developers decides is important to spit out onto their debugging screen. Often these messages are forgotten about and left in the shipping product. For example, it could be something cryptic such as this one from Matrox:
Max
GART size(entries) = 16384, GART region base = f8000000
or something that just marks how far the program has gotten
In
16bit DllEntryPoint: thkThunkConnect16 ret TRUE
To temporarily disable BugSight, press F2. This is useful in case you encounter a flood of error messages that threaten to overwhelm your system.
To re-enable BugSight, press F3.
The File | Save menu choice allows you to save the entire set of messages in a text file. Use this to capture all of the messages instead of just one at a time via right-click and Copy.
The Options menu has choices
The Help menu has choices
You will notice some slowdown in your system when bugs are prevalent due to the extra messages being sent from the operating system to BugSight. If this is a problem, disable BugSight (or close it). When you re-enable BugSight (or re-open it) during the same session, the bugs you missed seeing will be displayed as usual without any loss of information.
If you find a bug in BugSight, please report it to us.
However, if BugSight indicates that there is an error in some other program, please report it to that program's author/vendor. We have no better entry into other companies than you do, so please don't ask us to report the bug to them for you. Besides which, quite likely it'll be more effective to have lots of individual users report bugs than one company (us) beating the same drum over and over.
Normally, you'll know who the vendor is just by the name of the program and/or the name of its directory. If you have any question, this information is usually in the file referenced in the BugSight message. To view this information, bring up Windows Explorer (or an equivalent program), and browse to the directory with the referenced file. Right click on the file and choose Properties. Normally, there is a tab named Version with information such as Company Name, etc.
In this Internet age, almost every vendor has a web site through which you might find contact information. Often the program's help file or printed documentation contains contact points. If all else fails, send a message to postmaster@(the vendor's web site) asking for a contact point. If you paid for the product (and it's a current version), they should fix it for you.
Your favorite program might have bugs in it, but if it isn't a current version you can't expect the vendor to continue to support it. They might offer an upgrade, maybe at a reduced price, but it's unlikely they'll fix a bug in an out-of-date version, and I don't think you should expect them to. Time marches on, and so does software. You might ask them if the same bug is present in their current version, though.
Also, sometimes products die. That's life in the software lane. If the product is dead, so is support for it.
Armed with a contact point and information from BugSight, you are ready to report a bug.
As a general rule, the more information you provide, the easier it is for them to find and fix the problem.
When reporting a bug found by BugSight, please keep in mind that everybody makes mistakes. Developers have many demands on their time and fixing the bug you just found might not be their highest priority. However, they should acknowledge the bug and promise to fix it.
One caution: you might become quite frustrated trying to report a problem to certain vendors. Sometimes, they just don't want to hear from you as evidenced by my exchange with the folks at Real Networks.
And don't forget to tell them about BugSight so they can use it themselves.
Lastly, the source of a bug can be deceiving. For example, while I was developing this product, I was surprised to see BugSight display the following error message about itself!
ParamError:
Bugsight (R:\BUGSIGHT\BUGSIGHT.EXE)
KRNL386.EXE @
0177:0103 (GETATOMNAME+12)
Invalid handle = 0000
This message occurred when I first tried out the code to change the font (Options | Fonts). I knew that my code didn't call that particular API, so I started debugging. Eventually, I figured out that the error message was caused by a problem with a font (Tahoma, installed by MS Word) in my Windows Fonts folder, not a bug in my code. Were you to delete that font (wait, I don't recommend that), the error message goes away. If you have Tahoma installed on your system, likely you'll also run into this error message, too, when you use any program which enumerates fonts. This is also a not so subtle hint not to report this bug to me, as it isn't a bug in my code.
Thus, it is entirely possible that BugSight might indicate that the error occurred while a certain task is running (in the above case the task was BugSight itself), however the problem was caused by something entirely different - the problem just happened to rear its ugly head then. Please remember this when reporting bugs - the only thing you can say for sure is that the error occurred while a certain task was running, not that it's their fault.
This program works on the Win32 DOS-based versions of Windows (95/98/98SE/ME) only; not on the NT-based versions (NT/2000/XP). The method used to obtain the information reported on by BugSight was removed in the NT-based Windows and we have no plans to attempt to make BugSight work with those versions.
This program was written by and is © Copyright 1997-2005 Qualitas, Inc. The most recent version may be downloaded from http://www.bugsight.com/bugsight.zip.
It is free for non-commercial use; commercial use requires a volume purchase agreement from the author. It may be freely distributed for non-commercial use as long as no part of the program or its documentation is altered and the program and its documentation are kept together.
BugSight also uses a helper program Unzip32.dll which is an altered version of Info-ZIP, version 5.50 of 20 February 2002. That software is © Copyright 1990-2002 Info-ZIP, All rights reserved.
The original UnZip sources are available from Info-ZIP's home site at http://www.info-zip.org/pub/infozip/UnZip.html; my changes are available from http://www.bugsight.com/infozip-changes.htm.
For more answers to technical Windows questions,
see 
[Products] [Orders] [Technical Support] [Registration] [Downloads]
About Qualitas
© Qualitas, Inc. 1987-2006,
433 S. Duke St., P.O. Box 3299, Shepherdstown, WV 25443-3299