01-10-2019 11:20 AM - edited 01-11-2019 11:29 AM
After two days of troubleshooting the issue turned out to be the HD C: had become corrupt.
This was confusing because it passed multiple loops of the Bios system testing. So, I must assume that the Bios test is a physical read write test and not a logical test, ie, you can do IO on the drive, but the data (windows OS) was corrupted, otherwise how could the Bios test pass?
The saga started when I put a 450GB SSD in and cloned the HD to to. So after several days running from the SSD I was going to change the boot order to make the SSD the primary drive. But before doing that Windows had updates to do and they were applied to the HD. During the process of restarting for the updates the the BSOD started. At that point I took the SSD out thinking that it was causing problems, but no. As seen below nothing I did would prevent the BSOD on startup. So as a last resort I put the SSD back in and WHAM! it could boot from the SSD. Then looking into the Windows event log it appears that the HD had been repairing it self 8 or so times over the prior 5 days or so. I did manage to see it go briefly to a DOS black screen with a 'repairing' message once during the final windows updates, but assumed it was the new SSD.
Subsequently, to simply the HD/SSD drives I removed the a 32GB Lite-on SSD RAID (controlled by RST) cache that the laptop came with and now am running off of the 450GB SSD in nonRAID mode.
The original HD was operating okay but it appeared as an 'unknown' drive. I was able to clone the SSD to that HD and did a DSKCHK on it and it appears to be okay. I'll replace it with a new drive eventually.
Moral of the story. The Bios diagnotic disk check could not determine that the disk was toast as far as the data content, and that lead me down the path of thinking it was the 30G of lite-on cache which had become corrupted (as my best guess), but it wasn't. The HD just wasn't logically readable as an OS.
Hello - Just looking for advice after spending two days on this.
A zbook 17 mobile workstation (initial model D5D93AV) will not boot.
All of the attempts listed below have failed.
However, I found a post with a potential solution, however I don't know exactly what the post is saying.
I would like to share with you how the issue was finally solved.
The root cause was a failure in the smart hard drive used as a cache to start quicker.
Even though all the HP tests were run successfully, the Hp support team recommended me to deactivate and unplugged it.
They had performed that action and now everything works fine and but the initialization is a little bit slower.
Thanks again for all your support
Hopefully, it helps someone else too.
So, I left wondering what was deactivated and unplugged?
1) BiosHP Recovery - Tries but can't load windows - Get BSOD indicating iastorA.sys after 15 seconds.
2) Boot from a cloned image of the HD C: (windows) - The workstation cannot recognize the USB attached HD.
3) Windows Media Creation - Loaded Win Media Creation for Win 10 on Samsun 64GB usb stick - The error is Page fault in NonPaged area - iaStorAVC.sys is the named driver.
4) Ran all system Test with no errors thru 3 interations for 12 hours: (processor, 15.6GB memory tested, D, wireless, System Brd, Vedio)
I suspect that the 30GB cache SSD may be at fault, but I don't see a way to deactivate it, and I'm not sure if the SSD is physically present. That is, I suspect that 6GB of my 16GM physical memory is somehow partitions as an SSD, possibly through Intel RST technology. Is this possible?
Subsequently I tried the following
- Hard Reset - BSOD with error "System Thread Exception Not Handeled" - iaStorA.sys indicated.
- Forum page is not applicable - The page: HP PCs - Error Messages Display on a Blue Screen (Windows 10, 8, 7) - These options are either not applicable (because of BSOD at startup), or have been tried and do not worked.
- Windows Advance Options Menu - Using f8 key results in BSOD "Page fault in nonpaged area. - indicating iaStorAVC.sys. This is with attempting to boot from the Windows Media Creations for win 10 on a USB. If change the boot order to the internal HD the BSOD is "system thread exception not handled" - indicating iaStorA.sys (that is NOT iaStorAVC.sys)
Solved! Go to Solution.
01-11-2019 04:42 PM
systems that run the Intel 32GB (or smaller) cache module with a mech drive will have the cache module controlled in one of two places
1. in the bios, (you can enable/disable it)
2. from the intel RST console (you access it once windows loads)
in both cases the cache when enabled, causes read/writes to the drive to be first routed through the cache driver, and if you remove the drive and connect it to another system without first disabling the cache it will not be readable as the drive will still be trying to access the non existant cache module
if your cache is controlled from the intel RST console, then disabling the cache driver may not be possible, requiring a full "clean" windows reinstall
last, some systems allow replacing the intel 32GB cache module with a normal SSD module, if you do do this then remember to make sure the cache feature in the bios (if applicable) has been disabled
while the intel cache module is in many ways like a normal SSD, the cache module uses diffrent firmware algorithims that are specific to "caching data" rather than the generic Read/write access algorithims a normal SSD uses
if you have a corupted windows OS and your cache driver is controled using the RST console it's very hard to determine where the fault lies for most users since they can't disable the cach driver and as stated above a reinstall of windows is useally the only feasable option and once reloaded, you can then disable the cach module from within the os by loading the RST console and selecting the disable cache option
01-11-2019 06:09 PM
Thx for the clarity RE the cache. I removed it, and perhaps that is why my HD become 'unknown' to the system since they were a RAID pair. Not really sure at this point of the exact set of circumstances. After two days of trying everything that seemed reasonable which wouldn't be irreversable the time came to take more serious measures. Removing the cache unit and putting back the cloned SSD worked for me. The original HD is just for file storeage at this point (even though I cloned the SSD back to the HD.)
I have to think some sort of curruption of the HD was the originator of the problem given the errors in the Windows Event viewer.
I'm glad at this point not to have the 32GB of cache given your description of its limitations.