Windows as a Service: Example of fixing Compat Scan errors (A driver is installed that causes stability problems)


Sooner or later you will encounter some Compatibility Scan errors with your Windows 10 upgrades.

And if you like me run the Compat Scan prior to the actual Windows 10 upgrade, you will have time to fix these errors before the end-user is aware. Clever, right? ๐Ÿ˜€

So this post is an example of such and is based on a really simple approach to fixing an incompatible driver. Curious? Read on ๐Ÿ™‚

Compat ScanOnly

First things first and as mentioned. All of this is based on precaching and running compatibility scan prior to the actual upgrade.

In short, this is done with a task sequence similar to below and is something I have covered in details here:

What this essentially does, is running the setup.exe with a /Compat ScanOnly parameter. Hence no actual upgrade, but a validation of the process. Greatness.


So how do I know if something is incompatible? Logs and CompatData.xml to the rescue.

Again, I have covered my precaching task sequence in details previously here:

In below illustration, I’m making sure to copy out the relevant log and .xml files. This is very useful when needing to troubleshoot any issues related to upgrading Windows 10.

When taking a peek at the CompatData*.xml, the blocking type and reason is mentioned. In this scenario, the intcdaud.sys driver is incompatible.

Note: The reason for the compat scan failure is also mentioned in the smsts.logย and is referenced with a hexadecimal value. More info here:

Fixing the Issue

Now knowing that some devices have driver compatibility issues, it would be a decent idea to fix them before letting the users into upgrading Windows.

All of my WaaS setup prevents the actual upgrade from being offered to any device that failed the compatibility scan, so this is something that needs manual attention.

When a device fails either of the checks, it automatically becomes a member of new collection(s). See below illustration.

This is based on custom inventory (also covered previously) and with that in hand, you are quickly able to create additional collections and/or queries.

With that information available, I know exactly which device that failed the compat scan and what specific model this is.

Note: The specific model is important in this case, seeing it’s a driver related issue and a driver often is unique for the specific model.


Now that we know the ups and downs, it’s time to do something about it. As we know, in my scenario, this was caused by an incompatible driver.

So the first step is obviously to find an updated driver and test if this works with the particular model and version of Windows 10.

Once all of that is confirmed, it’s time to update the driver on the existing devices.

For this I’m leveraging pnputil.exe with a batch file:

  %SystemRoot%\Sysnative\cmd.exe /c %0 %*
pnputil.exe /add-driver "%~dp0intcdaud.inf" /install

I’m running this with a package/program with SCCM (System Center Configuration Manager), and we all know that a package runs as a 32-bit process on a 64-bit OS.

Therefore we have to trick the script into being launched from the sysnative folder, as pnputil.exe is not available when coming from a 32-bit process on a 64-bit OS.

Complicated much? Just copy/paste above if you want to run pnputil.exe with a package on a 64-bit OS ๐Ÿ™‚

The content of the package in my example looks like below:

And the program running pnputil.batย looks like below:


Eventually as the devices gets their driver updated, the compat scan is being rerun on a schedule. This is done only for the devices which failed the compat scan initially. Neat!

This is the collection, which is having a separate compat scan deployed:

Running the task sequence on a daily basis. What I really want here, is that the collection membership count is 0 and thus running this so aggressively shouldn’t be a problem.

For your convenience, below is an illustration of the separate compat scan task sequence.

The devices which failed the compat scan, only needs the actual compat scan. Therefore I have separated that part from the original PreCaching Task Sequence.

Let me know in the comment section down below if you have any questions.


2 thoughts on “Windows as a Service: Example of fixing Compat Scan errors (A driver is installed that causes stability problems)”

  1. Hi Martin,

    Only just come accross your task sequence that i will look into implementing.

    I do have one issue you may be able to help with, Most of my incompatabilities are down to the Base OS image and the image im wanting to deploy.
    We have OS language as 1033 (US) but am wanting to install the (en-gb) version over the top, do you know of anyway i can get around this or in fact any other random versions?

  2. Hi Martin. Is there a way to rule out a compat scan error from setting registry value 1 Failed.
    We have different languages in our company and if the upgrade package is in english so we get a Hard Block compat scan failded.
    We know how to handle this issue but i dont wont precash 6 full uppgrade packakges on each device.

    Result from setupdiagresults.xml
    Warning: Found Language Hard Block: “en-US”.
    Language = en-US
    You cannot upgrade the host OS to this language, select the correct
    matching language build to upgrade this system.



Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.