Jump to content

Unusual memory issue - SOLVED -


krelian

Recommended Posts


Are you sure that both himem.sys and himem.exe are in c:\windows?

yep, I can see them

actually if I type himem.exe I get some text/options.

However if I run xRayeR's ios and select yes, it states that himem.sys is not found

Link to comment
Share on other sites

5) to access "Safe Mode" with > 1 GiB RAM you'll need both the VCache.VxD modded by Xeno86 and xRayeR's patch to IO.SYS.

Are you sure? Did you read my posts about system.cb in safe mode? They are here: http://www.msfn.org/board/more-than-win9x-safe-mode-t142953.html

If my solution works for safe mode, it can be more useful than binary patches.

@Usher: I've read it, rest assured.

Not enough carefully, I'm afraid.

But I'm willing to add your thread and your machine to the > 1 GiB list, provided you PM me the description of your system, in the lines of the descriptions of the machines already listed there.

I have written in my posts that I have NO machine with > 1 GiB RAM for testing now. You have, other users have, but I do not have and I will not have such a machine in the nearest future.

I recommend doing the following (read this as a Mini How-To), which works for both Normal and Safe Modes:

And I wanted to change it to be more logical, so I reordered the steps:

1) Applying MS KB311561, then rebooting.

Official MS patch is a must have. It should be installed with all other MS patches, f.e. using unofficial Support Pack (SESP). You may recommend SESP install.

2) Adding a "MaxPhysPage=48000", without the inverted commas to the [386Enh] section of C:\WINDOWS\SYSTEM.INI

This is not for safe mode. In safe mode SYSTEM.CB file is used, not system.ini. You should recommend also editing SYSTEM.CB.

3) Installing Xeno86's modded VCache.VxD (after this, usually, no MaxFileCache line is needed in SYSTEM.INI)

There is no need for this patch. It is just hardcoded setting from [vcache] section in system.ini/system.cb. Editing ini files should be recommended - this way users can test different settings and find the best settings for their machines.

4) Adding HIMEMX.EXE to C:\WINDOWS, and then renaming it to HIMEM.EXE

5) Running xRayeR's w98iopat.exe, in True DOS, from C:\

6) Creating a CONFIG.SYS in C:\, containing the single line "DEVICE=C:\WINDOWS\HIMEM.EXE /NUMHANDLES=64", without the inverted commas.

The changes in 4-6) are for using memory manager other than MS HIMEM.SYS. Once again, I have no machine to test it with > 1 GiB RAM, but from FreeDOS mailing lists I know Japheth's HIMEMX.EXE may still have some bugs and compatibility issues that are not solved yet.

For even better results, one should instead use RLoew's RAM Limitation Patch, of course, but that's not for free, and the above procedure is the most reliable way to do it completely for free, in my experience.

In general, your recommendations are for advanced users, while my solution could be good also for testing by newbies.

And you know there is no need to use as much RAM as it is possible in safe mode. It is enough to have any simple, safe and working solution. Just someone ought to test it.

Link to comment
Share on other sites

5) to access "Safe Mode" with > 1 GiB RAM you'll need both the VCache.VxD modded by Xeno86 and xRayeR's patch to IO.SYS.

Are you sure? Did you read my posts about system.cb in safe mode? They are here: http://www.msfn.org/board/more-than-win9x-safe-mode-t142953.html

If my solution works for safe mode, it can be more useful than binary patches.

@Usher: I've read it, rest assured.

Not enough carefully, I'm afraid.

I have written in my posts that I have NO machine with > 1 GiB RAM for testing now. You have, other users have, but I do not have and I will not have such a machine in the nearest future.

Carefully enough. I only missed the fact you don't have a machine with enough RAM to test your idea.

There is no need to your adversarial posture. My only interest is to help. And I feel that, when striving to do so, it's more sensate to propose time-proven solutions than experimental ones, as the fist option. That said, thank you for posting your interesting idea and also for calling my attention to that interesting old thread by Tihiy.

And I wanted to change it to be more logical, so I reordered the steps:

1) Applying MS KB311561, then rebooting.

Official MS patch is a must have. It should be installed with all other MS patches, f.e. using unofficial Support Pack (SESP). You may recommend SESP install.

You also didn't read the OP carefully enough. The OP says he's already installed SESP 2.1! However, I recommended installing KB311561 just to be on the safe side, since, for me, it's evident he's running Win98SE in an unstable configuration, and did not do the time-proven tweaks for being able to use safe mode.

2) Adding a "MaxPhysPage=48000", without the inverted commas to the [386Enh] section of C:\WINDOWS\SYSTEM.INI

This is not for safe mode. In safe mode SYSTEM.CB file is used, not system.ini. You should recommend also editing SYSTEM.CB.

While it would, AFAIK, be harmless to recommend the change to SYSTEM.CB, no amount of prodding will be enough to make me use krelian as a guinea-pig for your new method, since there are time-proven alternatives I'm familiar with and know for sure that work.

3) Installing Xeno86's modded VCache.VxD (after this, usually, no MaxFileCache line is needed in SYSTEM.INI)

There is no need for this patch. It is just hardcoded setting from [vcache] section in system.ini/system.cb. Editing ini files should be recommended - this way users can test different settings and find the best settings for their machines.

That's simply not true. While Xeno86's modded VCache.VxD changes the default value for VCache, which is only used when there is no settings in the [vcache] section of SYSTEM.INI/.CB, it duly abides by any settings found there, when they exist. So it's a better all-round alternative to the original MS VCache.VxD, and should be used, at least, by all users running 9x/ME with > 1 GiB RAM. In fact, while it caters for the fact that there is no [vcache] setting in the original SYSTEM.CB, so that it obviates the need for this setting both there and in SYSTEM.INI, it'll also abide by such a setting present in SYSTEM.CB. Hence, Xeno86's modded VCache.VxD won't prevent anyone from tweaking their .INI and .CB files to their liking, in no way, but sets a more secure background to fall to, if needed. Had you read carefully enough VCACHE fix attempt, you'd be cognisant with all I said above, and there would be no need for me to reply to this particular point.

4) Adding HIMEMX.EXE to C:\WINDOWS, and then renaming it to HIMEM.EXE

5) Running xRayeR's w98iopat.exe, in True DOS, from C:\

6) Creating a CONFIG.SYS in C:\, containing the single line "DEVICE=C:\WINDOWS\HIMEM.EXE /NUMHANDLES=64", without the inverted commas.

The changes in 4-6) are for using memory manager other than MS HIMEM.SYS. Once again, I have no machine to test it with > 1 GiB RAM, but from FreeDOS mailing lists I know Japheth's HIMEMX.EXE may still have some bugs and compatibility issues that are not solved yet.

Japheth's HIMEMX.EXE v. 3.32 does indeed have some remaining bugs, the ugliest of which is creating orphan handles in some very contrived scenarios. It also simply ignores one switch, the TESTMEM switch if I remember right. And its implementation of XMS 3.0 functon 88H does not return the "highest ending address of any memory block" in the proper format (viz. in kiB). I know that from first-person experience, both from testing HIMEMX.EXE extensively and from analysis of the released source code. However, none of those bugs create any problem serious enough to prevent the day-to-day use of HIMEMX.EXE, which is a convenient tool for postponing XMS related problems caused by too much RAM for an unpatched VMM.VxD. For more on this, you should read again this most interesting post by RLoew on HIMEMX's limitations. And, BTW, HIMEM.SYS v. 3.95 also has standing bugs (three, at least, which I intend to address by releasing a patch for it in the near future), but that also doesn't prevent it from being usable and useful.

For even better results, one should instead use RLoew's RAM Limitation Patch, of course, but that's not for free, and the above procedure is the most reliable way to do it completely for free, in my experience.

In general, your recommendations are for advanced users, while my solution could be good also for testing by newbies.

And you know there is no need to use as much RAM as it is possible in safe mode. It is enough to have any simple, safe and working solution. Just someone ought to test it.

Now, here are various points, which have to be answered separately:

  • RLoew's RAM Limitation Patch is not free, but is absolutely user-friendly, and can be applied with success by even the most unskilled of newbies. And RLoew gives outstanding good support for his customers, on top of that.
  • Other solutions are free, but less user friendly. And there is only us, other users, to give what best support we can muster for other users trying to apply them.
  • Anyone who seriously intends to run Win 9x/ME nowadays, especially with > 1 GiB RAM, must seriously intend to become an advanced user, if he isn't already. Whoever wants easy should look elsewhere, because the one thing the Win 9x/ME world cannot be anymore is "simple": you have to strugle with hardware, drivers and the like every single day, and to do that minimally efectively you must be able to work both from True DOS and from within Windows, as needed, as the bare least (or, at least not be afraid to learn how to, when needed), and also welcome help in the form of time-proven bona-fide unofficial patches, that caring users provide to obviate you from the need of using debuggers/ disassemblers/hexeditors yourself.
  • I'm not, and never was, against the testing of your proposed solution. But, in principle, that should be done by experienced users solely, until proven to work well. What I'm certainly against is skipping over such careful testing and, instead, using new-users-in-need as guinea-pigs. That's all. Now, in the specific case of your proposed method, as it just involves editing SYSTEM.CB, I think the testing can cause no harm, so it's up to krelian to decide whether he wants to do it or not. In any case, it's counter-productive to have two users advising krelian to do completely different things at the same time.

Link to comment
Share on other sites

I give up:wacko:

I really dont understand what went wrong.

and yes the files are all present in C:\....I might be stupid but I aint bloody stupid

I'm going to delete the partition and reinstall it

@dencorso (and usher)

I really appreciate you spent time trying to help me out, dont really wanna waste anymore of it...but if you can give me just a final little help......

I will only put a single 512mb module on the mobo, just to be on the safe side

after that, I figure these are steps I need to take?

-install SP2.1

-reinstall KB311561, just in case

-place the 2x1GB memory modules and clear CMOS

-follow your instructions in post #12

so if I understand correctly, config.sys in C\ will only have A SINGLE line?

autoexec.bat though should still be empty?

bye for now

Edited by krelian
Link to comment
Share on other sites

Since you're reinstalling, let's do it this way (let's let the installation of office XP for after all else is working OK):

With just 512 MiB RAM do:

1) Install Windows and check it's working fine.

2) Install SP2.1 and check it's working fine.

3) Add a "MaxPhysPage=48000", without the inverted commas to the [386Enh] section of C:\WINDOWS\SYSTEM.INI

4) Install Xeno86's modded VCache.VxD

This should be enough to get you ready for more RAM.

Now, let's give Usher's method a test, since you'll will be at a point it's harmless to do and it may work.

5) Add a "MaxPhysPage=48000", without the inverted commas to the [386Enh] section of C:\WINDOWS\SYSTEM.CB

If there isn't such a section, create it at the end of the file. *Do* *not* copy SYSTEM.INI over SYSTEM.CB!

Just edit it with notepad, OK?

6) Now place in the 2x1GB memory modules and clear CMOS and reboot.

Windows should start normally. Restart in Safe Mode. Restart back in normal mode. Report.

If Usher's method works, that's it. If not, we now remove step (5) and proceed to add Japheth's HIMEMX.EXE and xRayeR's IO.SYS patch. If that's necessary, I'll give you as detailed instructions as you find necessary, OK?

Good luck!

@Usher: Yes, I know I'm proposing to use just half of your trick, since I recommended Xeno86's patched VCache.

But if what I proposed above works, then you've already got your proof of concept, so bear with me, please!

Link to comment
Share on other sites

great, thanks, I'll try that

there's another thing I forgot to ask:

last time I used some switches at setup, list here:

http://support.microsoft.com/kb/186111

for example those to bypass scandisk and not installing ACPI, I got the idea from this page

http://www.usbman.co...8seusbguide.htm

is there anything else I need to actually bypass?

Edited by krelian
Link to comment
Share on other sites

No. And installing 98SE without ACPI is a good idea which leads to a generally more stable configuration. I wrote about how to remove it from a finished installation in an old (but still useful) post, for which there is a link in the first post of the > 1 GiB thread. But, since you're installing from scratch, it's much cleaner to prevent Win 9x from using ACPI at install time. If all the rest works OK, I may then suggest you some extra tweaks that may be done at any time afterwards.

Link to comment
Share on other sites

IT WORKS!!!!

used the usher's method, or dencorso's guidelines till step 6

I can now enter safe mode with 2GB installed and the system is very stable, I burned a few cds, flashed the firmware of my SCSI burner, no memory problem whatsoever

couple of things, probably obvious, probably not.....bear with me I'm still such a noob

1)This one is really, really weird

When I enter safe mode, my USB mouse doesn't work, even there's NO POINTER, it's like disappeared

BUT if take a memory module off, then it works no problem.

Put the 2nd memory module back in, used a USB to PS/2 adapter, rebooted. Now the pointer reappeared, but still I can't move it

Rebooted again, entered BIOS options and "disabled USB mouse support". Now the mouse finally works even in safe mode.

2)I actually reinstalled windows for 2 times.

The first time also went good, however I installed Office XP as I had a feeling that's what messed things last time.

And as expected, couldn't boot into safe mode.

There must be something in the Office XP engine that **** with memory settings, but whatever I'm not gonna risk again. I'll probably install either Office 2000 or 97

Edited by krelian
Link to comment
Share on other sites

:thumbup Congratulations! :thumbup

I think now is high time for you to do a full, sector-by-sector, partition image, to obviate the necessity of ever reinstalling again. Do it before installing Office (whatever version) and, after you settle for a version, do it again. Theis way you start a library of known-good backups, which will make it much easier, from this point on, to experiment on the OS and avoid big-scale messes. I use Ghost 2003 for it, but there's a good free alternative jaclaz pointed to some time ago: PartitionSaving (link)! Do give it a try (and use the DOS version of the program, which is the easier and safer way to do images). Say... did you get a single BIOS setting, using which you mouse works OK both in normal and safe mode? This is the only point that was not clear for me in you latest post. And, BTW, your machine has been added to the > 1 GiB list. :yes: Do check whether I described it right, please.

@Usher: Congratulations for you, too! Now your method IS tested, and proven to work. I'll add a "Mini How-To" post to the > 1 GiB list quite soon, containing both your original method, and my modification of it (viz. using Xeno86's VCache, instead of [vcache] settings).

You two rock! :thumbup

Link to comment
Share on other sites

@krelian - just a comment/explanation of the USB Mouse (AFAIK)...

Depends on the BIOS of the MoBo whether it will work or not. In your case not, in mine yes.

If I understand my BIOS, it has "enable USB Legacy Support" which allows for the BIOS "emulating" PS2 until the OS takes over at which point the Drivers are loaded for USB devices. In Safe Mode, no Drivers are loaded but the BIOS allows for the OS to "see" PS2 devices. Very nice.

In your case, it appears you get one or the other (many older Compaq's/Gateway's are like that). So, your method of "switching" works. Use USB when not going to Safe (faster than PS2) and just "switch" when Safe is needed.

Edited by submix8c
Link to comment
Share on other sites

Hi submix, thanks for your input, funny thing the problem is now gone.

Just for the heck of it, I tried to clear CMOS once again and that did it, now I can boot into safe mode with a mouse plugged into the USB port

You two rock! :thumbup

I HARDLY rock ;)

I could have never figured it out without your and usher's help, the only people that rock here are you and him

I always thought to get some HDD cloning software but couldn't decide which, thanks for that

pm coming your way

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...