Windows 11 Trying to upgrade from 29617 to 29639 and getting multiple errors I can't fix

ProfPieHunter · 2026-08-01T15:26:22-0400

Getting the following errors using both WU and ISO. Can't factory reset either. Have two SSDs and both have 1.64 TB of 1.86 TB and 1.51 of 1.86 TB free. I've followed all kinds of steps and can't get this fixed. Not sure what else to do and worried about the certificate expiring on 8/11.

WindowsForum AI · 2026-08-01T15:29:00-0400

Hi ProfPieHunter. This is not a free-space problem. Your screenshots show two related failures:

Windows Update: 0x80070005 — access denied/permissions failure.
ISO Setup: 0x80070057-0x20003 during SAFE_OS / INSTALL_UPDATES.

Build 29634, released July 27, contains the renewed flight certificate, and build 29639 was released July 31. Installing either 29634 or later should address the certificate expiring on August 11, 2026. Others are reporting similar 0x80070005 failures with 29639, so this may not be unique to your PC.
Do not factory-reset yet. A reset uses some of the same servicing/recovery components and may fail for the same reason.

Recommended procedure

1. Prepare the computer

Back up anything irreplaceable.
Create a restore point.
Suspend BitLocker/device encryption if enabled.
Completely uninstall any third-party antivirus, VPN, or system-tuning software.
Disconnect unnecessary USB devices.
If practical, temporarily disconnect the second SSD, leaving only the Windows SSD connected. This prevents Setup from selecting recovery or boot partitions on the wrong drive.
Perform a clean boot.

2. Repair Windows servicing

Open Terminal (Admin) and run these individually:

Code:

DISM /Online /Cleanup-Image /StartComponentCleanup
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
chkdsk C: /scan

Restart afterward. Please note whether DISM or SFC reports anything it cannot repair.

3. Rebuild the Windows Update cache

Open Command Prompt as administrator:

Code:

net stop bits
net stop wuauserv
net stop cryptsvc
net stop msiserver

ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old

net start msiserver
net start cryptsvc
net start wuauserv
net start bits

If an .old folder already exists, rename it to something such as .old2. Restart Windows.

4. Retry the ISO without Dynamic Update

This is important because your ISO failure occurred specifically during INSTALL_UPDATES.

Use a 29639 ISO matching your current edition, architecture, and display language.
Mount the ISO inside Windows.
Disconnect the Internet.
Open Terminal (Admin).
Run the following, replacing D: with the mounted ISO’s drive letter:

D:\setup.exe /DynamicUpdate Disable

Choose Keep personal files and apps.

Microsoft documents /DynamicUpdate Disable specifically to prevent Setup from downloading and installing additional updates during the upgrade.

5. If it rolls back again, collect the Setup logs

Please do not run more permission-reset utilities yet. Upload these folders or their relevant logs:

Code:

C:\$WINDOWS.~BT\Sources\Panther
C:\$WINDOWS.~BT\Sources\Rollback

The most useful files are:

Code:

setupact.log
setuperr.log
setupapi.dev.log
SetupDiagResults.xml

You can create a ZIP from an elevated PowerShell window:

Compress-Archive -Path 'C:\$WINDOWS.~BT\Sources\Panther\*','C:\$WINDOWS.~BT\Sources\Rollback\*' -DestinationPath "$env:USERPROFILE\Desktop\SetupLogs.zip" -Force

The logs should identify the exact file, driver, registry key, or partition returning access denied. Because old-certificate builds can eventually become stuck and stop receiving flights, I would aim to resolve this several days before August 11, but you still have a recovery path through an ISO if Windows Update remains broken.

ProfPieHunter · 2026-08-01T15:59:24-0400

All steps have done nothing. When the update restarts the computer, "preparing for recovery" comes up. Also does nothing. I've attached the ZIP. I have no idea what I'm looking for.

WindowsForum AI · 2026-08-01T16:00:43-0400

Thanks, ProfPieHunter. You did nothing wrong with the ZIP, but it expands to about 376 MB, which exceeds the analyzer’s safe processing limit. It likely contains large trace/ETL files that we do not need.
The “Preparing for recovery” message means Setup has entered rollback/WinRE. Since Reset also fails, the recovery environment or disk layout could be involved—but let’s identify the exact failure before changing anything else.

Create a smaller diagnostic ZIP

Open PowerShell as Administrator.
Paste the entire script below:

Code:

$Out = "$env:USERPROFILE\Desktop\UpgradeLogSmall"
Remove-Item $Out -Recurse -Force -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Path $Out | Out-Null

$Targets = @(
    'C:\$WINDOWS.~BT\Sources\Panther\setupact.log',
    'C:\$WINDOWS.~BT\Sources\Panther\setuperr.log',
    'C:\$WINDOWS.~BT\Sources\Panther\setupapi.dev.log',
    'C:\$WINDOWS.~BT\Sources\Panther\SetupDiagResults.xml',
    'C:\$WINDOWS.~BT\Sources\Rollback\setupact.log',
    'C:\$WINDOWS.~BT\Sources\Rollback\setuperr.log',
    'C:\$WINDOWS.~BT\Sources\Rollback\setupapi.dev.log',
    'C:\Windows\Panther\setupact.log',
    'C:\Windows\Panther\setuperr.log',
    'C:\Windows\Logs\MoSetup\BlueBox.log',
    'C:\Windows\Logs\SetupDiag\SetupDiagResults.xml'
)

foreach ($Target in $Targets) {
    Get-Item $Target -ErrorAction SilentlyContinue | ForEach-Object {
        $Name = $_.FullName -replace '^C:\\','' -replace '[\\:$]','_'
        Copy-Item $_.FullName (Join-Path $Out $Name) -Force
    }
}

& reagentc.exe /info |
    Out-File "$Out\reagentc.txt"

Get-Disk |
    Format-List Number,FriendlyName,OperationalStatus,PartitionStyle,IsBoot,IsSystem |
    Out-File "$Out\disks.txt"

Get-Partition |
    Sort-Object DiskNumber,PartitionNumber |
    Format-Table DiskNumber,PartitionNumber,DriveLetter,Type,Size,IsBoot,IsSystem -AutoSize |
    Out-File "$Out\partitions.txt"

Compress-Archive -Path "$Out\*" `
    -DestinationPath "$env:USERPROFILE\Desktop\UpgradeLogSmall.zip" -Force

Wait for the prompt to return.
Attach UpgradeLogSmall.zip from your Desktop.

That ZIP should be only a few megabytes. It will include the final Setup errors, rollback activity, WinRE status, and both SSDs’ partition layouts.
For now, do not run another permissions reset, factory reset, or delete the recovery partition. The next step depends on whether the logs show a WinRE failure, an EFI/recovery partition on the second SSD, a specific driver, or a genuine build 29639 Setup bug.

ProfPieHunter · 2026-08-01T16:04:58-0400

Attached.

WindowsForum AI · 2026-08-01T16:05:26-0400

Thanks. Unfortunately, one or more individual logs—probably setupapi.dev.log—are enormous. The new archive still expands to approximately 148 MB, so the analyzer rejected it. You do not need to run the update again.

Create small text excerpts

Open PowerShell as Administrator.
Paste this entire script:

Code:

$Out = "$env:USERPROFILE\Desktop\UpgradeExtracts"
$Zip = "$env:USERPROFILE\Desktop\UpgradeExtracts.zip"

Remove-Item $Out -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item $Zip -Force -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Path $Out | Out-Null

$Logs = @(
    'C:\$WINDOWS.~BT\Sources\Panther\setupact.log',
    'C:\$WINDOWS.~BT\Sources\Panther\setuperr.log',
    'C:\$WINDOWS.~BT\Sources\Panther\setupapi.dev.log',
    'C:\$WINDOWS.~BT\Sources\Rollback\setupact.log',
    'C:\$WINDOWS.~BT\Sources\Rollback\setuperr.log',
    'C:\$WINDOWS.~BT\Sources\Rollback\setupapi.dev.log',
    'C:\Windows\Panther\setupact.log',
    'C:\Windows\Panther\setuperr.log',
    'C:\Windows\Logs\MoSetup\BlueBox.log'
)

foreach ($Log in $Logs) {
    if (Test-Path $Log) {
        $Name = $Log -replace '^C:\\','' -replace '[\\:$]','_'

        Get-Content $Log -Tail 8000 -ErrorAction SilentlyContinue |
            Out-File "$Out\TAIL_$Name.txt"

        Select-String -Path $Log -Pattern `
            '0x80070005|0x80070057|0x20003|error|failed|failure|rollback|WinRE|recovery|access denied|SAFE_OS|INSTALL_UPDATES' `
            -ErrorAction SilentlyContinue |
            Select-Object -Last 3000 |
            ForEach-Object { $_.Line } |
            Out-File "$Out\ERRORS_$Name.txt"
    }
}

$Results = @(
    'C:\$WINDOWS.~BT\Sources\Panther\SetupDiagResults.xml',
    'C:\Windows\Logs\SetupDiag\SetupDiagResults.xml'
)

foreach ($Result in $Results) {
    if (Test-Path $Result) {
        $Name = $Result -replace '^C:\\','' -replace '[\\:$]','_'
        Copy-Item $Result "$Out\$Name" -Force
    }
}

& reagentc.exe /info |
    Out-File "$Out\reagentc.txt"

Get-Disk |
    Format-List Number,FriendlyName,OperationalStatus,PartitionStyle,IsBoot,IsSystem |
    Out-File "$Out\disks.txt"

Get-Partition |
    Sort-Object DiskNumber,PartitionNumber |
    Format-Table DiskNumber,PartitionNumber,DriveLetter,Type,Size,IsBoot,IsSystem -AutoSize |
    Out-File "$Out\partitions.txt"

Compress-Archive -Path "$Out\*" -DestinationPath $Zip -Force

Attach the resulting UpgradeExtracts.zip from your Desktop.

This version contains only the final portions and matching error lines, not the complete 148 MB logs. It should be small enough to inspect and should expose the exact rollback trigger.

ProfPieHunter · 2026-08-01T16:08:56-0400

Attached.

Mike · 2026-08-01T16:38:32-0400

Update from the site owner: this was our bug, not your uploads.

@ProfPieHunter — thank you for your patience, and I'm sorry for the run-around. You supplied good diagnostic data three times and our assistant failed to read it three times. Everything it told you about your archives being "too large" was misleading, and the total silence after your last upload was a crash on our end, not a decision to ignore you.

I went through the server logs for this thread tonight and found four separate defects in how the assistant handles file attachments. All four are being fixed right now.

1. Logs written by PowerShell were being read as gibberish

Windows PowerShell writes text files in UTF-16 by default. Our attachment reader treated the byte pattern that produces as an unreadable binary blob and discarded the file before the assistant ever saw it. Every single log file our own instructions told you to generate was thrown away on arrival.

This was not specific to you. It has silently broken every log bundle any member has ever produced with a PowerShell collection script here — which is the exact thing our assistant keeps asking people to run. Text encoding is now detected properly and converted before anything else happens.

2. One huge file inside an archive discarded all the small ones

Our size limit was applied to the archive as a whole rather than file by file. Your second upload came to roughly 148 MB unpacked — but around 147 MB of that was a single log file. The remaining eight files totalled about half a megabyte and included the one short diagnostic report that names your failure exactly. All of them were rejected because of the one oversized sibling.

That limit is being replaced with a per-file budget that works smallest-file-first: oversized members get skipped and named in the summary, everything else gets read. Under this fix your very first upload would have been answerable and this thread would have ended at the second reply.

3. One file type killed the request outright

Your last archive contained a small diagnostic report that our code labelled with a content type the AI service refuses to accept. That refusal rejected the entire request rather than just the one file, which is why you received no reply at all instead of an error message. Text-based files are now all sent under a single, universally accepted type, which removes this whole class of failure rather than just the one case that bit you.

4. No overall budget when reading inside an archive

Even with the three problems above fixed, your last archive would have expanded to roughly 880,000 tokens of text — more than double what the model can hold at once — and failed again for a fourth reason. There is now a combined reading budget across the whole archive, spent smallest-file-first, because the small files are almost always the ones carrying the answer.

Two more changes

The assistant will no longer go silent. If a request is rejected for any reason to do with the attached files, it now retries once without them, so you get a reply and an explanation instead of nothing at all.
Long logs are now trimmed from the middle, not the end. Windows Setup writes the actual failure on the last lines of its logs, and we were cutting off precisely that part.

What you need to do

Nothing. Please don't re-run any scripts or upload anything further. The archive you already posted contains the diagnostic report that identifies your failure precisely — it was sitting there the whole time, and it is the file that crashed the request. Once the fix is deployed I will have the assistant re-read that exact upload and reply here properly.

I'll follow up in this thread when it's live. Your certificate deadline is noted and there's time.

WindowsForum AI · 2026-08-01T16:39:10-0400

Thank you, Mike, for investigating and explaining the failures clearly.
@ProfPieHunter, I’m sorry for repeatedly sending you through unnecessary log-collection steps. Your uploads and diagnostic work were valid; the failures were entirely on our side.
Please follow Mike’s instruction: do not rerun anything or upload another archive. Once the attachment fixes are deployed, I’ll analyze your existing upload and continue from the actual SetupDiag result.

Mike · 2026-08-01T16:46:56-0400

The attachment fixes are deployed and live.

@WindowsForum AI — please read the archive ProfPieHunter attached earlier in this thread now (attachment id 175273) using processAttachments, and give him a full analysis based on what the setup logs and the SetupDiag report actually say. Lead with the specific failure they identify, then the fix. Do not ask him/her for any further logs.

WindowsForum AI · 2026-08-01T16:48:33-0400

@ProfPieHunter — I can now read the archive properly. Your storage, SSD layout, and recovery partition are not causing this.

Specific failure

SetupDiag identifies the fatal error as:

Code:

0x80070005-0x2000A

Last phase: Safe OS
Last operation:
Relocate OS from C:\$WINDOWS.~BT\NewOS to C:\

Operation failed: 0x80070005
Additional status: 0x000000B7

This means Setup successfully prepared the new Windows installation, restarted into Safe OS, and then failed at the point where it was supposed to replace the existing operating-system directories with the new ones.
0x80070005 means access denied, while 0xB7 means an object already exists. The ISO message saying INSTALL_UPDATES was therefore somewhat misleading—the decisive failure occurred during the final OS-directory relocation.

This appears to be a build problem

Another Insider has reported the identical 29639 failure, including the same operation, error combination, and 0xB7 status. Other users on different manufacturers’ hardware have confirmed it, and a Windows Insider team representative replied that Microsoft is investigating. (reddit.com)
That is important because it means this is not simply a permissions problem unique to your computer. Repeated ACL resets, factory resets, driver removals, or clean-up scripts are unlikely to solve this particular flight regression.

What the remaining logs show

Both Samsung SSDs are online and GPT formatted.
Disk 0 correctly contains the EFI, Windows, and Recovery partitions.
Disk 1 is a normal data disk and is not incorrectly marked as the system disk.
The EFI partition is approximately 260 MB.
The Recovery partition is approximately 850 MB.
Windows RE is enabled and registered on Disk 0, Partition 4.
Windows RE reports version 10.0.29617.1000 and a successful configuration.
There was no bugcheck or hardware crash.
The driver-store and migration warnings occur before the failure, but SetupDiag does not identify them as the rollback trigger.
Setup also had trouble removing the stale HKLM\SYSTEM\Setup\Upgrade registry tree, but that is secondary to the OS-relocation failure.

The “Preparing for recovery” screen was Windows Setup initiating its rollback. It does not mean your Recovery partition is missing.

Recommended fix

The safest fix is to wait for Microsoft’s corrected build rather than perform destructive repairs.

Do not factory-reset or clean-install at this point.
Do not repartition either SSD or disconnect the second internal SSD.
Do not manually change permissions on C:\Windows, C:\Program Files, or C:\ProgramData.
Back up important personal files because this remains an Experimental build.
Stop retrying build 29639 until Microsoft releases a newer flight or confirms that the deployment issue is fixed.
When a newer fixed build appears, restart Windows first.
Open Settings → System → Storage → Temporary files.
Remove Temporary Windows installation files and Windows Update Cleanup, if offered.
Restart again and install the newer build through Windows Update.

I would not manually delete C:\$WINDOWS.~BT or the HKLM\SYSTEM\Setup\Upgrade key yet. Your logs show Setup completed its rollback and removed NewOS; forcing further offline deletion introduces more risk without addressing what now appears to be a Microsoft-side build defect.

About the August 11 certificate deadline

For Experimental/Future Platforms, build 29634.1000 or later contains the renewed certificate. Any newer corrected build will therefore satisfy the requirement. (blogs.windows.com)
Also, August 11, 2026 is not an immediate “computer stops booting” deadline. Microsoft says that if it is missed, the old build will display expiration notifications and old-certificate builds stop being offered; installing a newer renewed-certificate build restores the update path. It does not affect Windows activation or licensing. (learn.microsoft.com)
Bottom line: your logs match an actively investigated 29639 deployment failure. Your disks, free space, partition layout, and WinRE configuration look normal. Waiting for the corrected flight is safer than making further system-level changes.

Mike · 2026-08-01T16:52:19-0400

ProfPieHunter said:
Attached.

Well at least one bug was fixed, but not this one. Strange issue to say the least

Navigation section

Windows 11 Trying to upgrade from 29617 to 29639 and getting multiple errors I can't fix

Member

Attachments

AI

Recommended procedure​

1. Prepare the computer​

2. Repair Windows servicing​

3. Rebuild the Windows Update cache​

4. Retry the ISO without Dynamic Update​

5. If it rolls back again, collect the Setup logs​

Member

Attachments

AI

Create a smaller diagnostic ZIP​

Member

Attachments

AI

Create small text excerpts​

Member

Attachments

Windows Forum Admin

1. Logs written by PowerShell were being read as gibberish​

2. One huge file inside an archive discarded all the small ones​

3. One file type killed the request outright​

4. No overall budget when reading inside an archive​

Two more changes​

What you need to do​

AI

Windows Forum Admin

AI

Specific failure​

This appears to be a build problem​

What the remaining logs show​

Recommended fix​

About the August 11 certificate deadline​

Windows Forum Admin

Recommended procedure

1. Prepare the computer

2. Repair Windows servicing

3. Rebuild the Windows Update cache

4. Retry the ISO without Dynamic Update

5. If it rolls back again, collect the Setup logs

Create a smaller diagnostic ZIP

Create small text excerpts

1. Logs written by PowerShell were being read as gibberish

2. One huge file inside an archive discarded all the small ones

3. One file type killed the request outright

4. No overall budget when reading inside an archive

Two more changes

What you need to do

Specific failure

This appears to be a build problem

What the remaining logs show

Recommended fix

About the August 11 certificate deadline