Hey Checkyourlogs Fans,

With the looming deadline of January 2020 coming up very very fast I know many of you are racing to get your Windows 10 upgrade projects done. With that said I wanted to share an extremely handly little tool that Microsoft has built to help troubleshoot failed upgrades.

It is called setupdiag.exe and is a real life saver.

You can grab a copy from here:

https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag

Our situation today was a failed upgrade and this prompt on the end users machine:


The Installation failed in the SECOND_BOOT Phase with an error during MIGRATE_DATA operation.

This error message turns up next to nothing when researching it and it is pretty normal for Windows Upgrades / Migrations to have super cryptic error dialogs.

It is also important to note that doing an in-place upgrade like this has safety nets built-in. When the upgrade failed it rolled back to Windows 7, and the machine was useable for the end user. This allowed us to troubleshoot behind the scenes and get them back in working order while we figured things out.

Setupdiag.exe checks the following log files:

Windows Setup Log Files and Event Logs has information about where logs are created during Windows Setup. For offline processing, you should run SetupDiag against the contents of the entire folder. For example, depending on when the upgrade failed, copy one of the following folders to your offline location:

\$Windows.~bt\sources\panther

\$Windows.~bt\Sources\Rollback

\Windows\Panther

\Windows\Panther\NewOS

If you copy the parent folder and all sub-folders, SetupDiag will automatically search for log files in all subdirectories.

Step 1 – Download Setupdiag.exe from here: https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag

Step 2 – Run it from a command line like this on the problematic machine – setupdiag.exe /output:c:\post-install\setupdiagoutput.log

Review the file here is what our sample looked like:

Matching Profile found: CompatBlockedApplicationDismissable – EA52620B-E6A0-4BBC-882E-0686605736D9

System Information:

    Machine Name = CRP-BLAH

    Manufacturer = LENOVO

    Model = 3306F1U

    HostOSArchitecture = x64

    FirmwareType = PCAT

    BiosReleaseDate = 20120807000000.000000+000

    BiosVendor = LENOVO BIOS Rev: 9SKT39A 0.0

    BiosVersion = 9SKT39AUS

    HostOSVersion = 6.1.7601

    HostOSBuildString = 7601.24335.amd64fre.win7sp1_ldr_escrow.181228-0954

    TargetOSBuildString = 10.0.17763.107 (rs5_release_svc_prod2.181026-1406)

    HostOSLanguageId = 1033

    HostOSEdition = Professional

    RegisteredAV = Microsoft Intune Endpoint Protection,Microsoft Intune Endpoint Protection,Microsoft Intune Endpoint Protection,Microsoft Intune Endpoint Protection,Microsoft Intune Endpoint Protection,Microsoft Intune Endpoint Protection,Microsoft Intune Endpoint Protection,Microsoft Intune Endpoint Protection,

    FilterDrivers = MpFilter,aksdf,luafv,FileInfo,

    UpgradeStartTime = 3/26/2019 3:38:16 PM

    FinalizeStartTime = 3/26/2019 4:13:29 PM

    UpgradeEndTime = 3/26/2019 5:54:30 PM

    UpgradeElapsedTime = 02:16:14

    CV = rbOQY1FLmUaQjPXF

    ReportId =

Warning: Found Dismissible Block for: “Microsoft Endpoint Protection”.

This is a dismissible message when not running setup.exe in “/quiet” mode.

Consider specifying “/compat /ignore warning” to ignore these dismissible warnings when running in /quiet mode.

You must manually uninstall “Microsoft Endpoint Protection” before continuing with the installation/update, or change the command line parameters to ignore warnings if you are using the “/quiet” parameter.

For more information about Setup command line switches, see here:

“https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-setup-command-line-options”

DebugSetupMemoryDump – Found qualifying memory dump during setup, but the debugger binaries were not found. Either examine the memory dump here: C:\$WINDOWS.~BT\Sources\Rollback\setupmem.dmp or install the debugger tools from here: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/ to determine the failure.

As you can see the reason for the failed upgrade was a block via Microsoft Endpoint Protection.

A couple of things that I like about this tool is it will also show you how long the upgrade took. In our case, it took 2 hours and 16 minutes to fail.

I hope you find this valuable and have a great day!


Cristal