Kahenraz

It doesn't matter how you run the program. The memory has been consumed and isn't being released. Unlike in Windows NT, I can't see any way of monitoring which process has allocated how much memory.

I haven't looked into it, but it might be possible to configure a Linux server with the proper security protocols that are compatible with these older mail clients, and have it sync with another, modern mail server, such as an Outlook or Gmail account. The tricky part is sending mail (smtp), as this is typically done through a trusted service that is whitelisted to other mail providers. I don't know if it's possible to proxy smtp through one computer to another remote service, for the purpose of supporting an older mail client. It would be interesting to consider, though. I have already experienced this issue of older security protocols breaking legacy applications previously. For example, GitHub no longer supports the security protocols with git, as provided by the last Cygwin version release for Windows 98. Cygwin's ssh from this same version is also unable to connect to modern Fedora Linux 36 on my network due to incompatible security, despite working just fine with a much older CentOS Linux 7.9 that is also present on the network. Sometimes there isn't anything wrong with the software per se, but it's the other end that refuses to talk with you because they no longer accept older protocols that are deemed insecure.

Maybe we should chat on Discord so I can bring someone else up to speed with the issue. My primary Windows 98 machine is actually very similar to yours; a Core 2 Duo E6700 with a Radeon X800. I like to use this machine for testing because it's very fast, but the memory problem can be reproduced on any hardware or VM.

The tool is meant for Windows 9x/ME to demonstrate memory leaks. It won't show any of the memory problems I've mentioned in Windows 8.1.

This tool has no window and therefore no place to receive messages. It polls the keyboard asynchronously, so it doesn't matter what is active in the foreground when you press escape. "I had no trouble with my machine." Your system may also visibly consume and not free memory, if you watch it from the System Monitor. If you let it run for a while, the amount of time varies depending on the hardware and its speed, it will consume enough memory that you can't open a DOS window anymore. Let it run further and eventually Win32 programs will break as well.

Hold it down or try pressing it a couple of times. It might not capture the keyboard press if you do it too quickly. Because it runs in the background, it can only capture asynchronously, which is subject to race conditions when reading the keyboard.

Disabling VCACHE did not help. Anyone can replicate this issue if they want to. As mentioned previously, download my stess-open tool and have it open and close Notepad until it runs out of memory. https://www.vogons.org/viewtopic.php?f=24&t=89135

I'm still leaning towards a memory leak. When I got the memory pressure to the point where I could only open one Notepad at a time, continually opening and closing programs and windows by hand continued to slowly consume whatever resources were left until things started to stop responding. I could perform some emergency frees by closing other applications running in the background, but continued opening and closing of Notepad consumed those resources as well. I wonder if it's a bug in how the vcache is released.

I've been trying to monitor different memory areas that are trackable by System Monitor, and I think I found something consistent. The memory that displays as "Locked non-cache pages" is a resource that is normally consumed when programs are run and freed when they are closed. I can see this by opening multiple instances of a command window or Notepad. But if I open and close a program enough times, like Notepad, this resource slowly begins to creep and is not freed. This looks a lot like either a memory leak, fragmentation, or both. Is there anyone who can provide any more information? Edit: After further testing, if I continue to push the system and keep opening and closing Notepad, eventually the system will start to reporting that there isn't enough memory even for Win32 applications. It seems that the issue simply breaks DOS functionality much earlier. I can open one Notepad, but there isn't enough memory for a second one, despite there being almost 200MB of available physical memory, and the entire swap file. At this point, the entire system starts to struggle under its own weight of doing nothing at all. Opening My Computer causes it to hang as it can't get the resources it wants, even though Explorer is already running. It's very bizarre.

There is usually a mixer to raise the volume of the MIDI synthesizer or lower the other volume lines to compensate. The issue that I always have is that Adlib sound seems to always get lumped together in the mixer with the master volume or digital sound. Some games allow you to control this volume separately in-game, but not always. The best solution I found was to use a dedicated card for Adlib and route it into the Line-In of whatever card is meant to be used as the primary. This way you can control the Adlib volume by the Line-In slider of your audio mixer.

What's this about?

It's not LDT resources.

Thank you for this tip. I found this related KB article. https://www.betaarchive.com/wiki/index.php?title=Microsoft_KB_Archive/229670 The unofficial Windows 98 service packs provide gdi.dll and gdi32.dll, and this bug does not affect Windows ME. So it appears that I have already accounted for this. I'll see about finding an LDT resource counter and see what that looks like to rule it out entirely.

This problem is the state that the operating system can find itself in where some kind of "memory" resource has become exhausted. I can induce this state during testing by using my stress-open tool. I wrote this tool as a reaction to finding my system falling into this state with normal use and trying to find a way to induce it on demand for testing and replication. This is after a fresh reboot. The tool opens Notepad (a native Win32 program) and closes it gracefully with the WM_CLOSE message (this is what happens when you click the X button). The stress-open tool is also a Win32 binary; there is no 16-bit code here. But somehow the operating system becomes unable to open a DOS window, despite still being able to run Win32 applications. What DOES happen right before this state is my tool tries to open notepad.exe but it fails to open. At this point I can continue to open Notepad as normal, but I can't run anything that uses the DOS subsystem. Maybe it's some kind of race condition that corrupts memory somewhere in the kernel. Does Windows 98 support JIT debugging? Maybe this can provide some more information as to what causes Notepad to crash.

I managed to replicate this issue and put the system into this out of memory state. Here is a video of Windows 98 in a VM exhibiting the problem. I've saved it as a suspended state, so I can spin it up at any time. I can still run applications, but I'm unable to open any command prompt windows. Even if I close every other running application with Process Explorer, I can never put the system back into a state where it has the memory to open a DOS window. I have replicated this on fast hardware (i945/Pentium D/Core 2), age appropriate hardware (i440/Pentium 3/650Mhz/128MB RAM), and in a virtual machine (VMware) on a Ryzen 1800X. The easiest way to put the computer in this state is to open an close an application repeatedly (such as Notepad). Sometimes it takes a few minutes. Or an hour. Or eight hours. It's somewhat random. If you're not sure how long it will take, then it's best to do this operation overnight. I've written a program that will automate the process. You'll know when it's finished when an error box appears which says "Couldn't find a window to receive WM_CLOSE message", which indicates a failure to open the target application. Here is a video of the system reporting the memory error when I try to open a DOS window. Note that, while there is in fact some memory pressure, there should still be plenty left to run a DOS command window. I also demonstrate in the video that there are no problems running Win32 programs. I've found that the more memory that is available past a minimum of 128MB, the more physical memory there is leftover once the system reaches this state, so the amount of unused physical memory is not indicative of "free memory" as it pertains to this problem. The failure state of Windows ME is completely different when trying to induce it like this. The system will either crash Explorer or cause a system fault. On actual hardware, this causes the system to reboot suddenly. In a VM, a fault is reported that caused the virtual CPU to enter a shutdown state. When I'm just working on a real machine, the state comes naturally and I get the familiar popups and the inability to open a DOS window. I have started configuring both hardware and VMs, Windows 98 and ME, to the following conservative values for vcache, and it seems reasonable given the amount of physical memory available: [vcache] MinFileCache=1024 MaxFileCache=32768 As far as testing various patches, updates, and service packs, things that I have used or tried: I need to use this patch to allow Windows 98 to run on my Ryzen CPU, tested 0.7.45 and 0.7.47, with and without Q288430: https://www.vogons.org/viewtopic.php?f=24&t=88284 I have tried the following service packs for Windows 98 SE (3.65 and 3.66): http://www.techtalk.cc/viewtopic.php?t=65 Windows ME Service Pack 1.05 https://retrosystemsrevival.blogspot.com/2019/05/windows-me-service-pack-102.html Auto-Patcher for Windows 98 https://retrosystemsrevival.blogspot.com/2018/01/auto-patcher-for-windows-98se-december.html I have tried Windows 98 with a stock IE5, IE6SP1, and IE6SP1 with the shell32.dll update: https://msfn.org/board/topic/84451-98-fe-98-sp1-98-se-me-shell32dll-fix/ I tried varying sizes for the swap file, but with sufficient memory (at least 256MB), it apepars that the swap file is never even used (it's never expanded), so the problem seems to lie elsewhere. I have tried replacing himem.sys with HIMEMX. I have tried with and without rloew's memory patch. I have tried varying amounts of physical memory, 32MB, 128MB, 256MB, 512MB, 1.5GB. I have tried large swap sizes and small swap sizes. I have tried varying the amount of vcache, up to 512MB when large amounts of physical memory is installed. I understand that my method to replicate this error is unrealistic, opening and losing Notepad or some other program hundreds of times, but it is simply meant to induce the error with the absolute smallest amount of noise to eliminate the change that it may be caused by something else. In my case, it is triggered VERY often when I use Cygwin, as it spawns lots of child processes that perform some action and then exit. I have been pursuing this issue for weeks and I've finally made some progress. I have a copy of the system in this very state and can provide it in a VM, if there is an expert available to help look into this. Note that the picture below are from a VM with 128MB of memory and do show memory pressure and swap file usage. The video linked above is a VM with 256MB of memory and shows that this error still occurs without the same kind of memory pressure (plenty of swap and physical memory available).

I have this replicated on a fast i945 with a Pentium D or Core 2 running Windows 98 se, an era appropriate i440BX with a Pentium 3 at 650 Mhz and 128MB of ram running Windows ME, and two VMware VMs, one running Windows 98 and the other Windows ME.

I made an error in some research. I'll come back to rewrite this soon.

I have switched from Windows ME to Windows 98 SE and found this issue to still be present. I also tried installing IE6 and then this shell32.dll update, but it did not help with the out of memory error. I also tried installing AIDA64, but my system immediately bluescreens when I run it.

Watching some YouTube on Windows XP in a browser. Works great! I felt that Inception would be appropriate for the occasion.

How about Chrome 102 64-bit? I am cheating a bit, tunneling it over SSH. I'm trying to get something similar working on Windows 98. This is some testing that I've been doing on Windows XP. https://www.vogons.org/viewtopic.php?f=5&t=89122&p=1090683

There are other processes running. I used for term idle in this context to illustrate that I wasn't moving the mouse.

There is no issue with this on Windows 98 when processor usage is at 100%. CPU usage actually increases when the mouse is moved, since it has to send and process WM_MOUSEMOVE messages and possibly others. When the mouse is idle, less CPU activity is present.

I thought about that. There is never a problem with GDI resources.

What makes you think that it's saturated? If this were the case, I would think that the window would become unresponsive. The issue seems to be that the queue isn't being pumped, or is being left idle for some reason due to an overly aggressive optimization gone wrong. I don't know why this is an issue specifically with Windows ME and not Windows 98.

This is kind of an obscure bug that I found today while looking to compare X server performance differences between Windows 98 and Windows ME. What I found was that windows forwarded to my local X server on Windows ME lagged horribly and were unusable. I finally found the problem to be related to the Message Queue processing when I noticed that the progress animation for page loading in a web browser would stop when mouse input was idle. If I moved the mouse randomly around on top of the X window, I could force the queue to process and the loading animation would continue-- until I stopped moving the mouse. I can reproduce this issue most obviously by forwarding glxgears, which periodically reports how many FPS is rendered to the frame buffer. On Windows 98, it would average about 50 FPS, with no change if I were to move my mouse around on the window. But in Windows ME, it would only update at 5 FPS when idle, and upwards of 200 FPS when directly manipulated with the mouse. I don't know if this 200 FPS is correct or some kind of anomaly, as the display output was choppy and inconsistent, with no way to verify this performance metric. I tried installing the Windows ME Service Pack 1.05 to see if it contained a fix, but there was no change in behavior. I don't know what is causing this issue, so I'm having trouble pursuing any meaningful workaround. Is anyone familiar with this issue with message processing in Windows ME or know of a possible workaround?