What does 'No Match' mean when running SetupDiag.exe

When running SetupDiag.exe, after another failed 1803 update, the log file shows entries like the below.

Q: What does this 'No Match' mean?

Thanks.

SetupDiag: processing rule: CompatScanOnly. No match.
SetupDiag: processing rule: BitLockerHardblock. No match.
SetupDiag: processing rule: VHDHardblock. No match.
SetupDiag: processing rule: PortableWorkspaceHardblock. No match.
SetupDiag: processing rule: AuditModeHardblock. No match.
SetupDiag: processing rule: SafeModeHardblock. No match.
SetupDiag: processing rule: InsufficientSystemPartitionDiskSpaceHardblock. No match.
SetupDiag: processing rule: CompatBlockedApplicationAutoUninstall. No match.
etc.

Thank you so much! What can be concluded in case there are '0 matches', i.e. SetupDiag could not find errors?
Assume it could still be a driver- or hardware issue?

Searching for setup logs, this can take a minute or more depending on the number and size of the logs...please wait.
Found 1 setupact.logs.
Processing setupact.log at: C:\$WINDOWS.~BT\Sources\Panther\setupact.log
Found 3 setupact.logs.
Processing setupact.log at: C:\Windows\Panther\setupact.log
Processing setupact.log at: C:\Windows\Panther\NewOs\Panther\setupact.log
Processing setupact.log at: C:\Windows\Panther\UnattendGC\setupact.log
Found 1 setupact.logs.
Processing setupact.log at: C:\Windows\Panther\NewOS\Panther\setupact.log
Found C:\$WINDOWS.~BT\Sources\Panther\setupact.log with update date 05/21/2018 13:41:04 and CV: yRBG4hPmhklIDoZk to be the correct setup log.

SetupDiag found 0 matching issue.

Thanks for getting back on this.

Please find the files attached.

Pls also see PM

thanks again!

I assume(!) that it has something to do with assigning DeviceID's (DISK 0, DISK 1 etc. in Windows Diskmanagement).
My motherboard (Asus X99 DeLuxe/U3.1) has 2 SATA-controllers.
Controller 1, port 1 (AHCI) = Samsung SSD - this one includes Windows.
Controller 1, port 2, another SSD
and so on... up to port 6

Controller 2:
port 7: DVD
port 8: nothing attached
port 9: a 2TB SATA HDD
port10: nothing attached

However, Windows Diskmanagement lists the port 9 HDD as DISK 0 (DeviceID=0) and the Windows SSD as DISK 1.

One would assume that disabling the SATA port 9 (the Windows SSD is assigned to DISK 0 within Diskmanagement) would solve the matter.
But that is not entirely the case.
Upgrade will still fail.

I can only assume that within settings of Windows, just prior to upgrading, references are made to DISK 1 (i.e. the situation before disabling port 9) and therefore the upgrade fails.

It will only succeed when first formatting the drive and then do a clean install.

I think there is an article about this matter
"
Disk drive numbers may not correspond to the SATA channel numbers when you install Windows on a computer that has multiple SATA or RAID disks
"

This then leads to conclusion that in case of multiple HDD's and when Windows is not installed on DISK 0, the one and only upgrade is a clean install...

Up front: many thanks for taking the time to investigate the logs. It is really appreciated!


Before I read your post, I disabled SATA controller 2 entirely (my actions at earlier attempts were to just disable to port of the HDD)

This time the update finally, finally went fine! Pheww!

This isn't something for a 'simple end-user' though... (or a short-tempered person)

Note that the drivers are the latest ones.

And... above all...
in the past I even could not install Windows 10 x64 from USB (MCT) on a formatted drive!
i.e. non of those drivers were loaded then.

That's to say, I could install it, but at 1st reboot I would get a BSOD.

Next time I should start off disabling the 2nd controller.

Again, many thanks for taking the time.

What I am not sure of - with all the experts here - whether they have connections with Microsoft.
Meaning to say whether 'major issues' reported here are passed on to Microsoft, so they might include 'fixes' into one of the next releases.

My above update 'solution/workaround' is a quite unusual and figuring this has taken an awful lot of time.
Note that I was having the same issue with 1709 update
See thread titled: "1709 Fails to install and how to remove multiple recovery partitions?" I could only install the 1709 update by disabling the DISK 1 HDD and subsequently format the Windows drive. This time I managed to update by disabling the entire 2nd controller. All this has to do with drive/disk enumeration. AFTER the update only Windows works well even though it does not reside on 'DISK 0', but on 'DISK 1'.

I believe the update routine should consider the location of the existing version and update that even though it is not on DISK 0.
It is a bit weird that Windows runs fine from a different disk# but insists on the use of DISK 0 when it comes to updating.