System fast, but unstable

[docbill]

Since enabling primo cache on my wife's laptop, there have been an abnormal number of application crashes. For the first time ever, when rebooting two days ago Windows ran a check disk on the main drive. Today, for the first time ever the laptop crashed to a blue screen while my wife was doing here facebooking. (Unfortunately she did not capture the error information.)

How do I capture the error information needed to determine if primo cache is truly the cause, and if so how to fix it?

Here system details:

OS: Windows Home 7 Premium 64 bit.

Hardware: MSI G70, 8GB RAM. 750 GB Hard Drive, 120 GB Crucial M4 Msata drive.

Configuration: 128MB Level 1 (read only) cache, 100 GB L2 cache (The 120 GB is formatted into a 100 GB L2 Cache and a 12 GB partition for a windows page file.)

Initially 100% of the msata drive was L2 cache, and the Level 1 cache was read/write. However, yesterday, deactivated primo-cache, repartition the msata drive, and then reactived with the current configuration. (I was hoping changing to read only L1 cache would be more stable, but that does not appear to be the case.)

[minhgi]

You may want to have all the manufacturing drivers up-to-date. Then goes to Intel driver download center and have the drivers up to day as well. most likely your Sata driver is the culprit.

Disable primocache and fix the file system problem first before re-enable it back.

[docbill]

That is the first thing I did even before formatting the drive was grab the appropriate software from the crucial website. The crucial m4 firmware portion was a bit comical. You end-up rebooting to DOS just to find out your firmware is current. But the same program also checks that the drivers are current.

I don't have a clue what I would be hunting for on intel's website... Is there some sort of motherboard driver, or CPU driver you think would be relevant. So I haven't done that step.

Bill

[docbill]

The blue screen crash happened again. The driver it is crashing in is rxfcv.sys. I did a google on that driver and it lead me back to another message in this forum, so it looks like others have also seen this error. BTW. It looks like the L2 cache completely clears itself after the crash, so the computer is dog slow again for awhile. My wife tells me there is also a pop-up ever couple of days about deleting the cache, but it disappears too quickly for her to read it completely. But the pop-up is just shortly before the blue-screen crash.

So strictly as a hypothesis it sounds like primo-cache isn't properly managing the L2 cache, it gets full, and then crashes, rather that simply overwriting the oldest blocks. If that hypothesis is correct then one should be able to make it crash much more frequently simply by reducing the L2 cache size.

Bill

[Cachemaniak]

Do you use deffer write mode ?
I used to get blue-screens while using deffer write 1-2 times daily. I even tried clean Windows 7, turned on Primocache with deffer write and installed SP1. After reboot - system unbootable. Tried the same procedure without deffer write - everything works OK.
Hope this helps.

[docbill]

I believe deffer write mode is turned off. But I'll double check that. I find my wifes hypothesis about the cache filling up and then it crashing a bit unlikely. The reason being is whenever I have looked on her laptop, only a small fraction of the 100 GB was in use.

BTW. The mSata drive problem hypothesis doesn't really work to explain the problem. Even lets say the mSata drive was defective, and just suddenly stopped working. For the crash to happen in the primo-cache driver, indicates the error code is not being treated correctly. What I would expect to happen on a sudden drive failure is for primo-cache to deactivate its level 2 cache and probably pop-up an error, but not a crash. Of course since I also have a page file on the msata now, windows might still crash when it tried to use virtual memory, but that crash would not come from within the primo-cache driver. So far though, I have no evidence of a defective mSata drive.

[Support]

Hi docbill,

rxfcv.sys is the PrimoCache driver. Could you check this link and send us a memory dump file for the blue screen crash error if possible?
http://www.romexsoftware.com/en-us/know ... -file.html

PrimoCache can handle the case when L1/L2 is full. It shall not be the cause of this issue.
Defer-Write may be a cause, you may check if Defer-Write is enabled or not.

Thanks.

[docbill]

I checked and write-deferred is listed as "disabled". She hasn't seen a third blue-screen yet, but I'll enable the option to create the dump file.

Now here is the bigger mystery though. What about primo cache is corrupting the disk? For example, yesterday when she rebooted, afterwards it ran check disk again and fixed a page full of errors. It was a clean reboot, not a crash. Perhaps there was something left over from the previous crash that hadn't been repaired. Or perhaps primo-cache is some how caching causing corruption on the disks it is caching. Either option seems strange as I would not expect a second check disk to find additional errors, and I would not expect primo-cache to corrupt disks, especially when operating in optimize read mode. In fact it seems so bizarre if it wasn't for the fact the crashes happen within the primo-cache I would think her primary hard drive is failing...

In any case, I think the plan at this point is I will wait until she captures a dump file. Then switch her over to use something else, like eboostr until there is an update to primo-cache that might resolve the problem.

Bill

Hi docbill,

rxfcv.sys is the PrimoCache driver. Could you check this link and send us a memory dump file for the blue screen crash error if possible?
http://www.romexsoftware.com/en-us/know ... -file.html

PrimoCache can handle the case when L1/L2 is full. It shall not be the cause of this issue.
Defer-Write may be a cause, you may check if Defer-Write is enabled or not.

Thanks.

[Support]

Hi docbill,

Many thanks!

Theoretically it is safe when defer-write is not enabled. And you're right, it's quite strange that you get a chkdisk activity after a normal reboot. We'll continue checking if there's a bug in reading mode.

[Incriminated]

When shutting down or rebooting you should not "force quit" or "force shutdown" or push power buttons 4 seconds or unplug cable, in this case batterie etc., because primocache has to finish flushing whats in the write-cache for the timeout delay. Defer-write is ok, but please use a rel. short timeout (max few minutes better seconds).

That means for example you have to put auto-shutdown when battery is low to not use force quit.
When running chkdsk, run it with mode to find bad sectors, could take some time, but often corrects NTFS-errors when system appears problematic in some way.
Use actual SATA-Controller driver.

When I review your case, I see a 12GB-Pagefile (having 8GB-RAM ) on the same drive that is used as L2....

The hole Setup seems obscur. Why don't you put the System and Applications due a clean format onto the SSD, then use only L1 for the SSD and the HDD... would be quite better.