9520 SSD speed drops and hibernate stops working after switching to AHCI

Hello, I see you are looking for technical assistance. If you need our help, you can start a private message with us and we will be happy to assist you.

I was looking through your specifications and do not see if your system uses Optane memory.  If it does, RAID is required for that operation.

What driver does the Device Manager show for the NVMe drive?

If you are going to put Linux on that system, do research to see the best way to do that and backup everything you can prior to doing so.  If done incorrectly, future upgrades may be compromised.  I am not a Linux user so I cannot offer guidance.

If that system is a modern standby system, you might want to check the link which talks about that operation.  A way to tell if it is, the Properties tab on the Wi-Fi device in Device Manager will not normally have a Power Management tab.

Modern Standby | Microsoft Docs

Hello, I see you are looking for technical assistance. If you need our help, you can start a private/direct message with us and we will be happy to assist you.

Thanks for your reply. I'm not sure if there's optane on the system. In device manager the disk doesn't have optane in the name so I'm guessing there isn't.

The driver for NVMe is Standard NVM Express Controller if the system is switched to AHCI. It indeed has modern standby.

In Win 11, those standard drivers may be fine since my 980 Pro is using standard drivers on a PCIe 4 system and getting full speed.

I have changed controllers on my systems multiple times and never noticed a hibernation situation.  Maybe shutting the system all the way down would rewrite your hibernation file and update it.

The system is likely configured with Intel Virtual Management Devices which requires the RAID SATA Operation. At present there is no Linux Kernel VMD Driver so you need to use AHCI in order to recognise your internal drive in Linux... Sadly the newer Kernel in Ubuntu 22.04 or Fedora 36 does not have an Intel VMD Driver. It'll be another 2 years until a new mainstream build of Ubuntu is out.

The Intel VMD optimizes the performance of the storage controller by communicating with the NVMe SSD, Intel Processor and RAM and is therefore expected to have a higher read/write speed than using the legacy AHCI SATA Operation. In other words is working as expected.

Windows 11 itself is designed to work only on modern hardware with newer technologies... By disabling these technologies i.e. by using a legacy AHCI SATA Operation you are more likely to run into issues such as what you are experiencing such as coming out of hibernation etc.

You'll need to gauge how often you are using Windows and how often you are using Linux. If you use Windows vastly more than Linux, use of the RAID SATA Operation with VMD Drivers and a Virtual Machine (VMware, VirtualBox or Hyper-V) will likely perform better. 

intel vmd is only supported on xeon CPUs https://www.intel.de/content/www/de/de/architecture-and-technology/intel-volume-management-device-overview.html

---

@inteks wrote:

intel vmd is only supported on xeon CPUs https://www.intel.de/content/www/de/de/architecture-and-technology/intel-volume-management-device-overview.html

---

That link appears to be an older product sheet, with the high end Xeon processors originally showcasing the technology. Intel VMD is now used in more mainstream systems with 11th Generation and 12th Generation Processors:

Intel® VMD is the new way to configure platforms for Intel® RST management of RAID and Intel® Optane™ memory volumes.

The proper HW and BIOS support is currently available in mobile 11th and 12th Generation Intel® Core™ Processor-based systems.

How to Configure RAID or Intel® Optane™ Memory with... 

Intel 11th Generation Processors, No Drives Can Be Found During Windows 10 and Windows 11 Installation | Dell UK

So, guys, I've spent too much personal time resolving this particular issue, and I logged in here just to share my findings. Here's what I found:

• To my regret, DELL Premium support didn't help. All they do is walk you through their standard checklist, which is very time-consuming and irritating. What's interesting, they mentioned that the brand new laptop should not have come with the RAID-On option pre-selected. As you can guess, any changes to that arrangement render the system unusable; it simply stops loading, which is no surprise as you change the underlying mode of operating SATA devices. What's curious, there's a way to do that switch without reinstalling the OS. I found this Gist extremely useful, and it helped me a lot in my investigation. The bottom line is that switching from 'Raid-On' to AHCI is quite straightforward, but the reverse operation is quite complex for an average user
• Another finding - switching back and forth from Raid-on to AHCI and vice-versa does not affect hibernation. At first, I thought it was because it suddenly started working with the fresh OS installation in AHCI mode. However, it was a false positive, and after a while, once I started installing stuff on my laptop, the hibernation got mangled again
• I took another strategy, as I wanted to dig to the bottom of this issue and started installing software and updates one by one, keeping an eye on the Windows Event Log. Yes, that was a very irritating exercise, but what I found is invaluable - the windows updates are the culprit
• So far, I have identified two updates that render the Hibernation mechanism unusable in Windows 11 on this particular laptop:
  • KB5015814 - Cumulative Windows 11 update
  • KB5016629 (Security update) and this one KB5015882 is under question
• My observations:
  • The funniest part is that only DELL XPS 9520 is affected. My Windows 11 desktop that has exactly the same set of updates installed works just fine. Moreover, a colleague of mine with a Razor Blade 15 laptop has exactly the same OS and updates and the hibernation work absolutely fine
  • The disk operating mode (AHCI or RAID-on) does not matter - it works for both if these updates are not present in the system (I checked that with fresh Windows 11 installations)
• Things to try if you face the same issue with Hibernation:
  • The only actionable workaround would be complete uninstallation of the specified updates. Keeping Windows without those security updates is not an option, so whoever owns a DELL laptop and has this problem should demand from @support and @DELL-Cares to resolve the issue asap
  • In order to stop Windows from nagging you to install these updates (and btw., Windows 'has a habit' of installing critical updates without your explicit approval), you can use this article I found very useful. It boils down to leveraging 'wushowhide.diagcab' util, which Microsoft hid from you, so you can't disable the updates. But still, you can freely download it from the MS site (no worries, it's safe) and hide the updates from the Update center

And finally, this is the synopsis of the issue (for the DELL support benefit):

• Even though Hibernate is activated in Windows 11 and no other changes are done to  Power Options, the hibernation stops working right away (or eventually)
• If I change the Power Options, i.e., choosing what the closing lid does (i.e., hibernate in my case), the laptop hibernates but does not wake up from hibernation properly. Opening the lid results in the system shutting down.
• The same goes if you hibernate from the Start menu (Start --> Power --> Hibernate). Pressing the power button to start the laptop after hibernation results in the system shutdown
• That said, no matter what option you choose to hibernate the laptop, it results in abnormal failure (you can look at the Windows Event Logs) when the laptop doesn't wake up from hibernation properly. This is what I see in the event logs (but this is definitely up to DELL Technical team to look at and identify why exactly these updates are causing the Hibernation issue):
• 

That's it, guys. Hope it will help you as it helped me. However, I'm looking forward to the definitive resolution of this issue, simply because you can't keep skipping critical security updates for the OS

It looks like your system is getting Blue Screens.  Have you checked for a Memory.dmp or numbered .dmp file in the Windows\minidump file we could check?

If the system has Optane Memory it needs to be in RAID mode and the Premium SATA/PCIe driver will provide good performance.

Since the system is probably a modern standby system, have you made any changes in order to affect that behavior?

If you switch from AHCI to RAID, you need to be going through the process where you set the system, using msconfig.exe to boot back into Safe Mode.  Then reboot and go into the Bios to make the controller change and let it reboot into Safe Mode.

You can then use msconfig.exe to change back to a normal boot and the system should not go into a recovery mode.

I am not the expert at looking through Dump files but it appears the driver, WUDFRd.sys, is involved.  I found the site below so you might go through that procedure.  It is a third party site so be careful what you click on.

Keep in mind, Fast Startup and Hibernation work together.

Driver WudfRd Failed to Load – 5 Ways to Fix It in Windows 10 (partitionwizard.com)

Thanks, @Saltgrass 

I only described my own observation and fight with this issue, and I didn't get that deep into looking in the memory dump files. As I mentioned, this is a brand new laptop, and DELL replaced the first one after my complaints on Hibernation. The support team was unable to resolve the issue over the screen sharing, so they decided in favour of the free replacement. However, as practice shows, the problem is still there. The trick with the memory dump revealed a bit more details. I did the analysis, and this is what I see now:

DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000006, The device did not complete its Directed Power Transition callback successfully.
Arg2: ffffc10e97dd7010, The POP_FX_DEVICE object
Arg3: 0000000000000000, If this was a Directed Power Down(1) or Power Up(0) completion
Arg4: 0000000000000000

Debugging Details:
------------------

*** WARNING: Unable to verify checksum for win32k.sys

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 8281

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 26951

    Key  : Analysis.Init.CPU.mSec
    Value: 3062

    Key  : Analysis.Init.Elapsed.mSec
    Value: 127754

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 113

    Key  : Bugcheck.Code.DumpHeader
    Value: 0x9f

    Key  : Bugcheck.Code.Register
    Value: 0x9f

    Key  : WER.OS.Branch
    Value: co_release

    Key  : WER.OS.Timestamp
    Value: 2021-06-04T16:28:00Z

    Key  : WER.OS.Version
    Value: 10.0.22000.1


FILE_IN_CAB:  080922-11750-01.dmp

BUGCHECK_CODE:  9f

BUGCHECK_P1: 6

BUGCHECK_P2: ffffc10e97dd7010

BUGCHECK_P3: 0

BUGCHECK_P4: 0

DRVPOWERSTATE_SUBCODE:  6

DEVICE_OBJECT: ffffc10e9b1bcde0

DRIVER_OBJECT: ffffc10e9a313e30

IMAGE_NAME:  WUDFRd.sys

MODULE_NAME: WUDFRd

FAULTING_MODULE: fffff8035d990000 WUDFRd

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

STACK_TEXT:  
ffff8488`3ae0f828 fffff803`42fc7ecd     : 00000000`0000009f 00000000`00000006 ffffc10e`97dd7010 00000000`00000000 : nt!KeBugCheckEx
ffff8488`3ae0f830 fffff803`42fc79d3     : ffffc10e`97dd7010 00000000`00000000 ffffc10e`82adfc00 ffffc10e`97dd73e0 : nt!PopFxEnforceDirectedPowerTransition+0xc1
ffff8488`3ae0f890 fffff803`42fc808a     : 00000000`00000000 00000000`00000000 ffffc10e`97dd73a8 ffffc10e`ec013c10 : nt!PopFxCompleteDirectedPowerTransition+0x16f
ffff8488`3ae0f8e0 fffff803`42fc7cb1     : ffffc10e`97dd7010 ffffc10e`82adfc30 ffffc10e`82adfc30 ffffc10e`ec013c10 : nt!PopFxHandleDirectedPowerTransition+0xa6
ffff8488`3ae0f910 fffff803`42d1d10f     : ffffc10e`82adfc30 ffffc10e`82adfc00 fffff803`00000000 fffff803`00000000 : nt!PopFxDirectedPowerTransitionWorker+0x11
ffff8488`3ae0f940 fffff803`42c478f5     : ffffc10e`aa43a040 ffffe601`953d0000 ffffc10e`aa43a040 00000000`00000000 : nt!ExpWorkerThread+0x14f
ffff8488`3ae0fb30 fffff803`42e19a74     : ffffe601`953c0180 ffffc10e`aa43a040 fffff803`42c478a0 00000000`00000246 : nt!PspSystemThreadStartup+0x55
ffff8488`3ae0fb80 00000000`00000000     : ffff8488`3ae10000 ffff8488`3ae09000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x34


IMAGE_VERSION:  10.0.21390.1

STACK_COMMAND:  .cxr; .ecxr ; kb

FAILURE_BUCKET_ID:  0x9F_6_IMAGE_WUDFRd.sys

OS_VERSION:  10.0.22000.1

BUILDLAB_STR:  co_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {ae60ce0d-80ec-b321-0d01-767ceb898c87}

Followup:     MachineOwner
---------

From what I can see, there's a driver failure that took place. I wonder what driver is this and is there a definitive resolution to this issue?

Here's my experiences:

Summary: hibernate does not work with AHCI mode, but does work with RAID mode, on Windows 11 with all the latest updates and using Dell Command Update to apply all the latest drivers and firmware.

I bought just over 30 XPS 9520 laptops over the last few months. We changed them all from the default RAID to AHCI because historically AHCI was supposed to be better for SSDs due to the native TRIM support. Intel RST originally didn't support TRIM (still doesn't for RAID1 unless you have the Enterprise version I believe).

When building the laptops (using SCCM, using a pretty much straight off the ISO Windows 11 .wim) we use Dell Command Update to install all the drivers using dcu-cli.exe /driverinstall

We disable Fast Startup via a Group Policy Preference. Fast startup means that when the user tells the laptop to "shut down" it actually just logs them off and then hibernates - so none of the background services actually get shut down and the machine has not started up afresh when they next turn it back on again. I see no need to shave a few seconds off the startup time at the expense of machines getting a regular "proper" restart. Fast startup relies on hibernate, not the other way around.

Anyway, even with the latest v1.6.0 BIOS we still had the issue with hibernate so finally managed to get a method to switch the machine from AHCI to RAID without reinstalling Windows. Now hibernate works fine, so we're going to stick with RAID/Intel RST mode for the storage controller.

We've added the RST driver to our SCCM WinPE .wim, Win11 .wim and the Windows Recovery Environment .wim (inside the Win11 .wim) and are now building all further machines in RAID mode directly.

I did use the instructions on the Gist referenced above but they didn;t work without some extra modifications. Essentially, the info for the XPS 9520 RST dirver is different and our machines didn't have the driver installed. I'm planning to do a blog about it at some point but if anyone is stuck in the interim, ping me a message and I'll see if I can help. Note that I am not going to diagnose why your hibernate isn't working!

Ultimately, Dell need to figure out why there is a problem with hibernate, and this might well involve Microsoft and/or Intel as the AHCI driver is a Microsoft driver that ships with Windows. Either the driver is faulty or Intel's hardware is not properly talking AHCI. We use AHCI mode on our older Latitude laptops and have done since around 2016 and have no issues with hibernate on Win10 1607 (LTSB 2016).