Jump to content

z690 vcache protection error

FlameOnion

By FlameOnion
in Windows 9x/ME

 Share

Recommended Posts

  • 8 months later...

FlameOnion

FlameOnion

Posted
  • Author
Posted
On 1/10/2022 at 3:18 PM, FlameOnion said:

Installed softice(I don't know how to use it).Thought maybe it can give some hint or an idea. After I press C to continue, "Vcache protection error" appears

IMG_0888_.jpg

vcache_error_qemu.thumb.png.569e90503d80e34750ffe9eeb03dbcf7.png

Replicated the same error with qemu using OVMF with csm (uefi bios) edk2.git-ovmf-x64-0-20200422.1378.ge54310451f.noarch.rpm

Link to comment
Share on other sites
xrayer

xrayer

Posted
Posted

Hi, any update about this problem? Can we assume it's rather bios related that new cpu/chipset itself? maybe some incompatability introduced in new uefi csm module? did someone tried biosmod to downgrade specific csm module to isolate the problem?

Link to comment
Share on other sites
  • 4 months later...
FlameOnion

FlameOnion

Posted
  • Author
Posted
On 6/15/2023 at 3:27 PM, xrayer said:

Hi, any update about this problem? Can we assume it's rather bios related that new cpu/chipset itself? maybe some incompatability introduced in new uefi csm module? did someone tried biosmod to downgrade specific csm module to isolate the problem?

 

1
Link to comment
Share on other sites
defuser

defuser

Posted
Posted

I have such a question: there in the source it says - " noticed that the cause of the page fault was a write to a non-writeable page while executing in ring 0.". What does it mean? Under "normal conditions", it should have made this recording successfully? What is this entry, how important is it, and what does it affect? Is it possible, instead of eliminating the symptoms, to allow the necessary recording to be performed (If my assumption is correct), by removing write protection to this location? What can be the concomitant consequences of the fact that this record cannot be executed? Even if my concerns are unfounded, I would still like to see a more detailed explanation - what and where it wants to write down, why it can't do it, and what indirect consequences it may have. For clarity, let's say if we take a computer based on 440BX or similar, fully 9x compatible, does this recording succeed there?

Link to comment
Share on other sites
SweetLow

SweetLow

Posted
Posted
19 minutes ago, defuser said:

For clarity, let's say if we take a computer based on 440BX or similar, fully 9x compatible, does this recording succeed there?

Yes. With this flag cleared kernel mode code is ignoring the fact that page is read-only and writes on this page successfully.

1
Link to comment
Share on other sites
defuser

defuser

Posted
Posted

So everything is more or less clear. That is, with this option, the ability to write is saved and thus it works correctly. Questions are removed (This was not entirely obvious to me from the description). Thank you for this valuable clarification.

Link to comment
Share on other sites
pangoomis

pangoomis

Posted
Posted (edited)

It is working! 
CREGFIX, HIMEMX, PATCHMEM, AHCI Driver (with patcher9x), GeForce 7900 GTX, Delock 89135 USB 2.0 PCI-E x1 card with USB Mouse and USB Audio Card attached.
No LAN - too new, no DOS/NDIS2 drivers available.
Rebooting doesn't work but Shutdown -> Ctrl+Alt+Del works equally well.
Need to run using WIN, rather than automatically, otherwise every second boot fails on AHCI.PDR, weird...

VCa7FHY.png

gGLRhw3.jpg

 

Edited by MrMateczko
1
Link to comment
Share on other sites
Omores

Omores

Posted
Posted (edited)
On 11/3/2023 at 10:28 PM, MrMateczko said:

This is huge news!

I will definitely try this with my i3-12100F, 7900 GTX and the PRO H610M-B DDR4.

@Omoresmaybe you should see this :P

 

Yes, it works with a 13th gen CPU too! Most likely everything will be fine with a 14th gen CPU as well. (I already use a 09/2023 BIOS compatible with 14th gen) Didn't use the AHCI patch. Everything is rock stable, no kidding. This H610 mobo has a classic PCI slot filled  with a Creative SB Live! There is also a PCIE to PCI adapter for a NEC PCI to USB. I will install some USB Wifi dongle.

Funny thing is that Windows 3.11 is working perfectly fine on this configuration with the included himem.sys and no is fix required.

***A few days ago I was trying to find a solution for this problem and I observed that on a 9th gen compatible motherboard (H310) the XMS was reported as ~3.4GB - but on this H610 socket 1700 mobo it was only ~1.9GB. Also on my Ryzen 3900X configuration - after the BIOS update which gave VCACHE error - the amount of XMS reported decreased from 3.4GB to 3GB... There is a SETXMSTO.EXE tool which overrides the amount of RAM reported to DOS. So I used this tool to set the RAM back ~3.4GB and there was no VCACHE error anymore but I ended up with a Microsoft Registry Checker loop which is also caused by corrupt RAM. :)

Windows98_Intel13thgen_CREGFIX.png

registry_checker_socket_1700.jpg

Edited by Omores
1
Link to comment
Share on other sites
  • 2 weeks later...
Omores

Omores

Posted
Posted (edited)

For those who are interested in more technical details about the VCACHE error, here is a comment from mintsuki, the author of cregfix.

This is a reply on a Youtube video about Windows Millennium and probably won't get much exposure there.
  

@myne00 2 days ago

If I'm reading the 'how it works' correctly, it's a bug with the compatibility support module of the UEFI setting pages as readonly.

This clears them. Wonder if AMI will release a fix?

@mintsuki1 1 day ago

„Close. It's about a control of the CPU that says whether kernel code should or shouldn't cause page faults when writing to read only pages. Originally the x86 did not have such control and no kind of kernel write to read only pages would cause any fault; around the 486 era (if I am not mistaken) they realised this was stupid and there was a need and use case for the kernel to be able to cause page faults of its own on non-writeable pages (think swapping to disk and other virtual memory related features). So they added this "feature" in, but since x86 is all about backwards compatibility, the feature, like many others, is gated behind a control bit in the CR0 control register (namely CR0.WP). Obviously it does no good for compatibility if the bit is enabled by default, as we can see in this case. Many modern UEFI firmwares enable the bit, as do many modern OSes, but then fail to clear it when handing off control to a legacy boot sector using CSM. Probably no one ever caught this; but also you have to keep in mind that legacy BIOS does not really have a specification and therefore it says nothing about the state that control registers should be in at handoff, other than common sense. So should this be fixed by the UEFI firmware vendors? Yes, imho. Do they even consider this to be a bug? Hard to tell. And plus cregfix.com will still be useful since one cannot expect all UEFI vendors and motherboard manufacturers to actually ship fixed firmwares, especially for older models... And speaking of older models, I'd like to point out that I have been chasing this issue for about 5-8 years before finally figuring out the root cause, also thanks to trannks (the person I originally emailed about their posts) making me realise it could be reproduced in QEMU with an OVMF/CSM firmware. From what I can track down it started happening with Skylake systems, so around ~2015; but obviously that's when it became widespread and I don't exclude systems having the same issue before that point.”

Edited by Omores
Link to comment
Share on other sites
  • 2 weeks later...

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
 Share
Go to topic listing

  • Recently Browsing   0 members

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