We help IT Professionals succeed at work.

Memory leakage

I've got a problem.
At first I have a PC in my office Pentium III with 64 MBytes of RAM, and with a few applications open I began to get the Out of Memory error.
So I get 64 MBytes more (for a total of 128 MBytes), and the problem still contiued.

The company change all the development machines and I get a Pentium III (900 MHz) and 256 MB of RAM memory. I still experience the same problem, so I want to know if there is a way to monitor the used memory and wich program is using this memory, so I can find which program is causing this memory leakage.

Watch Question

Your most likely problem is resources.  Try Start-Settings-Control Panel-System and click on the performance tab.  If this is a resource problem it will not be solved by adding memory since resources are set and limited regardless of how much memory you have.  If you have in98 you can use the Resource Meter - http://www.smartcomputing.com/editorial/article.asp?article=articles%2F2000%2Fs1107%2F06s07%2F06s07%2Easp.  You could also try replacing your modem if you have an HSC modem since it is a notorious resource hog.  Also take a look at how many and which programs you are running.  Maybe they are grabbing and not releasing resources.

check your disk space and swap file settings. You can have all the RAM in the world, but you will still get the out of memory errors if the swap file is unsufficient. Your swap file should be at least as large as the installed RAM because of the method Windows uses to "page" memory.

Top Expert 2007

If you have win9x or WinME, then this can be a problem.

NT and Win2k do not have this problem.

From: dew_associates    Date: 01/22/2001 02:19PM PST
                   Okay, first don't confuse system resources wih physical memory, they are entirely different animals,
                   even though they are related.

                   memory handlng across the windows platforms are handled as follows:

                   The virtual addresses used by a process do not represent the actual physical location of an object in

                   memory. Instead, the system maintains a page map for each process, which is an internal data structure

                   used to translate virtual addresses into corresponding physical addresses.

                   The virtual address space is divided into partitions as follows.

                   Windows NT Server Enterprise Edition/Windows 2000 Advanced Server: The 3 GB partition in low memory

                   (0x00000000 through 0xBFFFFFFF) is available to the process, and the 1 GB partition in high memory (0xC0000000

                   through 0xFFFFFFFF) is reserved for the system.

                   Windows NT/2000: The 2 GB partition in low memory (0x00000000 through 0x7FFFFFFF) is available to the

                   process, and the 2 GB partition in high memory (0x80000000 through 0xFFFFFFFF) is reserved for the system.

                   Windows 95/98: The following are the partitions on Windows 95/98.

                   0K - ~64K (0xFFFF)

                   Not writable. This boundary is approximate due to the way the Windows 95/98 loads some features of Microsoft?

                   MS-DOS?. This memory is private to the process.

                   ~64K (0x10000) -
                   4 MB (0x3FFFFF)

                   Reserved for MS-DOS compatibility. This memory is fully readable and writable by the process. However,

                   this range of memory may have some MS-DOS-related structures or code in it, so processes should not

                   arbitrarily read from or write to it. This memory is private to the process.

                   4MB (0x400000) -
                   2GB (0x7FFFFFFF)

                   Available for code and user data. User data is readable and writable by the process. Code is execute-only.

                   This memory is private to the process.

                   2GB (0x80000000) -
                   3GB (0xBFFFFFFF)

                   Shared area, readable and writable by all processes. A number of system DLLs and other data are loaded

                   into this space.

                   3GB (0xC0000000) -
                   4GB (0xFFFFFFFF)

                   System memory, readable or writable by any process. However, this is where low-level system code resides,

                   so writing to this region may corrupt the system, with potentially catastrophic consequences.

                   Virtual Address Space and Physical Storage:
                   The virtual address space of each process is much larger than the total physical memory available to
                    all processes. To increase the size of physical storage, the system uses the disk for additional storage.
                   The total amount of storage available to all executing processes is the sum of the physical memory and
                   the free space on disk available to the paging file, a disk file used to increase the amount of physical
                   storage. Physical storage and the virtual address space of each process are organized into pages, units
                   of memory, whose size depends on the host computer. For example, on x86 computers the host page size

                   is 4 kilobytes.

To maximize its flexibility in managing memory, the system can move pages of physical memory to and  from a paging file on disk. When a page is moved in physical memory, the system updates the page maps   of the affected processes. When the system needs space in physical memory, it moves the least recently
                   used pages of physical memory to the paging file. Manipulation of physical memory by the system is completely
                   transparent to applications, which operate only in their virtual address spaces.

                   Setting aside this 4k to 2MB area for the moment, when windows begins the initialization process, switches
                   from 16bit to 32bit protected mode, the protected-mode cache driver *Vcache* initializes and obtains
                   the total physical memory and available drive space (subject to Windows minimum available drive space)
                   from either SPD or DMI intialization. Vcache then reserves enough memory addresses to permit it to access
                   a cache of the maximum size so that it can increase the maximum cache to that size if needed. These
                   addresses are allocated in a range of virtual addresses from 0xC0000000 through 0xFFFFFFFF, or between
                   3 and 4 GB, which is known as the system arena. This arena is comprised of two resources available to
                   Windows, physical memory and drive space. Unfortunately this Vcache initialization process is flawed.
                   The swing from Win95, to OSR2, then to Win98 attempted to correct much of this. Early on, Windows code
                   could only see 64MB of memory. Osr2 moved this 96MB, and Windows 98 (first release) moved this to 128MB.
   The final release of 98 moved this number to 800MB, which is the maximum that the 98 kernel can handle
                   without a complete rewrite.

                   As it were, 98 boxes with more than 512MB of memory still had problems, both in causing protection errors
                   as well as data read/write errors above 544MB. This didn't turn up until the release of the AGP50 video
                   cards with 128MB of on-board memory, and motherboards that permitted mapped apertures in the 64MB to
                   128MB range.

                   All this being said, let Windows manage memory, and you check these areas.

                   1. Make sure the MB bios is current.

                   2. Make certain that you have the correct memory for the motherboard and CPU combination. If it's PC-100
                   or PC-133, verify (don't take the resellers word for it) that it is compliant.

                   3. Make sure that the correct memory timing settings appear in the Bios setup.

                   4. Make certain that all of the motherboard chipset drivers are loaded correctly.
I hope this helps !
Top Expert 2007


Low system resources
http://support.microsoft.com/support/kb/articles/Q90/7/62.ASP       WIn 3.x explanatiom
Still relevant for win9x/ME

Free memory utility GDI resources memory leaks. Low system resources.
From: ozphil    Date: 02/27/2001 04:45AM PST
                   Irwan, i'm after a permanent fix. I have a memory recovery tool from  http://www.meikel.com
From: irwank       Date: 02/27/2001 03:45AM PST
                   Have you try memory leak recovery tools?
                   I'm using AnalogX Maxmem (free).
                   Get it from www.analogx.com.
Hey, there are a lot of programs that do this. An excellent example, RAMPAGE.
                                                          Download it from cnet.com or www.softseek.com. Set it when you want the RAM to be  freed. When the RAM drops down below that level, it automatically clears excess  memory. it is higly recommended.
There's a freeware utility called Optix, which will show you what applications are hogging your resources. Here's a link:
Top Expert 2007
Lastly !!

From: CrazyOne     Date: 08/16/2001 07:43AM PST
               To add to what tmj883 was refering to about system resources.


               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.)

               1. Restart your computer, and do not start any programs.

               2. Right-click My Computer, click Properties, and then click the Performance tab. Note the percentage
               number next to System Resources. This is the amount of free system resources before you run any programs.

               3. Start one of your programs, use it as you would normally for 15 or more minutes, and then quit the

               4. Right-click My Computer, click Properties, and then click the Performance tab. Note the percentage
               number next to System Resources, and compare it to the number you noted in step 2. If your system resources
               are substantially less than they were previously, your program may be creating a memory leak. To resolve
               this issue, contact the manufacturer of your program to inquire about the availability of a fix for
               this issue. To work around this issue, restart your computer after you quit the program.

               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

               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.



               Authored by Fred Langa


go sys!

>a way to monitor the used memory and wich program is using this memory

try the utilities from

Hello all,
I am Computer101, a moderator from Experts-Exchange and also an expert within this topic area. This question has been open a long time.  What I am going to do is allow feedback from the questioner and experts.  If it is not resolved, I will delete or accept an answer based on the info I have been given, Experts, feel free to offer input.  I will monitor these questions for a period of 3-5 days and come back and evaluate.  I will have another moderator (who is also an expert in this topic area) look at the question also to ensure we do the right thing for this question.

Thank you
Community Support Moderator
Comment from SysExpert accepted as answer.

Thank you
Community Support Moderator

Explore More ContentExplore courses, solutions, and other research materials related to this topic.