Jump to content
Welcome to our new Citrix community!
  • 0

Drive Error Notification On Non-persistent VDIs After Windows 10 Upgrade to v2004

Derek Gamble


Hi there,


We've been experiencing a strange issue suggesting disk errors after upgrading to Windows 10 2004 and wondered if anyone else has saw this one. Details are as below:



Citrix ELM Version –

Hypervisor – Nutanix

Windows 10 version – 2004 with App Layering Prep Utility 20.900.6 installed and latest set of Setup Scripts from the Tools extracted to c:\windows\setup\scripts

Symantec Endpoint Protection 14.2

Citrix VDA 2009

Citrix Workspace 2010



We’re having an issue with non-persistent VDIs created from an App Layering published image which is used with Citrix Machine Creation Services.

The template has been upgraded from Windows 10 1809 to 2004 and the latest App Layering tools and utilities applied. The recovery partition created on the OS Layer was removed before finalizing the layer too.

The Symantec fix for v14.2 to sort the boot file signature issue (‘AddSymantecFilesNeededForBoot.cmd’) was also applied on an Application Layer.

When devices updated with this image are logged on to we see the attached error message in Security and Maintenance notifications ("Restart to repair driver errors.") which we haven’t experienced before on the previous image updates.

We’ve ran chkdsk on devices as well as running on the source template and also on a version of the OS Layer and no issues are reported. Is this an issue that’s been reported from other clients?


Link to comment

7 answers to this question

Recommended Posts

  • 0

In the past, we(internally) have seen that message, and deemed it as benign, not truly a indicator of a problem. Something to do with how Microsoft "reads" our image. I am checking if this is still true. But, please reply to the below.


- Does the error appear all of the time?

- Is the machine functional, in spite of the message?

- Are you using Elastic and, or User Layering?

Link to comment
  • 0

Hi Raymond.


Thanks very much for the response.


- I can confirm that this is at every reboot/startup and does also happen on the published template used as the Machine Catalog source too but not on the OS Layer (I'm testing Platform layer and App Layer that has Symantect installed to see if any of the layers show this or if it's just when the template is published)

- machines are functional despite the message. We don't see any issues. There are no 'wininit' or 'chkdsk' events in the Application log when checked but the Ntfs\WHC log does show Event ID 100 at each startup showing 'NTFS Global corruption action state is now 3.' immediately after an Event ID 100 showing 'NTFS Global corruption action state is now 1.'

- There are no Elastic or User Layers in our environment currently.

Link to comment
  • 0

Apologies as the first message in the Ntfs\WHC log is 'NTFS Global corruption action state is now 0.'


I've double checked the layer with Symantec on it and there are no warnings or errors in that log as they are just information events showing 'NTFS Global corruption action state is now 0.' too.


The Platform Layer shows a Warning Event ID 100  'NTFS Global corruption action state is now 1.' after first showing the state as '0'.


So it seems that it's during the image publishing phase that introduces some configuration that the Windows OS sees as a potential disk error.


I've also looked at a Server 2016 image that we manage with App Layering and can see the published image and updated devices show a Warning Event ID 100 in the Ntfs\WHC log that shows 'NTFS Global corruption action state is now 2.' after the first event showing '0'.

Link to comment
  • 0

Try the below, to see if it helps.


1) Add a version to your OS layer

2) Once the packaging machine, vm is ready remove the disk, then attach the disk to a non-App Layering VM

3) Find any third party defragmentation tool, then defrag the drive. Do not use the OS native tool, since we have noticed

4) Attach the disk back to the packaging machine and finalize the disk

5) Test with the new OS layer version

     a) Publish a normal image, with all of your layers. If you still see the error, go to b.

     b) Publish an image with only the OS and Platform Layers. Let's see if another layer is part of the cause


Should the error persist, after "b", I will need for you to open a case and request it be escalated, per this thread.

Link to comment
  • 0

Thanks for the guidance on this Raymond. One of my colleagues opened a support case - Citrix - 80157356 - (I posted in the forum as I have no access to do so currently) and this has now been resolved.


Steps taken to check and fix (quite similar to those you advised):


1 - Add a new OS Layer and run Chkdsk /f reboot then sfc /scannow and reboot - double check no disk or Ntfs\WHC entries

2 - Publish test image with only this new OS Layer and the Platform Layer - check for and drive warning or Ntfs events - all clear

3 - Publish full image with the amended OS Layer and again check for warning and events - all clear

4 - Ran our cleanup script, took a snapshot and updated the Machine Catalog and rebooted devices to test with the updated image - again all clear now.


Because of this we're going to add the Chkdsk and sfc steps to our monthly update process so hopefully won't run into this again.


Once more thanks for taking the time to guide on this. 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...