January 1999

To: CTI Subscribers
CC: Microsoft Watchers, Linux Enthusiasts
Subject: Windows Tips To Keep Your CTI Apps Running Smoothly

[Go straight to the backup utility code.]

Ah, the start of the New Year. A time for reviewing achievements and, even more important, defining new goals. I have high hopes for the coming year, and I anticipate exciting new developments in the CTI and Internet telephony industries, as well as breakthrough technologies in general computing.

Yes, with the New Year, it is also time for New Year's resolutions. Personally, my resolution is to educate CTI� magazine's readers on productivity-enhancing applications, tips, and utilities. What better way to start off than telling our readers some of my "tricks of the trade" to keep Windows from crashing and to perform optimally?

WHY WAX ELOQUENT ON WELL-TUNED WINDOWS?
Allow me to explain why we should cultivate an intimate familiarity with Windows. For instance, do we really want to demo a CTI application to clients or customers at a CTI show, only to be confronted by the implacable Blue Screen of Death (BSOD), � la Bill Gates during his Comdex keynote?

Another reason to keep Windows in tip-top shape is the need to avoid productivity losses caused by having to reboot Windows several times throughout the workday. Consider what could happen if users were to rely on Microsoft Outlook to access their voice mail and faxes. If Windows were to crash, these users would have to reboot, and then they would have to wait for SCANDISK to run, before they could get back into Windows and read/listen to a critical voice mail or fax.

Do we want our call center agents rebooting their machines during peak call hours, and being unable to use ANI (automatic number identification), perform record lookups, and enter data? Finally, if users are going to trust their Windows PC to perform desktop call control, users want to be confident their PC isn't going to crash in the middle of a call control function, such as a transferring to another extension or answering a call. If we're running mission-critical CTI applications on Windows, we need the operating system to be stable; in addition, we need to be able to troubleshoot it if something goes wrong. And we need more up our sleeves than the same old advice: "Just reboot and see if that helps."

SOME OF US SHOULD ALREADY KNOW BETTER, BUT…
I'm continually surprised by how little some interconnects and VARs know about the inner workings of Windows, and by how unprepared they are to troubleshoot Windows when something goes wrong with an installation. (We have interconnects and VARs come into TMC™ Labs for various telecom matters, and often I find myself showing them how to troubleshoot something in Windows.) Such ignorance can be costly, since interconnects and VARs charge per hour. Obviously, people who work with interconnects and VARs prefer that they get the job right on the first try.

Interconnects and VARs are going to have to learn how to troubleshoot Windows problems, especially since many unified messaging servers, PC-PBXs (communications servers), and CTI applications run on Windows NT with Windows 98 clients. There are many undocumented tricks in Windows that could - if interconnects and VARs only knew about them - prevent time-wasting calls to technical support.

SOME OF MY FAVORITE TIPS AND TRICKS
Over the years, I've discovered many techniques to keep Windows NT and Windows 95/98 running smoothly. Here are a select few:

Look At WIN.INI Limitations
A frequently overlooked limitation in Windows 95/98 involves the WIN.INI file. This file, which is located in your Windows directory, is limited to 64KB. Although most programs no longer use the WIN.INI for storing various settings (it was replaced by the registry), many legacy programs still use it.

For example, if you use Postscript printers and install many Postscript fonts, each Postscript font will be listed under each Postscript printer within the win.ini file. Thus, if you have several Postscript printers installed on your computer and you have several Postscript fonts, you can very easily exceed the 64KB limit.

Using font management programs helps, since these utilities take care of loading and unloading fonts without taking up space in the WIN.INI. I've seen computers which have breached this 64KB limit experience problems ranging from displaying fonts incorrectly on the screen to applications no longer functioning. So check your WIN.INI and make sure you are under 64KB.

Review Your Resources
Windows 95 and Windows 98 are limited by something called "Resources," which consists of System Resources, User Resources, and GDI Resources. There are a finite number of resources in Windows, and you might think you could get around this problem by increasing your RAM. But you'd be wrong. Indeed, even if you had a fully loaded Pentium 450 running 256 MB of RAM, you would still have a problem. We all have the same number of resources.

If you run too many applications, your system resources can dwindle, causing applications to crash. Early symptoms of low resources include icons and fonts displaying incorrectly, and slow performance, especially slow screen redraws. If you suspect your resources are getting low, you can determine how many resources are left by going into Accessories, System Tools, and then Resource Meter.

You can leave this program running constantly, and tuck it away in the lower right system tray. However, you do take a slight performance hit to keep the Resource Meter running in the background. If you notice a drop below 10 percent in any of the three resource categories, you should probably reboot your PC or close some applications.

One thing I've noticed is that even if you close all your applications, the number of resources still does not return to the amount you had when you first booted the PC. On my Windows 98 machine, when I first booted my PC, I started with 82, 82, and 90 percent resources for the three resource types. After opening and then closing Outlook, my resources dropped to 80, 80, and 90 percent.

It would appear that some modules weren't being unloaded. However, when I went back into Outlook and exited, the resources didn't drop again. Apparently, when you run certain applications, specific modules get loaded once, and stay memory-resident even if you exit out of the application. I noticed a similar trait when loading Microsoft Word and Internet Explorer for the first time and then exiting them. The resources would drop a few percentage points from the original resources before the applications were loaded.

In fact, after using my machine for a couple of hours and then closing all my applications, I was down to 30, 30, and 52 percent free resources. It would appear that some applications just don't give the resources back to the resource pool, which seems to me to be a serious "memory leak" in Windows 95/98. I've even run just Microsoft applications, figuring that maybe Microsoft would be more adept at memory management in their operating system than third-party developers. No such luck. As previously stated, Microsoft applications exhibited the same symptoms.

I consider this to be a serious flaw in Windows 95/98, which I hope Microsoft will address. Unfortunately, there is no way of determining who is not "giving up" the shared resources. There are no utilities that I am aware of that can help you pinpoint where your resources have been expended. This information, were it available, would help you determine which applications consume your resources, and how much. Because of this perpetual "resource leak," I make a habit of rebooting my machine every morning even if I'm not experiencing any problems, just to free up these resources.

Think About Your Temp Folder
The C:\Windows\Temp folder (some users use the C:\temp directory) is where "scratch" files are kept by most applications. I've seen applications refuse to run, crash repeatedly, or act finicky until I deleted all of the temporary files in the C:\Windows\Temp directory.

Fortunately, Windows 98 has a feature that lets you schedule when the C:\Windows\Temp directory is cleaned up; however, Windows 95 lacks this feature. For our lab computers still running Windows 95, I put the following into the AUTOEXEC.BAT file: erase c:\windows\temp\*.* <yes. Then, I created a file called "yes" with no extension in the root directory. Within this file I include nothing but the letter "y" and a carriage return. This basically directs a "y" to the erase command so that the prompt is answered automatically without user intervention.

Peruse Your Processes
In the case of Windows 95/98, the troubleshooting armamentarium would benefit greatly from the addition of a utility that would let you see what was going on with the system processes. Such a utility is available with UNIX. Specifically, UNIX includes a "top" command, a daemon that shows you all of the running processes and how much CPU time each process consumes. Even Windows NT has this capability, via the Task Manager. (In case you don't know already, it is easily accessible simply by right clicking on the taskbar and choosing "Task Manager.") So, why can't Windows 95/98, the predominant PC operating system, have this capability? Why hasn't Microsoft included this utility with Windows 95/98?

Fortunately, not all is lost. Although Windows 95/98 doesn't ship with a "process watcher," you can download Kernel Toys from Microsoft's Web site, which includes a nifty utility called "WinTop," which shows you all your running processes. You can even view individual threads and kill errant processes using WinTop. (Download the utility here. [Ed. note: URL updated 01/18/99 per Microsoft's site reorganization.])

I've used WinTop on my Windows 98 machine on several occasions to pinpoint some pesky processes that were slowing down my computer. I highly recommend using WinTop to figure out what's happening on a PC. For example, one time I was working with a Pentium 120 MHz machine that moved at the speed of a Pentium 60 MHz. By using WinTop, I learned that the problem was a faulty CPU fan that caused the Pentium chip to overheat and under perform.

I had another troublesome machine, a souped-up Pentium-333 MHz with 64 MB of RAM, that sometimes slowed to a crawl. This machine would take five minutes just to open Microsoft Word. Using WinTop, I found out that the problem was the Microsoft Office FindFast utility, which was claiming over 95 percent of the CPU clock!

I've been aware of the FindFast utility's problems for a few years now. I've read in computer publications that Microsoft itself has admitted problems with this program. So, it bears some scrutiny. If you have Office 97 installed on your computer, check your Program Files "Startup" folder, which is where programs get executed when you first boot your computer into Windows 95/98 and NT. If you see FindFast in the Startup folder, get rid of it.

WinTop works on Windows 98 as well (I use it all the time), but Microsoft warns on their Web site that you shouldn't install WinTop on Windows 98. Windows 98 does ship with a comprehensive system utility called System Information located under Accessories, System Tools folder. This is a powerful utility that lets you monitor hardware resources (IRQs, DMAs), software drivers, as well as view all running processes. Within this Win98 utility, if you expand Software Environment and then click on Running Tasks, you can see all the running tasks.

I suppose this utility is meant to replace WinTop; however, I prefer WinTop when I monitor my system processes. The reason is that the new System Information utility doesn't show you real-time percentages of how much system CPU time each process is utilizing. For this reason, I'm going to take my chances and ignore Microsoft's warning not to use WinTop on a Windows 98 machine, at least until they come out with a better replacement, one that includes real-time process statistics.

Refine Your Recoveries
Windows 98 has a much improved method of backing up multiple copies of the registry. However, if you're still using Windows 95, you only have one automatic backup, which keeps the last revision stored in hidden files called system.da0 and user.da0. I've had mixed success using these two files to recover from a corrupt registry.

Seasoned IS administrators have no doubt encountered the dreaded "Windows Protection Error," which is actually worse than a BSOD since you cannot even get into Windows. This error usually means a reinstall of the operating system, unless you know about the hidden registry files and how to recover them. However, what usually happens is that a user will try a few times to get back into Windows after the registry has been corrupted. However, if you try to get into Windows a second time after receiving a "Windows Protection Error," the backup registry files are overwritten with the corrupt registry settings.

The only recovery method at this point is to dig up your tape backup and restore the registry files. This is time consuming. I have a batch program which keeps the last five revisions of any files you specify. Simply by adding a call to this batch program in your AUTOEXEC.BAT, you can backup your important system files, including the registry. You can find the code here.

CONCLUSION
If we run CTI applications on a PC, we need to use every trick at our disposal to make sure the PC doesn't fail. We can improve the hardware reliability and uptime of PCs by installing fault-tolerant PCs, UPS backups, surge protectors, ECC memory, redundant power supplies, etc. However, what can we do to improve software reliability?

If we run buggy software applications that crash our system, there is almost nothing we can do about it, right? Since many of us use one of Microsoft's three operating systems (95, 98, and NT - the last of which is soon to be called 2000), we are at the mercy of Microsoft's programmers for an imperfect operating system (nobody's perfect) as well as the third-party application developers who write software for the Microsoft platform.

Well, there are a few things we can do. I've described several in this column. I hope they help you troubleshoot your Windows platforms so that your CTI and regular business applications run smoothly. But let us hope that the Windows platform continues to improve, and that one day we will never again encounter the BSOD or Windows Protection Error. Some of my computer techie colleagues have said that a virtually crash-proof operating system already exists - it's called Linux. But let us save the Windows vs. Linux debate for another day.

Right-click here and save the MS-DOS Batch File. Then put SaveIt.bat into your C:\root directory. Open the file in Word or Notepad for further instructions.