Reply 20 of 26, by Kahenraz
- Rank
- l33t
Kahenraz wrote on 2022-07-31, 15:09:Yes, I never disable virtual memory. I have tried both with allowing Windows to manage memory for me and by specifying the page […]
Yes, I never disable virtual memory. I have tried both with allowing Windows to manage memory for me and by specifying the page file, either growing or of a fixed size. The issue doesn't appear to involve swap file usage at all, because when there is sufficient physical memory available, the swap file is never used (it doesn't grow).
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 can reproduce this problem on a fresh install on real hardware or a VM after a clean reboot simply by opening and closing Notepad repeatedly, until errors start to appear. Cygwin also triggers the symptoms, but there is some kind of underlying problem within Windows itself that is the root cause.
