defuser

Yes, it is stable and reproduces for me, if you move the paging file (WIN386.SWP) to "RAMDISK64". Only I don't have a blue screen, but a black one and only the white wand flashes. And in order to continue, you need to double-click any button on the keyboard, after which the exit/restart procedure continues as usual. At the same time, the keyboard must be connected to the PS/2, or to a USB port managed by the CSM. Since reinitialization of the USB controller after the WINDOWS driver occurs at the DOSSTART.BAT processing stage (But not before), and this is one of the subsequent stages. The need to press a key occurs precisely at the most inconvenient moment when the WINDOWS driver has been successfully unloaded and no LONGER works, and the CSM BIOS driver has STILL not turned on and re-activated the USB. Therefore, I had to refrain from the beautiful idea of "Paging file in x64 RAM" at the moment (This role is not so bad performed by SSD). Although the idea itself is quite attractive (In everything else), I tested it and, in addition to the obvious speed advantage, it can also save the SSD from unnecessary procedures for overwriting the drive cells (Which is also quite useful for SSDs and other solid-state media). In general, you need some kind of workaround that automates the keystroke procedure (especially for new systems without PS/2 support), both when you exit Windows and during a hot reboot (SHIFT+Restart). Or a fundamental bug fix (this doesn't happen with regular disks). Well, or the third possible solution is to find a way to initialize the "Legacy USB" at a slightly earlier stage, so that the USB keyboard would ALREADY work at the time of this error (Unloading the WINDOWS driver and IMMEDIATELY after this initialization of the CSM USB). But how to do this, so far there are no ideas. And yes, the problem is clearly beyond the scope of "RAMDRV4M", but it is also impossible not to mention this separately here.

Yes. It worked! Thanks for the tip. I used a tiny program "BAT2EXEC", from here: http://web.archive.org/web/20060512120615/http://ftp.sunet.se/pub/simtelnet/msdos/batchutl/bat2ex15.zip Mention of this wonderful program was found there: https://www.mdgx.com/newtip14.htm Combined in one BAT file a call to the original "WININIT.EXE" + "UserProg.EXE" (following it) and converted using "BAT2EXEC" to a single file, giving it the name "WININI1.EXE". Corrected and "WIN.COM" (What would be the new one "WININI1.EXE" called instead of the original one "WININIT.EXE"). As a result of all these actions, during a hot reboot, if "WININIT.INI" is found in the folder "C:\WINDOWS" - then run first "WININI1.EXE", which first calls the genuine original "WININIT.EXE" and he works out as usual, and after him immediately enters the game already and "UserProg.EXE", producing useful action. Not exactly a perfect design, but at least that's how it works. So now, as they say, both hares are whole and wolves are full I will generally observe. I hope that everything will work correctly from now on. PS: Yes, you're probably right. But for some reason, Google sent me here with my question (And I thought that maybe we should not duplicate discussions that were previously created by other participants, but instead supplement existing ones?). But if this is somehow not good - then okay, it's not difficult for me to create a new topic next time.

Is it possible to execute a user script or EXE file during a hot reboot? This is when the usual "Restart" is selected in the menu, while holding down the "SHIFT" key (Sometimes the OS itself also chooses this simplified method of rebooting). I always assumed that "DOSSTART.BAT" is also processed there (just like when exiting in DOS), but it turned out that it is not. Called only "WININIT.EXE", and then only if "WININIT.INI" exists next to it (you need to create it again each time). However, I didn't find any convenient way to call the EXE file from "WININIT.INI". The rough approach is to replace "WININIT.EXE" to any other EXE that needs to be executed by giving it this name and placing "WININIT.INI" next to it. And this method works. However, this also loses useful functionality (necessary for the system to work properly, as well as for installed programs and drivers). Maybe there is some more elegant way to execute the necessary code (BAT or EXE) during a hot reboot (But only necessarily at an early stage, before starting the WINDOWS kernel and GUI)? Thank you.

Yes, the problem was related to MTRR and now everything is fine:

Greetings. I noticed a feature that is observed when checking the RAMDRIVE surface: Checking up to 1000 (approximately) clusters is very fast, from ~1000 to ~2100 very slow, and then after ~2100 to ~3200 again very fast! RAMDISK is now at 12.5 GB and in this test the ramdisk is completely empty.

Yes, all three are working now: keyboard, mouse and flash drive.

Result: http://sweetlow.orgfree.com/download/usb20_win9x.zip - from cold start - it works fine - after exiting to DOS - it doesn't work - after returning to WINDOWS (with the EXIT command) - it works fine http://sweetlow.orgfree.com/download/usbehci.zip - from cold start - it works fine - after exiting to DOS - it doesn't work - after returning to WINDOWS (with the EXIT command) - does not work But there is good news. I found a workaround to enable the mouse (The keyboard is connected to the second port managed by CSM and it works correctly everywhere and always). And so, after the first cold boot in DOS, I saved PCI registers for the USB controller on which the mouse is installed (USB1_GOOD.TXT): And then, booted into WINDOWS. Exit to DOS. The mouse immediately went out (Stopped working). Then I ran RU.EXE and I applied all these data (Which are given above) and the mouse immediately lit up (Earned). This means that the mouse and keyboard just need to be initialized automatically after exiting to DOS via DOSSTART.BAT. And the problem will be completely solved. Content "USB1_BAD.TXT": By the way, when the controller is running, these digits "0D 15 0F 1D" are constantly changing. And when the controller does not work, they freeze and stand still (DB 05 D6 1F). After applying data from "USB1_GOOD.TXT" these numbers come to life again and start moving. Mouse working!

This is a very good, stable EHCI driver. I use it for a long time, there are no complaints (serious). Moreover, it turned out to be useful not only for Windows 98, but also helped to solve the problem of "jumping" or halving the frequency of USB port polling in Windows XP (USBEHCI.SYS) on one of the problematic configurations. My only wish is to improve support for real DOS mode as much as possible. Now, after exit to DOS, the keyboard and mouse connected to the EHCI controller that this driver is installed on in Windows 98 do not work. And in order to continue working (type something on the keyboard), you now need to switch the keyboard to the second USB controller, which is controlled by CSM (only a dummy driver is installed on it). And after exiting DOS (Returning to WINDOWS with the "EXIT" command), the driver works as if nothing had happened. That is, it is not correctly unloaded (It does not transfer control back to the CSM BIOS). And this is the only small (Since there is a working workaround), but still very desirable improvement at the moment. Otherwise, everything works very smoothly (Other options I tried either did not work at all, or worked very crookedly, or required pulling the system floor from Windows ME). And this is the most compact and versatile option that does not require making deep changes to the original Windows 98.

I'm focusing on choosing the right hardware for the new configuration, and I came to ask if there is a solution to this problem. The choice depends on it. If there is a solution, then it will be one piece of hardware (later). And if there is no solution, then it will be a completely different hardware (earlier). Such things you want to know in advance, so as not to make a mistake and make the right choice.

On the current hardware (Without VCACHE error) - loaded successfully. For reliability, it would be necessary to check this on the problem hardware (Which is subject to this error), but I don't have it at hand at the moment.

Checked it out. If you run this CREGFIX.SYS after EMM386.EXE in CONFIG.SYS - the above error occurs. But if you put it BEFORE it, there is no such error.

CREGFIX.COM + EMM386.EXE = "Unrecoverable privileged operation error - press Enter to reboot." Is there any workaround? EMM386.EXE a very useful technology that helps you run some software under Windows 98 that requires UMB + EMS and, of course, I would not like to completely abandon it.

Thank you, it helped to find the reason in the right place! I went to the device manager to see the addresses of devices that are located in this region and found there a safely forgotten previously reserved address left over from the previous configuration, where with the old BIOS design of the video card (Before the BIOS patch), it did not interfere with anything (Like other 128\256MB video cards). And now, at 512MB, apparently-this piece is also captured. And this actually prevented the driver from loading, no matter how hard I tried and what measures I did not take... I removed this entry and everything loaded immediately. Well, the actual results: It was: Become: And one more not big, but nice enough, bonus (Was=>Became): Well, the most basic thing that was expected from the BIOS patch, for which all this was originally started - exiting DOS back to Windows 98 (Re-booting Windows) - now works again. The patched (Problematic in this regard) NVCORE.VxD was replaced with the original one. And also the oddity (With the absence of WC working by default) on PCI-E hardware under 9x in NVIDIA drivers is also in all its glory: Originally it was (By default): After pre-configuring MTRR under DOS and then applying MTRR_LEN under WINDOWS:

Vendor 10DEh NVIDIA Corporation Device 009Dh G70GL [Quadro FX 4500] Command 0007h (I/O Access, Memory Access, BusMaster) Status 0010h (Has Capabilities List, Fast Timing) Revision A1h, Header Type 00h, Bus Latency Timer 00h Self test 00h (Self test not supported) Cache line size 64 Bytes (16 DWords) PCI Class Display, type VGA Subsystem ID 032210DEh Unknown Subsystem Vendor 10DEh NVIDIA Corporation Address 0 is a Memory Address (anywhere in 0-4Gb) : F6000000h Address 1 is a Memory Address (anywhere in 64-bit space, Prefetchable) : C0000000h Address 3 is a Memory Address (anywhere in 64-bit space) : F5000000h Address 5 is an I/O Port : 0000E000h System IRQ 11, INT# A Expansion ROM of 0Kb decoded by this card (Currently disabled) New Capabilities List Present: Power Management Capability, Version 1.1 Does not support low power State D1 or D2 Does not support PME# signalling Current Power State : D0 (Device operational, no power saving) Message Signalled Interrupt Capability MSI is disabled MSI function can generate 64-bit addresses PCI Express Capability, Version 1 Device/Port Type : PCI Express Endpoint Device Unsupported Request Severity is Non-Fatal Non-Fatal Error Detected Unsupported Request Detected Maximum Link speed : 2.5Gb/s Maximum Link Width : x16 Link Port Number : 0 Common Clock Configuration In Use Current Link speed : 2.5Gb/s Current Link Width : x8 Conventional Memory: INT 12h Memory below 1M: 635 KB (00000000 - 0009EC00 : 0009EC00) Extended Memory: INT 15h, AH=88h Memory above 1M: 0 KB INT 15h, AX=E801h Free between 1M and 16M: 0 KB Free above 16M: 0 KB Configured between 1M and 16M: 15360 KB (00100000 - 01000000 : 00F00000) Configured above 16M: 2812928 KB (01000000 - ACB00000 : ABB00000) INT 15h, EAX=0000E820h 0000000000000000 - 000000000009EC00 : 000000000009EC00 1 (Available) 000000000009EC00 - 00000000000A0000 : 0000000000001400 2 (Reserved) 00000000000E0000 - 0000000000100000 : 0000000000020000 2 (Reserved) 0000000000100000 - 0000000020000000 : 000000001FF00000 1 (Available) 0000000020000000 - 00000000ACBF9000 : 000000008CBF9000 2 (Reserved) 00000000ACBF9000 - 00000000ACC00000 : 0000000000007000 4 (ACPI NVS) 00000000ACC00000 - 00000000AD6B2000 : 0000000000AB2000 2 (Reserved) 00000000AD6B2000 - 00000000AD95C000 : 00000000002AA000 2 (Reserved) 00000000AD95C000 - 00000000BD038000 : 000000000F6DC000 2 (Reserved) 00000000BD038000 - 00000000BE024000 : 0000000000FEC000 2 (Reserved) 00000000BE024000 - 00000000BE038000 : 0000000000014000 3 (ACPI Reclaim) 00000000BE038000 - 00000000BE18B000 : 0000000000153000 4 (ACPI NVS) 00000000BE18B000 - 00000000BF7FF000 : 0000000001674000 2 (Reserved) 00000000BF7FF000 - 00000000BF800000 : 0000000000001000 2 (Reserved) 00000000F8000000 - 00000000FC000000 : 0000000004000000 2 (Reserved) 00000000FEC00000 - 00000000FEC01000 : 0000000000001000 2 (Reserved) 00000000FED00000 - 00000000FED04000 : 0000000000004000 2 (Reserved) 00000000FED1C000 - 00000000FED20000 : 0000000000004000 2 (Reserved) 00000000FEE00000 - 00000000FEE01000 : 0000000000001000 2 (Reserved) 00000000FF000000 - 0000000100000000 : 0000000001000000 2 (Reserved) 0000000100000000 - 000000023E000000 : 000000013E000000 1 (Available) Available: Bytes KiB MiB GiB TiB Below 4GiB: 536472576 523899 511.6 0.5 0.0 Above 4GiB: 5335154688 5210112 5088.0 5.0 0.0 Total: 5871627264 5734011 5599.6 5.5 0.0

In general, I flashed this patched BIOS and after that it booted up immediately in XP without any problems, the memory in the system became 512MB less. But in Windows 98, it loaded only in 640x480@16 colors. In Device Manager, it says "This device cannot find any free Memory Range resources to use (Code 12.)". And if you set resources manually in safe mode, it already writes the following "This device is either not present, not working properly, or does not have all the drivers installed. (Code 24.)". Then I updated the driver to version 82.69 and now it always writes " Protection Error. You need to restart your computer". What I've already tried: - add SPLIT8MB in AUTOEXEC.BAT - limit memory to a safe 2GB (as well as up to 512MB) - apply PATCHMEM /A /C: 128 / M /P - delete EMM386.EXE - register EMMExclude=A000-FFFF in SYSTEM.INI Technical information: NVIDIA Quadro FX 4500 [DISPLAY] ** DEVICE: PCI\VEN_10DE&DEV_009D&SUBSYS_032210DE&REV_A1\000800 ** DRIVER: DISPLAY\0001 ** MFG: NVIDIA ** HARDWAREID: PCI\VEN_10DE&DEV_009D&SUBSYS_032210DE&REV_A1 PCI\VEN_10DE&DEV_009D&SUBSYS_032210DE PCI\VEN_10DE&DEV_009D&REV_A1&CC_0300 PCI\VEN_10DE&DEV_009D&CC_030000 PCI\VEN_10DE&DEV_009D&CC_0300 ** COMPATIBLEIDS: PCI\VEN_10DE&DEV_009D&REV_A1 PCI\VEN_10DE&DEV_009D PCI\VEN_10DE&CC_030000 PCI\VEN_10DE&CC_0300 PCI\VEN_10DE PCI\CC_030000 PCI\CC_0300 ** Registry.MatchingDeviceId: PCI\VEN_10DE&DEV_009D ** Registry.Inf: NVAGP.INF:[NV30] ** CLASSGUID: {4d36e968-e325-11ce-bfc1-08002be10318} ** CLASS: DISPLAY ** CAPABILITIES: 00000014 ** Registry.ProviderName: NVIDIA ** Registry.DriverDate: 5-28-2023 ** Registry.DevLoader: *vdd ** Devnode Status: 18006EA6 ** Problem: Devnode Problem = 0000000Ch (NORMAL_CONFLICT) ** Tree Level: 3 MTRRcap Register: 000000FE 0000000000000D0A Variable MTRR Count: 10 Fixed MTRR Supported: TRUE Write-combining (WC) Memory Type Supported: TRUE SMM Memory Range Registers (SMRR) Supported: TRUE MTRRdefType Register: 000002FF 0000000000000C00 Default Cache Type: 00h Uncacheable MTRR Enabled: TRUE Fixed MTRR Enabled: TRUE Reported Processor Physical Address Size (bits): 39 Variable MTRRs - Base, Mask and Decription: 00000200 0000000000000006 0000007E00000800 8G @ 0 / WB 00000202 0000000200000006 0000007FE0000800 512M @ 8G / WB 00000204 0000000220000006 0000007FF0000800 256M @ 8G 512M / WB 00000206 0000000230000006 0000007FF8000800 128M @ 8G 768M / WB 00000208 0000000238000006 0000007FFC000800 64M @ 8G 896M / WB 0000020A 000000023C000006 0000007FFE000800 32M @ 8G 960M / WB 0000020C 00000000C0000000 0000007FC0000800 1G @ 3G / UC 0000020E 0000000000000000 0000000000000000 Not used 00000210 0000000000000000 0000000000000000 Not used 00000212 0000000000000000 0000000000000000 Not used Has anyone ever encountered something like this? While I would not like to roll back the BIOS back, but first try to fix everything that is already there. Any ideas?