I get a lot of mail like this:
"Fred, I'm running Win98 SE with 128MB of RAM and I notice that my 'system resources' level is constantly draining to a low level. It starts at 70 percent and goes as low as 14 percent with only 1 or 2 apps running. Is this something to be concerned about? I've found some freeware apps that promise to help: Freeware Plus -- memory management tools.
I would appreciate an article on this subject, along with recommended remedies, if appropriate."
-- John Byers
I certainly can sympathize with John, and you probably can too. No matter how much physical RAM you have in your system, it's still possible to run out of System Resources. When that happens, one of three things occurs:
1. You may get an error message such as "Out of memory" or "Not enough memory to display completely" or "System Resources are running low."
2. Or, your system may begin to behave weirdly by doing things such as opening blank or garbled windows, refusing to respond to keystrokes or mouse clicks, and the like.
3. Or, your system may simply crash and burn.
In each case, your only remedy is a reboot. Hope you saved your data recently!
So what's really going on? What can you do to prevent it from happening? And do those freeware apps that John mentioned (and others like them) really help? Let's take it a step at a time:
The Mythical "System Resources"
To begin with, there's no single thing called "System Resources." It actually means different things depending on how it's used. Most generally, it refers to all the components of your PC that let it do what it does.
But the "System Resources" that John's letter mentioned are two very specific memory areas inside Windows: User Resources and GDI (Graphics Device Interface ) Resources. You can think of these areas as scratchpads -- actually, internal tables and pointers -- that Windows uses to keep track of running applications.
The User area contains information about all the apps and windows currently running, including dialog boxes, the controls in dialog boxes, and so on. Every DLL, in fact, your apps use gets its own data area in the User section.
Loosely speaking, the more things you ask your computer to do at once, the more heavily used your User area becomes.
The GDI area keeps track of the things Windows uses to draw what you see on screen: there are things called pens, brushes, fonts, bitmaps, regions, and palettes, for example. Roughly speaking, the more graphical objects you have on-screen -- windows, icons, wallpapers, etc. -- the more heavily used your GDI area becomes.
Both resource areas are of a fixed size regardless of how much RAM you have -- and that's the problem. If you run too many things at once or have too many graphical objects displayed at once, you can deplete the User or GDI area. When that happens, you get the error messages mentioned earlier, or weird behavior or a crash.
The Good News
With properly-coded applications (that's a major caveat), it's actually fairly hard to run out of System Resources. I just tried an experiment, for example, on my main Win98SE system here: I opened (as normal windows) Internet Explorer, my Office 2000 suite (Access, Outlook, Word, Excel, PowerPoint and FrontPage), Lotus Organizer, an MS-DOS window, and Eudora (a notorious resource hog), plus a couple of small "tray" apps I always have running. It's hard to imagine a single person needing to run much more than that at the same time, but Windows could have done lots more -- I still had 28 percent system resources free!
(And by the way: You can thank Windows Magazine -- the predecessor of WinMag.com -- for this ability of Windows to handle so many apps with ease. You see, during the early beta testing of what was to become the original Windows 95, the folks at WinMag discovered that the new OS retained the tiny, inadequate System Resource areas of the old Windows 3.1. WinMag complained to Microsoft, in print, and Microsoft responded by making Windows 95's System Resource areas far larger than they'd planned to. It's a little-known fact, but literally every person who has ever used any version of Windows 9x has benefited from the aggressive testing and reporting of Windows Magazine!)
The Bad News
As you run apps, open and close windows, and so on, various User and GDI resources get allocated. When you shut down an application or when part of an app is no longer needed, its resources are supposed to be released, freeing up space in the User and GDI areas for use by other apps.
However, in poorly-coded apps, some of the resources used by an app may not be released. Over time, more and more resources may be marked as "in use" even when they're really not. In a sense, bad programming treats the User and GDI areas as roach motels -- resources check in, but they don't check out: Eventually, there's not enough available resource memory space to continue working, and you get an "out of memory" error message or crash.
In fairness to programmers, in a complex app there can be thousands of items to track. When programming for Win9x was a new thing, many apps were truly awful about releasing resources. In fact, this was one of the reasons why Win95 got its bad reputation for instability: It was actually "resource leaks" in various badly-coded applications that often were the cause of Win95 crashes. Win98 is better at cleaning up after sloppy programs; it can recover "leaked" or "orphaned" resources, up to a point. Windows NT and 2000 largely do away with the limited resource areas, and thus are intrinsically more resistant to problems of this sort. Plus, programmers and programming tools have gotten better at preventing leaks. But resource leaks still happen, and a very leaky app or a large number of apps with small leaks can still wreak havoc.
Finding Resource Leaks
Here are the official Microsoft instructions for finding what they generically call "memory leaks" in Win98. (Other versions of Windows have similar procedures.)
Note that step 4 refers to resources that rebound to a level "substantially less" than before: In some apps that use shared components (DLLs and such that perform common functions) some of the shared components deliberately may be left in memory in anticipation of reuse: The program designers may use a little space in the User or GDI area as a kind of cache to speed the next use of the shared component. So, seeing a loss of a few percent of resources after running an app does not by itself mean you have a leak.
But a large drop almost always means there's a leak. Likewise, if you repeatedly open and close an app and find that your resources steadily decline and do not recover, this too means you have a leak: The components are not being reused.
Also note in step 4 that Microsoft correctly attributes this behavior to the applications, not the OS; the problem arises within the leaky application, and really can only be fixed there. (Ironically, some Microsoft applications leak, too; but the OS can't fix what's broken in an application even if it's from the same company.)
This means the only true cure for memory leaks is a rewritten or patched version of the offending application: The programmers have to find out what memory isn't being properly released, and correct the problem -- plug the leak.
Other Tools and Fixes
There are many, many utilities, both free and low-cost, that purport to fix memory leaks caused by other applications. I've been trying a pile of them for the last couple weeks, and in Part Two of this column I'll tell you how these optimizers work, what they actually do, and whether they're worthwhile or not.
Meanwhile, you can begin tracking your own System Memory use to see if you're experiencing resource leaks. You can use the Microsoft procedure, above; or, if you want to get really serious about tracking System Resources, there's an even better way:
It's a very simple utility called Resource Meter. It may already be installed on your system in Start/Programs/Accessories/System Tools. (If it's not there, you easily can install it by clicking to Start/Settings/Control Panel and then clicking on the Add/Remove Programs applet. Within the applet, choose Windows Setup; scroll to System Tools and then click on Details. Select System Resource Meter and click on OK. Depending on how your system is set up, you may need to insert your Windows CD; if so, you'll be prompted at the right time.)
When you run the Resource Meter, you'll see three bar charts: System Resources, User Resources and GDI Resources. In this case "System Resources" is really shorthand for either the User or GDI resources, whichever is lower: The overall "System Resource" bar simply shows you whichever resource pool (User or GDI) is lowest at any given moment.
If you minimize the Resource Meter, it installs itself in your System Tray, by the clock: It becomes a tiny bar graph that shows you available System Resources (again, this is simply the lower or either User or GDI resources) in near real-time. If you want more detail, you can hover your mouse over the tiny bar-chart icon, or click on the icon to open the full-sized chart display.
I created a shortcut to the Resource Meter (C:\WINDOWS\ Rsrcmtr.exe ) and dragged the shortcut to my Startup folder: C:\WINDOWS\Start Menu\Programs\StartUp. This way, the Resource Meter runs every time Windows starts.
Over time, you'll learn what constitutes acceptable resources for your particular system and apps. (When your resources get low enough, you'll sometimes get a warning from Windows suggesting that you close some apps in order to recover resources.)
Some people worry if their resources drop into the 70 percent; others fret if they go below 50 percent. I think these fears are left over from the early days of Windows: In normal use, my resources fluctuate between 30 to 60 percent free all day long, and that's fine. I also know that I can get all the way down to low single-digit percentages of available resources before I actually run into resource problems.
Your mileage may vary, but I generally don't worry about resources at all until or unless my Resource Meter shows me dropping into the 10 percent range or so.
So keep an eye on your meter: If your resources drop steadily during the day, you may have a leak. With careful use of the Resource Meter, you may be able to identify which app is causing the leak, and then visit the vendor's home page to see if there's a fix.
In the next column, we'll look at utilities that try to fix leaks. Meanwhile, what are your experiences with resource leaks? What apps have you found to be leaky? What tools or techniques do you use to plug the leaks or recover the resources? Join in the discussion!