Can't boot two machines after windows updates

[Leesamn]

I rebuilt two machines from scratch last night and had some issues. Here's the config of each:
PC1
AMD FX 8320E Vishera
8gb ram
4 Disks in RAID 10 (1.2TB) on MSI 970A-G46 AMD 970 / AMD SB950 Chipset
1 Samsung SSD (120GB)

PC2
AMD Phenom II X4 955BE
8GB ram
2 Disk in RAID 1 (1TB) on MSI 790FX-GD70 AMD 790FX / AMD SB750 Chipset
1 ADATA SSD (32gb)

What i did:
-Wipe disks
-Install Win 7 Pro x64
-Install Drivers
-Install 160+ windows updates
-Install PrimoCache and configure SSD to act as Layer 2 cache using the max space available (this formats the SSD again). Create caching task also using 512MB ram as Layer 1 cache

After PrimoCache was up and running happily i did a check for updates one more time on both machines. Each had about 25 more updates to install. I installed the 25 updates and rebooted on both machines.

After the last batch of 25 updates neither machine will boot into Win 7.

I tried booting off the install disk, loading raid drivers and running startup recovery but bootrec.exe /scanos finds 0 windows installations. If i open up task manager and go to new task i can browse to the windows installation on the root array. I don't know what prevents bootrec from finding it.

Not sure where to go next in the troubleshooting, i'm pretty sure if i wiped both machines and started over again i'd get the same result because i saw the same behavior on two different machines.

[Bjameson]

I do not speak for Romex but perhaps I can be of assistance. There appears to be some overlap with supercilious' problem. Both of you refer to "Raid" and "Updates" in the same context. That can hardly be a coincidence.

Although it's a lot of work, you might be willing to try a few different PrimoCache settings. Roughly repeat the same procedure you already did twice. The following is only one of many possible ways to pinpoint the problem by tuning PrimoCache.

- The first step, if successful, makes any further steps superfluous. First repeat your entire procedure with the same PrimoCache settings, but this time set L1's Write Delay to Off. Working fine? No further testing is needed, PrimoCache's Delayed Write mechanism appears to have a problem with RAID, since similar setups with non-RAID work fine.

If you again have trouble, you could try figuring out the problem in more detail.

- Try with only L1, Delayed Write off. No L2.
- Again with only L1, Write Delay on. No L2.
- Again with only L2, no L1.

If it fails at any step, you have pinpointed the culprit and it's up to Romex to fix it. It could well be that there is interaction between L1 and L2, wich makes it even harder to figure out what's going on. At any point you may think you have found a workaround, only to be disappointed later on. So structured testing is the only way forward.

[supercilious]

For the record, there is no RAID nor anything resembling an exotic IO subsystem, just WTG supported USB drives (as the Windows-to-Go guidelines suggest).

The corruption occurs reliably when installing the initial Windows 8.1 updates because I believe that some aspect of the update process bypasses the cache (causing a undetected stale cache) or the cache write-back times-out due to its sheer size at reboot (causing an lost writes). There is no error or other useful diagnostic information in the event log.

[supercilious]

(This should have been in the previous comment, but I posted it accidentally trying to preview; Sorry.)

As for diagnosing it, all one needs is Windows 8.1 Enterprise x64 and a Sandisk Cruzer Extreme USB 3 flash drive (min 32GB). The error can then be reproduced on any machine with more than 16GB of RAM (perhaps less if you use a USB 2 port).

I only tested the write-cache aspect of the performance with delayed writes turned on. I have no interest or desire to use any other combination of options, as I am simply trying to ameliorate the performance issues inherent in writing to a slow USB drive (reads are already adequately fast). I have never used the L2 caches, nor any other setting such as read or read+write.

[Leesamn]

I tried again last night on both machines and also noticed i had previously checked to include the 100mb System Reserved partition in the cache task. AFAIK that partition is a boot partition required if you'll be using bitlocker encryption on the whole drive. I believe i was thinking that if it was available to be included perhaps it would help with speeding up boot times.

I setup the task without the write delay checked off and also without the system reserved partition included in the task. Both machines are now working great. I'm not sure which option fixed it and it may be some time until i can test it again to find that out.

[Leesamn]

I'd also like to note that the layer 1 cache exposes ram issues VERY quickly. One of the two machines needed a slightly higher voltage on an older stick of ram and i was getting BSODs very often until i got it upped the correct amount.

[supercilious]

Since you had hardware errors, it seems inappropriate to blame any issues on software, so in your case at least, the RAM is solely to blame.

There is no question of hardware error in my case however, and the bug still exists and manifested in some Windows-to-Go workspaces I created last Friday. I am currently investigating alternatives like supercache (http://www.superspeed.com/desktop/supercache.php) and so far at least, it works flawlessly on a single machine, but the licensing mechanism causes problems when the drive is booted on different hardware.

So it seems for now, I am resigned to living without a writeback cache.

[Davey126]

Disappointing Romex has not addressed the potential for timeouts on large writebacks to slow media. That said, you could probably use a smaller L1 cache and receive at least some of the benefit. Believe you mentioned a 16GB L1 cache another post. Perhaps drop that to 4GB and see what happens. Not ideal if you have surplus memory but better than zero.

[supercilious]

While I am sure it would work OK with a smaller cache, it does not inspire confidence in the software for bugs such as these to go unfixed for months at a time. As I stated earlier (in another thread), I am reluctant to trust any valuable data to PrimoCache until such time as these bugs are fixed.

[Davey126]

Understandable, especially given the lack of recent updates and the significant problem that you encountered. That said, many participants in these forums have used PrimoCache (and its predecessor FancyCache) extensively without incident. The L1 cache performs admirably with modest parameters; the L2 cache seems more problematic.

Not sure I would deploy in a production environment or on any system where a 'crash' or data loss would be unrecoverable. I have purchased a license for my own use (and don't regret it) but have yet to engage my clients for the same reasons you articulated.