512MB Fix in Unofficial service pack for WIN98SE

[DGundling]

The service pack states that it has a fix for the 512MB RAM limit in WIN98SE. I installed the most recent version of the service pack but the system manager still shows only 512MB of the 1GB memory installed.

Any idea what to try next?

I have 3 512MB RAM modules. Any one of the three will be recognized by WIN98SE but no combination of two will yield recognition of 1GB installed.

BTW, before I had a HD crash which forced a complete wipe of the HD (Fdisk), the system recognized the 1GB after the service pack install. The service pack at that time was the SEP/Oct 2005 version, I think.

As I hazily recall, the only thing I had to do to get it to recognize the 1GB initially was to do the Max Files fix.

Thanks.

[LLXX]

The service pack states that it has a fix for the 512MB RAM limit in WIN98SE. I installed the most recent version of the service pack but the system manager still shows only 512MB of the 1GB memory installed.

Any idea what to try next?

That's not a "fix" isn't it... more like a workaround. Check to see if MaxPhysPage has gotten a value in the system.ini, and remove that line completely.

The real solution is to decrease the maximum size of the file cache. See the other thread somewhere here for more information.

Edited July 12, 2006 by LLXX

[kartel]

Add this to system.ini

[vcache]

MaxFileCache=524288

Edited July 19, 2006 by kartel

[galahs]

I'm always worried good information sites will vanish off the net. So I'll cut and paste a great win9x memory resource here. I used to run Win98 on my Pentium 4 which had 1.5GB of RAM.

The secret was to diasable all RAM over 1GB!!!

from http://www.aumha.org/win4/a/memmgmt.php

Windows 98 & WinME

Memory Management

Updated October 15, 2003

Memory management in Windows 98 and Windows Millennium Edition (WinME) is dramatically improved over what existed in Windows 95. It is so much improved that, for nearly everyone, nearly all the time, the best recommendations on how best to optimize memory usage in Win98 is: Let Windows handle it.

The following sections discuss the main memory management considerations of VCache and swap file management, and the value of more RAM. Along the way, efforts are made to debunk some prevalent fictions that remain in circulation concerning Windows’ native handling of memory.

IMPROVEMENTS IN WIN98/ME VCACHE

Foremost among the improvements in Win98/ME memory management are the changes in VCache. Simply put, the VCache is used (among other functions) to store previously used code and data that Windows thinks might be needed again. If the code or data is just flushed from memory, but is then needed again, it has to be read anew from the hard drive when it is again needed. Reading from the hard drive is much slower than finding the code or data already in RAM. Some code is used quite often. If it has to be read from the hard drive over and over again, this would slow down performance considerably. The VCache concept is that, as long as there is unused RAM sitting about, we should just cache information in it that we might need again. (There is smart code that makes decisions about what to keep, how long to keep it, etc.; this has all been taken into consideration and is not particularly important to the present discussion.) Then, since this is only a “just in case” cache, if the RAM is needed for something else, part of the VCache contents are flushed and the RAM is made available.

One improvement in VCache management in Win98/ME over Win95 is that Win95 had a bug that kept VCache from releasing RAM when it was needed. VCache would just keep growing sometimes, and the amount of available RAM would diminish accordingly, forcing more swap file activity (using the hard drive as a substitute for RAM). This is the famous “memory leak” of Win95. The user’s solution in Win95 was to put MinFileCache and MaxFileCache lines in the [vcache] section of the SYSTEM.INI file to control the size of VCache. This was sometimes a great help (especially on the 12 MB, 16MB, and 32MB systems which were the vogue in Win95’s heyday). But, in Win98, this problem was fixed (with further improvements in Windows 98 Second Edition, that carried over into WinME), and these [vcache] lines are not needed. Not only are they not needed, they actually get in the way in Win98/ME. In Win95 they improved performance, but in Win98/ME they decrease performance, because of a second improvement that was made in memory management for Win98 — to be discussed in a moment.

But first, THREE EXCEPTIONS TO THE FOREGOING:

EXCEPTION No. 1: For systems with more than 128 MB of RAM, setting a VCache maximum of about 70% of your total RAM is recommended as prophylaxis against run-away VCache growth in rare, specialized situations. (A tip of the hat to MS-MVPs Ron Martell, Ovidiu Popa, and Alex Nichol for months of experimentation and documentation of these details and recommendations.)

EXCEPTION No. 2: VCache increasing above 512 MB can create serious memory handling problems. If you have more than 512 MB of RAM, a VCache maximum of 524,288 KB (or a little less) is recommended. This is obtained by adding a MaxFileCache=x entry in the [vcache] section of SYSTEM.INI, where x is the maximum value you wish to set. VCache is limited internally to a maximum cache size of 800 MB. The problem is that, on computers with large amounts of RAM, the maximum VCache size can be large enough that it consumes all of the available addresses in the system arena, leaving no virtual memory addresses available for other functions such as opening an MS-DOS prompt. This problem may occur more easily if you have an AGP video adapter: The AGP aperture is also mapped to addresses in the system arena, and if VCache is using its entire 800 MB allowance and an AGP video adapter has a 128 MB aperture mapped, there will be very little address space remaining for other system code and data that must occupy the available range of virtual addresses.

EXCEPTION No. 3: For systems with more than 1 GB of RAM, the defaults in Windows 98 or ME can cause continuous rebooting of the computer, or to hangs or serial reboots during the Windows upgrade process. To resolve this problem, add a MaxPhysPage=40000 entry in the [386enh] section of SYSTEM.INI. This effectively limits the amount of RAM Windows can access to 1 GB. (Microsoft limits ths recommendation to systems having more than 1.5 GB of RAM, but the solution is to roll it back to 1 GB. See MSKB 304943.) Microsoft has now flatly stated that, “Windows Me and Windows 98 are not designed to handle more than 1 GB or RAM. More than 1 GB can lead to potential system instability.”

The second improvement is that Windows can now execute code or access data directly from VCache. In Win95, this was not possible. If code was stored in VCache, it had to be passed to another part of RAM before it could be executed. This was still much faster than reading it again from the hard drive, but, nonetheless, took a small amount of time. In Win98/ME, it does not have to be moved to another part of RAM — it can be run directly from VCache itself. This saves a bit of time.

In Win95, anything stored in VCache was disposable (but the “memory leak” bug prevented the trash from being taken out when necessary). In Win98/ME, code in VCache may not be disposable — it could be “live code,” part of a program you are using at the time.

This explains why VCache sometimes seems not to give up memory that is needed for other functions. If code or data were stored in VCache only for caching purposes, then it should be emptied out before the swap file is used; but in Win98/ME, VCache often will stay quite large, forcing the swap file to be used more. Is this another memory leak? No, it isn’t. It would be a memory leak if the contents of VCache were only stored, inactive code or data. But if the contents are code or data currently being used (as it commonly will be in Win98/ME), we have quite another story!

WHY IS THE SWAP FILE SO LARGE?

For most people, in most situations, the best advice regarding the Win98 or WinME swap file is: Let Windows handle it. There are dozens of recommendations on ways to optimize it just a bit (some of which I use, and perpetuate, myself), but these are so system-dependent that it would take a huge article to explain all the ifs, ands, and buts of one approach over another in a particular situation. These discussions occur quite regularly online, on peer-support and general discussion newsgroups, so it is not hard to find opinions.

I will indulge myself by giving one, which I regard as the least controversial and most helpful: The single best swap file arrangement is to have two physical hard drives, and to place the swap file — and nothing else! — on the first partition of the second physical drive. Be sure the partition is generously sized. Nonetheless, and to simplify the matter for the present, there is rarely any need for someone to worry about this in order to have a happily purring Win98/ME system. The general rule prevails: Let Windows handle it.

A common confusion and concern is that, even with a great amount of RAM on the computer, Windows creates a swap file, and the swap file sometimes grows quite large. To respond to the first point: Windows will always create a swap file — that’s just the way it works. Also, some applications require swap file use even if Windows might not use it otherwise. Just expect this to be the case. Of more concern is that the swap file may seem to be much larger than is really needed. For example, my swap file at this moment is not being used at all (0 swap file usage, as measured by System Monitor), but the swap file’s allocated size (measured by Norton System Doctor) is 111 MB! Earlier today, the actual usage was about 10 MB, and the allocated size was 137 MB.

Why in the world would this be? It is because Win98/ME “thinks ahead” more than Win95 did. One way it does this — since the resizing of the swap file is one of the biggest slowdowns to system performance on Win95 — is to more intelligently allocate space, in advance, for anticipated swap file needs.

How does Windows know how much swap file space you might need in the near future? Each program specifies how much memory should be set aside (allocated) for its use. Generally, programmers request more memory than they need. (If done skillfully, this is a good thing: When running a program, one would rather have a bit too much memory available, rather than a bit too little, right?) This resembles reserving a table at a restaurant, even if you don’t plan to show up to eat, just in case you get hungry later. An OS has to allocate this requested memory for possible use by the program, even if it may never be used. Windows is smart enough to use the swap file for these “unused restaurant table reservations,” rather than use physical RAM! Think about it: This frees all of physical RAM for actual current memory needs — active program code, actively used data, etc. — and diverts the “wasted space” allocations away from physical RAM. If you have enough RAM, the swap file is never written to — it just takes reservations!

The Swap File Usage monitor in Norton System Doctor measures the allocated size, whereas the equivalent gauge in Windows’ System Monitor measures the actual swap file usage. In the above example, with the many programs I presently have loaded, Windows thinks that I just might need over 100 MB of swap file space. It has prepared for that possibility ahead of time.

This concept is central to the discussion below concerning one current recommendation of a way to handle Win98/ME memory management. The method below sounds, on first exposure, like a bad idea — but it may, in fact, have some worthwhile troubleshooting applications, and (if initial testing is any indication) may be worthy recommendation for Win98/ME systems with larger amounts of RAM installed. Whether good idea or bad, the technique deserves an airing and discussion.

THE ADVANTAGES OF MORE RAM

People often complain that they have added a lot of RAM to their computer, but very little of it is free.

If Windows has anything at all it can do with the RAM, then free RAM is wasted RAM. Windows will try to make use of all of the RAM it can, for one good purpose or another. This benefits the user. Having unused RAM rarely benefits the user. In fact, the advantages of more RAM on a computer boil down to two:

1. Reducing swap file use.

2. Enabling a larger VCache.

A large VCache is not a bad thing. Generally, it is a good thing (presuming Windows has a use for it at the moment).

Bottom line: Let Windows handle it.

NOTE: In Win95/98, if you have more than 1 GB of RAM, Windows may not start. A solution for this problem is given in the Microsoft Knowledge Base article “Error Message: Insufficient Memory to Initialize Windows.” The gist of Microsoft’s work-around is to artificially limit the amount of RAM to 768 MB. This may, however, be too stringent a restriction — a value only a little below 1 GB may solve the problem with less constraint on your RAM. A little experimentation will resolve this for you.

THE “CONSERVATIVE SWAP FILE USAGE” TWEAK

One popular recommendation for Win98/ME memory management is to add the following line to the [386Enh] section of the SYSTEM.INI file: ConservativeSwapfileUsage=1

Those who have used it, and reported favorably on it, say that it keeps their swap file usage lower, does not impede performance in any situation they have noticed, and seems to improve performance in other situations. I have seen this reported on systems with 128 MB to 256 MB of RAM. I have seen it on my own 128 MB system.

Is there anything to this? What does it do?

Sometimes appearances can be deceiving. Sometimes not.

Based on benchmark testing by MS-MVPs Mike Burgess, Alex Nichol, and other MS-MVP colleagues, I have concluded that this tweak can be of real value in many Win98/ME systems with 128 MB of RAM or more (and on some 64 MB systems). If your machine has sufficient RAM that, for your particular use of your computer, there is relatively little swap file usage, then this tweak will probably improve system performance by reducing the overhead in swap file maintenance activities that you do not really need.

In contrast to behavior in Win98, testing of this by Mike Burgess in Windows Millennium Edition showed no significant performance difference with or without it. However, because it does impede swap file run-away growth on some computers — such as mine! — I recommend this on Windows ME.

The default value of ConservativeSwapfileUsage was 1 in Win95, and 0 in Win98 and WinME. Therefore, this recommended tweak reverts a portion of the Win98/ME improved memory management system back to the way Win95 did things. (That’s what sounded like such a bad idea at first, because Win98 or ME is generally far superior to Win95 with regard to memory management.) A valid question, though, is whether it is a good (that is, useful) idea for systems that have grown past the RAM size originally contemplated as typical when Win98 was created. For many computers, the answer seems to be: Yes, it is.

According to MS Knowledge Base article 223294,

Windows 98 added a new feature, PageFile_Call_Async_Manager, that allows the Memory Manager to asynchronously write out page file (swap file) buffers during periods of time when VFAT file system activity is not busy. This feature can affect the behavior of VxDs [virtual drivers] that monitor and/or otherwise intercept PageFile VxD functions.

(See the article itself for more technical background on the rather clever way this function operates.)

This feature is part of improvements made initially in Windows 98 that lend the appearance of faster performance to a Win98/ME computer because many of the small time-consuming activities are deferred to moments when you are not actually asking the computer to do anything. The tweak described above disables this feature. As MS-MVP Jeff Richards summarized it, “It’s more conservative in scheduling non-critical swap-file activity.”

Microsoft advises that this change may be “at some cost in overall system performance.” Furthermore, in theory it would seem that this would make the computer seem slower. But only experimentation on a given system (and by a particular user on that system) can determine what the subjective performance difference (pro or con) would be. Based on experience to date, I would say it is probable that this tweak will have a positive effect on systems with an unusually large amount of RAM, and very little swap file activity. It is unlikely that it would have a positive effect on other systems, and might have a negative impact on their performance.

Since the tweak is so easy to undo — just remove, or comment out the line added to SYSTEM.INI — “power users” will likely want to experiment with this and give more feedback to the general community.

Here's Microsoft solution:

http://support.microsoft.com/?kbid=184447

===============================================

Error Message: Insufficient Memory to Initialize Windows

SYMPTOMS

If your computer has 1 gigabyte (GB) or more of random-access memory (RAM) installed, Windows may not start. Also, when you try to start your computer, you may receive the following error message:

Insufficient memory to initialize Windows.

Quit one or more memory-resident programs or remove unnecessary utilities from your CONFIG.SYS and AUTOEXEC.BAT files, and restart your computer.

This behavior may also occur during Windows Setup, or when you try to start Windows for the first time.

RESOLUTION

To work around this issue, add the following line to the [386enh] section of the System.ini file:

MaxPhysPage=30000

This limits the amount of physical RAM that Windows can access to 768 MB.

To do so, use the following steps:

1. Use any text editor (such as Notepad) to edit the System.ini file.

2. Add the following line in the [386Enh] section of the file

MaxPhysPage=30000

3. Save the file, and then restart your computer.

If this problem occurs during Windows Setup, use the following steps to resolve the issue:

1. Restart your computer. When you see the "Starting Windows 95" message, press the F8 key, and then choose Command Prompt Only from the Startup menu.

For Windows 98, restart your computer, press and hold down the CTRL key until the Startup menu appears, and then choose Command Prompt Only.

2. Change to the folder into which you are attempting to install Windows.

3. Edit the System.ini file. To do so, type edit system.ini, and then press ENTER.

4. Add the following line in the [386Enh] section of the file

MaxPhysPage=30000

===============================================

As suggested in the previous article, I ignored Microsofts recommendation and used MaxPhysPage=40000 and it worked fine! (1GB of RAM is made available)

Edited July 20, 2006 by galahs

[LLXX]

I think it depends on the mobo and chipset. I've successfully used 2Gb of RAM with no problems (after setting MaxFileCache as described to 524288).

It's rather pointless IMHO to use MaxPhysPage... might as well just physically remove the extra 512Mb, if it's not even being used.

[galahs]

I guess its just a better alternative than removing ram chips if your dual booting with a newer OS.

[kartel]

1 gig is plenty........more than that and your putting a bus motor on a bike............

[Petr]

It's rather pointless IMHO to use MaxPhysPage... might as well just physically remove the extra 512Mb, if it's not even being used.

Multi boot configuration?

Petr

[kartel]

ya i don't know.............

[randiroo76073]

Multiboot = more than 2 OSes on 1 machine, ie: 2 windows & 3 linux distros