Jump to content

z690 vcache protection error


FlameOnion

Recommended Posts

Is there a way to debug this? a way to trace and exclude memory with emm?

On h87  with an i5 it worked(vdd protection error fixed by removing the 1060, and using igpu or ati x600).On z690 it does not work.I don't reach vdd protection error( I get vcache protection error).I can reach vdd protection error and pass it(with ati x600) if I boot with step by step and don't load ifshlp.vxd, but later I get blue screen vfat error
 

with normal boot, safe mode, ends at "[00142D3F] DEVICEINIT   = VCACHE"

(I have 32gb ram, removed 1 stick and it was the same.Saw a video with a russian getting the same vcache protection error on z390, he then used an adapter and 2gb ddr4 sodimm and it was the same)

 

Link to comment
Share on other sites


There still could be too much RAM, did you do this; from rLoew's comments.

"If you have more than 2.75GB of available RAM in your Computer, Programs that
use XMS Memory may exhaust the default supply of Handles offered by HIMEM.SYS.
Add the following line to your CONFIG.SYS file before any program that might
use XMS Memory to prevent this problem:

DEVICE=<path>\HIMEM.SYS /NUMHANDLES=64"

I do not know otherwise except that the hardware accesses RAM differently as technology has evolved: - controlled by hardware so should be OK.

Edited by Goodmaneuver
Link to comment
Share on other sites

9 hours ago, Goodmaneuver said:

There still could be too much RAM, did you do this; from rLoew's comments.

"If you have more than 2.75GB of available RAM in your Computer, Programs that
use XMS Memory may exhaust the default supply of Handles offered by HIMEM.SYS.
Add the following line to your CONFIG.SYS file before any program that might
use XMS Memory to prevent this problem:

DEVICE=<path>\HIMEM.SYS /NUMHANDLES=64"

I do not know otherwise except that the hardware accesses RAM differently as technology has evolved: - controlled by hardware so should be OK.

Tried Xmgr.sys, HIMEM.SYS /NUMHANDLES=64, HIMEMX.EXE , HIMEMX.EXE /NOABOVE16 /X /X2MAX32, it is the same.

Link to comment
Share on other sites

If you are using Win98 have you tried limited memory access to 1GB by adding MaxPhysPage=40000 in system.ini and under [vcache] in system.ini have you tried limiting vcache to say MaxFileCache=344064. In case the expanded memory has got something to do with it then you could try SysVMEMSLimit=2048. see http://conradshome.com/win31/83435-6.php I would try a smaller RAM stick, one that is the same size or smaller than the h87 total equivalency if you can.

Edited by Goodmaneuver
Link to comment
Share on other sites

1 hour ago, Goodmaneuver said:

If you are using Win98 have you tried limited memory access to 1GB by adding MaxPhysPage=40000 in system.ini and under [vcache] in system.ini have you tried limiting vcache to say MaxFileCache=344064. In case the expanded memory has got something to do with it then you could try SysVMEMSLimit=2048. see http://conradshome.com/win31/83435-6.php I would try a smaller RAM stick, one that is the same size or smaller than the h87 total equivalency if you can.

Tried with 16gb(same as h87) and it was the same.
With DEVICE=HIMEMX.EXE /MAX=64M, 

[386Enh]
SysVMEMSLimit=2048
MaxPhysPage=40000

[vcache]
MaxFileCache=344064

same


 

mem(dos7.1 version) DEVICE=HIMEMX.EXE /MAX=64M


Memory Type         Total  =   Used   +   Free
----------------  --------   --------   --------
Conventional          624K        59K       565K
Upper                   0K         0K         0K
Reserved                0K         0K         0K
Extended (XMS)     65,535K         3K    65,532K
----------------  --------   --------   --------
Total memory       66,159K        62K    66,097K

Total under 1Mb       624K        59K       565K

Total Extended (XMS)                 65,535K  (67,107,840 bytes)
Free Extended (XMS)                  65,532K  (67,104,768 bytes)

Largest executable program size         565K     (578,288 bytes)
Largest free upper memory block           0K           (0 bytes)
Available space in High Memory Area       1K         (608 bytes)
MS-DOS is resident in the high memory area.
 

Link to comment
Share on other sites

Try disabling the Efficient-cores in UEFI if possible.
Do you have the rloew's RAM Patch installed?
Make sure the partition you install Win98 to is at the beginning of the hard drive and less than 137GB to avoid problems regarding partitions.


You are the first person I see to try Win98 on the new Intel hybrid platform, brave! :) 

Link to comment
Share on other sites

and i personally have such problem with Intel Core i7-10700 on Gigabyte B460M DS3H.

It is not memory size (and map), processor speed or specific hardware drivers related. And reproduced on any version of VCACHE from 95 to ME.

Link to comment
Share on other sites

If you are keen you could buy an add on card like a SCSI card. Once the HDD is formatted and OS files are on the SCSI HDD them the SCSI card runs from BIOS so really does not need drivers for the OS. File system restraints still apply. The other alternative is if it can boot to USB but this could be tricky but I bought a USB2 card that worked without drivers installed as at first the bios controls it I estimate. It would be easy to test if boot to USB was a function in BIOS as just get a USB external disk or memory stick with the OS on it and see what happens. The vcache is within VMM32 or external with rLoew's I think but if looking at previous load and is taking file system I would say that the error would say cannot install the next item. See if Boot Logging is writing to the HDD.

Link to comment
Share on other sites

disabled cores, downclocked to 2ghz, downclocked ram and increased timings, disabled lan, sound, sata controller, tpm, used less than 2gb partition fat, fat32, same.
Booted from usb, same(on h87 it worked booting from sata and usb stick)

Bootlog works. It stops at "[000EB590] DEVICEINIT   = VCACHE  "

Edited by FlameOnion
Link to comment
Share on other sites

Doesn't hurt to try ConservativeSwapfileUsage=1.

Seems like the issue is in the VCACHE.VXD file itself...but we don't know what the issue is with it :} 
Didn't encounter this issue myself when I had H110 and B450 motherboards.
An interesting experiment would be to remove VCACHE.VXD from VMM32.VXD and see what happens :ph34r:

Link to comment
Share on other sites

On 12/13/2021 at 3:06 AM, FlameOnion said:

Booted from usb,

The way I see it is that it works on USB so there is not problem with vcache. There are no access timing settings for SATA as FlameOnion would have said I think. To check, select the HDD itself in BIOS and there might/should be a Multi-Sector Transfer option, A PIO Mode, DMA mode, Smart Monitoring and a 32bit Data Transfer option. I usually select PIO Mode either 0 or 1 and DMA SWDMA0 or up to MWDMA2. I select the lowest first and then you can test drive speed later. Even on the lowest settings the HDD can be going flat out and will not go any faster. The actual HDD speed capability with the settings is determined with the BIOS and it is not a universal standard. Speeds can be tested on another OS. The SATA is driven off the PCI I would think and devices like USB are also driven from PCI. They quite often are jostling each other for bandwidth and PCI bus has to be in excellent condition for 16bit drivers it seems. If this board is new then perhaps exercise it with a different OS first. Do not push the HDD any faster than it can go as the time to get data to and fro will get shorter with higher speed settings and not recommended to run with the BIOS test setting it chose, but every BIOS is different. FlameOnion disabled as many devices as possible before testing on USB so they did the right thing there.

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...