Moving from AHCI to Raid

Moving from AHCI to Raid

In the previous blog post, we moved from RAID to AHCI. Moving from AHCI to RAID can also be achieved without reinstalling Windows. With my NVME disk, I have not seen a huge performance difference between AHCI with the native Windows driver and RAID with Intel RST. If, however, you want to move back from AHCI to RAID when newer drivers become available this is also possible. Depending on your approach it can be a more tedious process with some risk, but normally you can always fall back to AHCI if it doesn’t work out and, otionally, try another approch.

You can also find a procedure to move from RAID to AHCI in https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63. I mentioned before. Make sure you read and understand it before jumping in. Also, why try the easier ways first. Read on!

I personally have used other ways to do this. Manipulating some registry settings in combination with a safe boot before booting normally does the trick as well. This works with both SATA SSD and M.2 NVMe drives and it enables relatively fast switching between back and forth between AHCI and RAID. I have described this method below.  I have also tried the same process used to switch from RAD to AHCI and that works as well.

  • Switch to safe boot
  • Reboot into BIOS
  • Change from AHCI to RAID in the BIOS
  • Boot into safe mode
  • Turn off safe mode and reboot normally again

Nothing else and that also did the trick, just like with moving from RAID to AHCI.  So the link above and my step by step below is here for completeness. You have options in case one of them doesn’t work!

Step by step AHCI to RAID registry method

This procedure I describe below works on Windows 10 1803/1809 and has been tested on Dell Latitude E6220 an XPS 13 9360. Editing the registry is always a little risky if you have no clue what you are doing. So, beware if you mess up and can’t figure out how to get out of this pickle, you might need to redeploy/restore from backup.

To change the SATA operation mode from AHCI to RAID follow the steps below.

Prepping the registry settings

  • Open the registry editor regedit
  • Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetXXX\Services\and find the some of the keys that are below (not all will exist depending on your laptop’s configuration):
    • iaStor: (Intel RAID, 3 = off, 0 = on).
    • iaStorAVC: (Intel Chipset SATA RAID Controller,3 = off, 0 = on).
    • iaStorAV: (Intel(R) SATA RAID Controller Windows,3 = off, 0 = on).
    • iaStorV:(Intel RAID Controller Windows 7, 3 = off, 0 = on)
    • storAHCI: (this is AHCI, 3 = off, 0 = on)

You can put all these to 0 if you want, that doesn’t matter but normally you’ll know which one matters. AHCI is easy, there is only one entry. For the iaStor options I know I need aiStorAVC as the one I see in device manager and in the WinDbg MEMORY.DMP analysis is iaStorAVC.sys in my previous blog post.

When you find a StartUpOverride sub key and it is set to 3 also change this to 0 for the value you want to switch to.

Just make sure you set the one you need to 0 as then it will be picked up when you switch between AHCI/RAID in the BIOS. If you’re in you can set them all to 0 as the setting in the BIOS will pick up the correct one and windows will reset the StartupOverride value where needed.

When changing values in CurrentControl001 or 002 make sure you know the one that is being used. You can find that inHKEY_LOCAL_MACHINE\SYSTEM\Select in the value named Current. If it is 1 edit CurrentControl001 if its 2 edit CurrentControl002 (that key might not even exist).

Making sure you go into safeboot mode

  • After changing the registry setting set the default boot mode to Safe Mode, use msconfig.exe or open an admin cmd/PowerShell window and run: bcdedit/set ‘{current}’ safeboot minimal
  • Reboot and hit F2 to enter the BIOS.
  • Change the SATA mode to RAID.
  • Save and reboot.
  • After Windows successfully boots into Safe Mode, disable Safe Mode with msconfig.exe or open an admin cmd/PowerShell window and run: bcdedit /deletevalue ‘{current}’safeboot
  • Reboot again.
  • Log in and verify in Device Manager, that you now have the Intel Chipset SATA RAID Controller device under Storage Controllers.

Updating the Intel RST driver

  • You are now back to RAID but are still at the driver level that is causing your BSODs. Mine was 15.9.
  • To fix that you need to upgrade your Intel RST driver. While doing so you might get a warning about being unable to inject the driver into the recovery partition but you can ignore this and take care of that later.
  • Now reboot again and check the storage controller now in device manager. You’ll find an Intel Chipset SATA/PCIe RST Premium Controller now with driver version 16.7.0.1009 at the time of writing and that is the one I used and which fixed the BSODs for me when using RAID. Now DELL also releases updates on their support site you can try. If that doesn’t fix it, grab a more recent one from Intel if you can find one to try. That is what I did here.
  • The old AHCI disk is still visible when you enable show hidden devices but also shows the disk name as know to the Intel Chipset SATA/PCIe RST Premium Controller.

Important

Note that if you have a BSOD during the installation don’t despair, try again and after a successful run and reboot you’ll have the new driver. Then you’ll have to work on the laptop and see if it still blue screens. If so, revert back to AHCI.

I hope this helps someone out there, including my future self.

Move from RAID to AHCI

Move from RAID to AHCI

The good news is you do not need to reinstall Windows to move from RAID to AHCI. You just need to do it right and in the correct order to make this pretty straightforward.

As you might recall from my previous blog DELL XPS Laptops and seemingly random Blue Screens of Death the reason for moving to AHCI is that our laptop blue screens on the iaStorAVC.sys driver of the Intel Rapid Storage Technology when in SATA RAID mode.  If an update is not available or doesn’t help we can move to SATA AHCI mode and avoid any more BSOD due to the Intel RST driver.

The process for moving from RAID TO AHCI (and back again if you so desire) is described very well over here https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63. Note that this can also be done via msconfig (safe boot, minimal).

Step by step RAID to AHCI

To move from RAID to AHCI is surprisingly easy. All that’s needed is a successful boot to Safe Mode after switching from RAID to AHCI in the BIOS settings. It is important you first boot into safe mode after making the change in the BIOS. This process was tested with an XPS 13 9360 and a lab Lattitude E6220. The process, step by step, is as follows.

  • To set the default boot mode to Safe Mode, usemsconfig.exe or open an admin cmd/PowerShell window and run: bcdedit /set ‘{current}’ safeboot minimal
  • Reboot and hit F2 to enter the BIOS.
  • Change the SATA mode to AHCI.
  • Save and reboot.
  • After Windows successfully boots into Safe Mode, disable Safe Mode with msconfig.exe or open an admin cmd/PowerShell window and run: bcdedit /deletevalue ‘{current}’safeboot
  • Reboot again.
  • Log in and verify in Device Manager, that you now have the Standard NVM Express Controller device under Storage Controllers.
After moving to SATA AHCI

The performance with my KXG50ZNV512G NVMe Toshiba disk is still OK. Not as good as it could be but that’s reality for you. It’s worth to note that DELL does not officially support other NVMe drivers than the inbox Windows one for AHCI mode. Not saying you cannot try to install them but thenyou would be out of support. As noted above, standard these laptops come with RAID mode enabled by default.  AHCI is supported and sometimes even needed (dual boot with Linux for example).

Anyway, things work and perform well. They are also stable and that is of utmost performance for me. If at a later date you want to move to RAID again read the next blog: Moving from AHCI to Raid

DELL XPS Laptops and seemingly random Blue Screens of Death

Introduction

Over the last years, I have endured some blue screens on my personal travel laptop and those of some buddies. The common factors were various types of DELL XPS laptops and seemingly random Blue Screens of Death (BSOD) with irql_not_less_or_equal. The problem and cause are however not limited to these devices or brand. The cause, I found, very often was the Intel RST driver.

Trust me, there is nothing I find more annoying than a BSOD while I’m on the move and working in a train, airplane, attending a conference or in the speaker room of conference finishing my slides. Heaven forbid it happens while I am presenting. It is always annoying, but in my home office I have other options. While I am traveling, I have no other options.

Diagnose the problem

To fix the issue we need to stop guessing and randomly upgrading or downgrading drivers in a trial and error fashion. Diagnose the problem properly. So what does a seasoned IT Pro do? The IT Pro copies the memory dump from the system and feeds it into WinDbg (download it here).

Be sure to work on a copy of the MEMORY.DMP if you run WinDbg on the problematic machine itself to prevent any permissions issues. Open it via the “File” menu and the option “Open Crash Dump”.

Select your copy of the MEMORY.DMP file.

Let it run and have some patience as it does its work. Pretty soon you’ll see output like below.

Probably caused by : iaStorAVC.sys ( iaStorAVC!Wcdl::Allocator::freeContiguous+20 )

When you run analyze -v you’ll get extra details but you already know what you need to know.

The outcome over the past years, in many (most) cases, pointed to iaStorAVC.sys more than anything else. This is the Intel Rapid Storage Technology (intel RST) driver. Your mileage may vary but I have seen the same cause on multiple XPS systems I figured I would blog it and save my future self (and maybe some of you) a ton of headaches. That said, when you get a BSOD you really must investigate the MEMORY.DMP file from that system yourself to see what driver is the culprit. But with an XPS, chances are iaStorAVC.sys is a reasonable candidate suspect. It has been a common issue over the past few years it seems.

Fine now we know what to fix. How to fix it is what we’ll look at next. I just wrote this blog for my own reference.

Fixing iaStorAVC.sys related BSOD

You have two possible approaches to fixing iaStorAVC.sys related BSODs.

  1. Get an updated Intel Rapid Storage Technology driver (this port)
  2. Move from RAID to AHCI without reinstalling
  3. Move from AHCI to RAID without reinstalling(handy when newer RST drivers are available and your want to test your luck).

We will look at all 3 options, staring with option 1 below.

For these operations make sure you have a (local) account with admin rights. These procedures should work with BitLocker enabled (my laptop has) but make sure you have your recovery keys at hand somewhere. Also, when using a PIN this won’t work in safe mode you know your username/password. The Barney Bear essentials for sysadmins who’ve been around the block a few times.

Get an updated Intel Rapid Storage Technology driver

This is pretty straightforward. Making sure all drivers are up to date is the 1st response to driver issues. No need to explain this in detail, just install them. If DELLEMC has one on their support site that’s great. If they don’t head over to the Intel site and look over there. DELLEMC can lag behind a few months which is why SuoortAssist or you won’t find anything. I have used the more recent Intel downloads with success in the past (https://downloadcenter.intel.com/download/28255/Intel-Rapid-Storage-Technology-Intel-RST-User-Interface-and-Driver?product=55005) to keep Intel RST update.

As RAID mode is how the systems ships by default this is the easiest way to resolve the issue with DELL XPS Laptops and seemingly random Blue Screens of Death. Now if this doesn’t fix the issue or there is no newer driver to be found move on to option 2 and eventually maybe even 3. Those are other blog posts.

New-SMBMapping -UseWriteThrough $True

New-SMBMapping -UseWriteThrough $True

As my readers probably know I like networking technologies. I experiment a lot find the best solutions for the challenges at hand. The aim is to make sure what I finally deploy in production is a very solid design. This avoids issues. Details can be very important in all this.

One such details is that in Windows Server 2019 (1809) and Windows 10 1809 mapping an SMB share has gotten a new parameter. For specific use cases, where caching is undesirable, you can now leverage: New-SMBMapping -UseWriteThrough $True

Some software requires and is dependent on the absolute guarantee data is consistent and persisted at all times. If so, the standard behavior of the OS in relation to a SMB 3 share is not enough to achieve this. Backups are such a use case. I wrote an article on this that was published on the StarWind Software blog: 
Windows Server 2019 introduces a new SMB Mapping Option UseWriteThrough

Go have a look and I hope you find it useful. You will find more info on the potential issue it fixes inWhen using file shares as backup targets you should leverage continuous available SMB 3 file shares