I have a Windows 2012 R2 VM that was working fine until a couple of days ago when I upgraded from 11.0-U3 to 11.0-U4. Now when it attempts to boot a blue screen comes up with the message Inaccessible boot device.
I tried going back to 11.0-U3 and I am getting the same error so I'm not entirely sure if it's related to U4 or not. It's worth noting that prior to the U4 update I manually shut down the VM cleanly just to avoid this sort of issue.
My configuration: FreeNAS 11.0-U3/U4 booting from an USB stick on an ASRock C2750D4I with 32GB ECC RAM. When it comes to the VM, other than the VNC adapter, it has a VirtIO NIC (tried to change to Intel E82545, still no go) and an AHCI ZVol disk that resides on a SSD drive (also tried to change this one to VirtIO but of course it didn't work which is pretty normal seeing that the VM doesn't have the viostor driver). Trying to boot in safe mode results in the same blue screen and no C:\windows\ntbtlog.txt file is created, something that according to Microsoft can only happen if the OS cannot get a handle to the disk to write the file. I even specifically tried to select the Enable Boot Logging option - same result, no log file. Trying to select Last known good configuration results in the same blue screen.
What is strange is that when it boots in automatic repair mode, I can open a command prompt and there is no problem if I try to create a file on the C: drive, it works fine... Also, chkdsk reports no problems. Tried sfc /scannow with /offbootdir and /offwindir a couple of times, the first time it reported repairing something but the 2nd time it reported no integrity violations yet the blue screen keeps showing up. I did nothing to the ZVol or to the VM configuration in the past couple of weeks and no Windows updates were installed recently (it's configured for manual update installation) - basically it simply stopped working when I updated to 11.0-U4.
I checked the FreeNAS logs and nothing relevant appears to happen when the VM boot fails, which is not completely unexpected seeing that the error occurs inside the VM.
Did anyone encounter similar problems? Is there anything that I am overlooking that might be causing this behavior? Any suggestions on what I could do at this point?
I tried going back to 11.0-U3 and I am getting the same error so I'm not entirely sure if it's related to U4 or not. It's worth noting that prior to the U4 update I manually shut down the VM cleanly just to avoid this sort of issue.
My configuration: FreeNAS 11.0-U3/U4 booting from an USB stick on an ASRock C2750D4I with 32GB ECC RAM. When it comes to the VM, other than the VNC adapter, it has a VirtIO NIC (tried to change to Intel E82545, still no go) and an AHCI ZVol disk that resides on a SSD drive (also tried to change this one to VirtIO but of course it didn't work which is pretty normal seeing that the VM doesn't have the viostor driver). Trying to boot in safe mode results in the same blue screen and no C:\windows\ntbtlog.txt file is created, something that according to Microsoft can only happen if the OS cannot get a handle to the disk to write the file. I even specifically tried to select the Enable Boot Logging option - same result, no log file. Trying to select Last known good configuration results in the same blue screen.
What is strange is that when it boots in automatic repair mode, I can open a command prompt and there is no problem if I try to create a file on the C: drive, it works fine... Also, chkdsk reports no problems. Tried sfc /scannow with /offbootdir and /offwindir a couple of times, the first time it reported repairing something but the 2nd time it reported no integrity violations yet the blue screen keeps showing up. I did nothing to the ZVol or to the VM configuration in the past couple of weeks and no Windows updates were installed recently (it's configured for manual update installation) - basically it simply stopped working when I updated to 11.0-U4.
I checked the FreeNAS logs and nothing relevant appears to happen when the VM boot fails, which is not completely unexpected seeing that the error occurs inside the VM.
Did anyone encounter similar problems? Is there anything that I am overlooking that might be causing this behavior? Any suggestions on what I could do at this point?