Navigation section

Ongoing 20H2 problem fix or force compuer to stop updating permanently

T

Tim81499

New Member
Joined
Feb 23, 2026
Messages
8
Hi All.

I've been fighting with 20H2 since it first downloaded. It fails the update every time. I've done everything to fix it that I can find on the internet including re-installing windows 10. This is an ASUS GL503V laptop.

So, right in the middle of doing anything with the laptop it will come up with the blue display saying it's time to reboot to install the update. I cannot make it stop.

So I've tried just completely disabling the update process, again with data found on the internet, and it will work for a day or so then up comes the blue screen.

I need the update process shut down totally. This is a good laptop, much faster than the new one I bought, and I want to use it for a music service that I'm involved in.

How do I either get the 20H2 to install or how do I permanently shut down the update process.

Thank You.
 

Hi Tim — a couple key points first:
1) Windows 10 version 20H2 is very old and is out of support (and Windows 10 itself is out of support as of October 14, 2025). So if your machine is still trying to install 20H2 in February 2026, something is “stuck” in Windows Update (pending update loop) or your install source/management policy is unusual.
2) That blue “time to reboot” screen is typically a pending reboot/update deadline behavior. We can stop the interruptions immediately, and then either fix Windows Update properly (best), or block updates as much as Windows allows.
Below are the most effective steps, in the order I’d do them.

A) Stop the forced reboot prompts immediately (so you can use the laptop)​

1) Set Active Hours + restart notifications​

Go to:
  • Settings → Update & Security → Windows Update
    • Change active hours (set it as wide as it allows)
    • Advanced options → turn on restart notifications (wording varies by build)
This won’t fix the underlying failure, but it usually stops Windows from interrupting you mid-task.

2) If you have Windows 10 Pro: set “Notify” (no auto-download/install)​

  1. Press Win + R, type gpedit.msc
  2. Go to:
    Computer Configuration → Administrative Templates → Windows Components → Windows Update → Manage end user experience
  3. Set:
    • Configure Automatic Updates = Enabled → option 2 - Notify for download and auto install
    • No auto-restart with logged on users… = Enabled
(If you have Windows 10 Home, tell me and I’ll give the registry equivalent.)

B) Fix the update loop (recommended)​

Even if you ultimately want to reduce updates, you’ll usually need to clear the broken/pending update state first.

1) Get the error code (very important)​

Please check:
  • Settings → Update & Security → Windows Update → View update history
  • Find the failed “Feature update to Windows 10, version 20H2” entry and tell me the error code (example: 0x80070002, 0xC1900101, etc.)
Also press Win + R → type winver and tell me your Version and OS Build.

2) Reset Windows Update components (safe + commonly fixes this)​

  1. Open Command Prompt (Admin) or Windows Terminal (Admin)
  2. Run these commands:
Code: 
net stop wuauserv
net stop bits
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 bits
net start wuauserv
  1. Reboot the PC.
  2. Try Windows Update again.

3) Repair Windows system files​

In Terminal/Command Prompt (Admin):
Code: 
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
Reboot afterward.

4) Bypass the broken “20H2” offer by doing an in-place upgrade to the newest Win10 build (or Win11)​

Because 20H2 is obsolete, the cleanest repair is usually an in-place upgrade repair install using a newer installer.
  • If the laptop supports it, Windows 11 is the better long-term answer in 2026.
  • If you must stay Windows 10, go straight to Windows 10 22H2 (still out of support, but at least it tends to install cleanly and won’t keep chasing 20H2).
Method: mount an ISO and run setup.exe, choose Keep personal files and apps.
If you tell me your current winver details, I’ll point you to the exact best path for your starting version.

C) If you truly want updates “shut down totally” (not recommended, but doable-ish)​

Windows is designed to resist permanent disabling, but here are realistic options:

Option 1 (best “permanent”): Keep it offline​

If this laptop is a dedicated music/service machine, the only truly reliable way is:
  • Don’t connect it to Wi‑Fi / Ethernet
    (or connect only when you decide to update manually)

Option 2: Metered connection (limits most downloading)​

  • Settings → Network & Internet → Wi‑Fi → (your network) → Metered connection = ON

Option 3: Disable Windows Update service (often gets re-enabled later)​

  • services.msc → Windows Update → Startup type Disabled
Note: Windows Update Medic / Orchestrator can re-enable updates later, which matches what you’re seeing (“works for a day or so then comes back”).

Quick questions so I can give you the exact fix​

1) What does winver show right now (Version + OS Build)?
2) What error code shows in View update history for the 20H2 failure?
3) Are you on Windows 10 Home or Pro?
4) Approximately how much free space is on C: (roughly)?
Answer those and I’ll tell you the most direct “do this, then this” path to either (a) get it updated cleanly, or (b) stop the interruptions without breaking the system.
 

Here is something I found that may help, but I want to be very clear up front: these are advanced methods and can cause severe problems if used incorrectly. I strongly recommend doing a deep dive and understanding the trade‑offs before attempting any of them. I do not do this, and I do not suggest anyone else do this, but there is a way.

The article explains a technique to effectively pause Windows Updates long‑term by changing how Windows interprets the “pause until” date, rather than relying on the normal short pause window in Settings. This goes beyond standard options like pausing updates for a few weeks and typically involves policy or registry‑level changes, which Windows does not expect most consumers to use long‑term.

Important things to understand before considering this approach:

  • These methods are not officially supported as a permanent solution.
  • Misconfiguring policy or registry values can:
    • break Windows Update entirely
    • prevent security patches from installing
    • cause future feature updates to fail or require repair installs
  • If updates are disabled too aggressively, Windows can attempt recovery actions later that are far more disruptive than normal updates.
For many users, safer alternatives include: (assuming you haven't already tried)

  • using the built‑in Pause Updates option for short periods,
  • setting the network as metered to delay large downloads,
  • or, on Pro/Enterprise editions, configuring update behavior through Group Policy rather than hard stops.
If you decide to explore long‑term pause methods like the one described here, treat it as a temporary workaround, document what you changed, and be prepared to reverse it later.

Article for reference (read carefully before proceeding): Use This Trick to Permanently Pause Windows Updates

That said, I want to emphasize that the methods discussed there are advanced and potentially risky. Making deep changes to update behavior (policy/registry level) can have unintended side effects and, if misconfigured, may destabilize the system or create security issues.

Since this sounds like an important music service and data integrity matters, a potentially safer long‑term approach might be to avoid forcing Windows into unsupported states altogether. You may want to consider dual‑booting Linux (for example, Pop!_OS or Ubuntu) and migrating or running the service there instead.

A dual‑boot setup:

  • Keeps your existing Windows installation intact
  • Avoids aggressive update suppression or registry hacks
  • Provides a stable, well‑supported environment for audio and service workloads
  • Lets you migrate gradually without derailing your current setup
Linux distributions like Pop!_OS and Ubuntu are widely used for creative and audio workloads, and this approach reduces the risk of breaking Windows Update or the OS itself.

If you do decide to explore the Windows update workaround, treat it as temporary, document every change, and be prepared to reverse it. For critical services, isolation and migration are often safer than fighting the update system directly.
 

You’re right to flag that as “advanced and risky.” The bigger issue, though, is why you’re being pushed so hard to update in the first place:
  • Windows 10, version 20H2 has been out of servicing for a long time: May 10, 2022 for Home/Pro (and related Pro variants), and May 9, 2023 for Enterprise/Education/IoT Enterprise.
  • Windows 10 overall reached end of support on October 14, 2025. As of today (Feb 23, 2026), normal security updates for Windows 10 are no longer provided unless you’re on an ESU path.
That context matters because registry/policy “pause-until” tricks tend to fail (or cause breakage) precisely when Windows is trying to remediate an out-of-service build.

About the “permanent pause” registry trick​

I’m not going to walk you through that method step-by-step, because “effectively disabling updates long-term” can leave you stuck without security fixes and can also break Windows Update servicing in ways that force a repair install later—exactly the risk you already called out.
Even when it “works,” Windows often:
  • ignores extreme pause dates later,
  • resets them after servicing stack changes,
  • or attempts remediation actions that are more disruptive than regular updating.

Safer, supported ways to regain control (without breaking servicing)​

What you can do depends on your edition and what you mean by “stop updating”:

If your goal is stop feature upgrades (but keep security fixes)​

Best practice (Pro/Enterprise):
  • Use Group Policy / Windows Update for Business controls to defer feature updates and manage timing/rings (instead of hard-stopping WU).
Also: if you’re on Windows 10, note that 22H2 was the final Windows 10 release, so “feature update pressure” is mostly about getting you off 20H2 and onto a supported baseline (historically 22H2).

If your goal is stop all updates​

That’s never a good idea for an internet-connected machine—especially for something you called an “important music service.” The safer pattern is:
  • stabilize the system (freeze feature changes),
  • control timing of quality/security updates,
  • and keep a rollback plan (image backups).

The practical path forward in 2026 (given Windows 10 support ended)​

You essentially have three realistic options:
1) Move to a supported OS path (usually Windows 11 if hardware allows).
2) If you must stay on Windows 10, look into Microsoft’s ESU program options (so you’re not running unpatched after Oct 14, 2025).
3) Isolate the workload (your Linux dual-boot idea, or a dedicated machine/VM for the service) so Windows updates can’t disrupt it.

Quick questions (so I can give the right steps)​

1) What are you actually running right now—Windows 10 20H2 (what OS build number?) or something else? (winver will show it)
2) When updates happen, what breaks specifically (audio driver, DAW, latency, a service won’t start, etc.)? Any error codes?
3) Which edition: Home / Pro / Enterprise?
If you answer those, I can suggest a supported “freeze feature changes + control quality updates” setup that matches your edition—without using brittle registry hacks that can brick Windows Update.
 

Another option worth considering is running a Windows 11 virtual machine on the existing Windows 10 system. While this doesn’t directly fix the underlying update or stability issue on the host OS, it can provide the application with a more controlled and predictable environment.

Using a VM:
  • Isolates the app from host‑level Windows Update behavior
  • Reduces the risk of updates interrupting or breaking the service
  • Allows snapshots and rollbacks if something goes wrong
  • Keeps the primary Windows 10 installation unchanged

This can be especially useful for critical services where uptime and consistency matter more than native performance. That said, it does add some overhead and complexity, and it’s best viewed as a containment or stabilization strategy, not a long‑term solution to the update model itself.
Between registry‑level update suppression, dual‑booting Linux, and virtualization, the VM approach sits in the middle: safer than deep system tweaks, less disruptive than a full OS migration, but still not addressing the root cause.
 

Running a Windows 11 VM on your existing Windows 10 install can be a good “containment/stabilization” move—especially if your main pain is that updates or software drift keep breaking a specific app/service. But it’s important to be clear about what it does and doesn’t solve.

What a Windows 11 VM helps with​

  • Predictable app environment: you control the guest OS configuration and when/if it updates.
  • Snapshots/rollback: you can revert after a bad update or config change.
  • Isolation from host app clutter: the VM can stay “clean” even if the host is messy.

What it does not solve (big limitations)​

  • Host OS risk remains: if Windows 10 on the host is unstable or compromised, the VM can still be impacted (a compromised host can read/modify VM disk files, intercept traffic, etc.).
  • Performance/latency overhead: for anything audio/real-time (DAW, low-latency drivers), VMs are often a poor fit unless you’re doing something more “service-like” (file serving, streaming, automation, office apps).
  • Hardware passthrough is limited: USB devices can be forwarded; GPUs are possible in some hypervisors but not “simple/guaranteed.”

Feasibility checklist (before you invest time)​

1) CPU virtualization support enabled in BIOS/UEFI
  • Intel VT-x / AMD-V must be enabled.
    2) Enough RAM
  • Practical minimum: 16 GB host RAM if you want the VM to be comfortable (e.g., 6–8 GB for the VM).
    3) Enough SSD space
  • Plan for 80–150 GB free for the VM (more if the app stores data).
    4) Hypervisor choice (depends on your Windows edition and needs)
  • Windows 10 Pro/Enterprise: Hyper‑V is built in and stable.
  • Windows 10 Home: usually VirtualBox or VMware Workstation Player (third-party).

The Windows 11 “TPM/Secure Boot” VM snag (common gotcha)​

Windows 11 typically expects TPM 2.0 + Secure Boot. Many VM platforms can provide this, but:
  • Hyper‑V: easiest if your host supports it; you create a Generation 2 VM and enable the VM security features (vTPM/Secure Boot).
  • VirtualBox / VMware: possible, but the exact steps depend on version/features and can be more fiddly.
If you can’t provide TPM/Secure Boot to the guest, you may end up in “workarounds,” which usually defeats the point of “controlled and predictable.”

Recommended “safe middle path” setup (if your goal is stability)​

  • Keep the host as minimal as possible (drivers, storage, networking stable).
  • Put your “important music service/app” inside the Windows 11 VM.
  • Disable auto-updates in the VM (or at least schedule them), then update only after a snapshot.
  • Use snapshots like release checkpoints:
    • “Known-good baseline”
    • “After installing app”
    • “After monthly patching”

Two quick questions so I can suggest the best VM route​

1) What edition is the host OS: Windows 10 Home or Pro?
2) What is the “music service” workload—real-time audio (DAW/ASIO), or more like a server/service (streaming, library management, automation)?
With that, I can recommend the best hypervisor (Hyper‑V vs VirtualBox vs VMware), the right VM settings (CPU/RAM/storage/network mode), and whether this will realistically meet your stability/performance needs.
 

Before jumping into any of these solutions, I’d strongly recommend taking a step back and doing some deliberate research on your specific system first. Many of the approaches being discussed (registry edits, service disabling, forced update blocks, etc.) are not universally safe and can make things worse if applied blindly.

The best next step is to create a checklist for your particular machine and situation before choosing a route. For example:

  1. Windows version and build (Home vs Pro, 20H2 specifics, support state)
  2. Hardware age and drivers (especially chipset, audio, and storage)
  3. Whether the issue is feature updates, security updates, drivers, or all of the above
  4. How critical uptime and stability are versus staying fully patched
  5. Whether this system hosts critical apps or data
  6. Your tolerance for workarounds vs clean separation (dual‑boot, VM, migration)

Once that’s clear, you can evaluate options in order of risk, starting with the least invasive (supported pause/settings, metered connection, policy‑based controls) before considering more aggressive methods. Skipping that evaluation phase and “attacking” an implementation directly is how systems end up broken, insecure, or stuck in an unsupported state.
There isn’t a single correct answer here—there’s only the right approach for your system and use case. Taking the time to map that out first will save you far more time and frustration later.
 

That’s the right approach. With Windows Update issues (especially on older Windows 10 builds like 20H2), the fastest way to avoid making things worse is to collect a small set of facts first, then pick the lowest-risk path that meets your uptime/security needs.
Below is a practical checklist template you (or anyone following the thread) can use. If you post the answers back, we can usually narrow it down to a safe plan in 1–2 replies.

1) Identify exactly what you’re running​

A. Version / edition / build​

Press Win + R → winver and note:
  • Windows version (e.g., Windows 10 / Windows 11)
  • Version (e.g., 20H2 / 22H2)
  • OS Build number
Also: Settings → System → About
  • Edition: Home / Pro / Enterprise
  • “Experience” info

B. Support state / constraints​

  • Are you intentionally staying on Windows 10?
  • Is this machine allowed to move to Windows 11 (TPM/CPU), or is that a hard “no”?

2) Define what is actually “breaking”​

There’s a huge difference between these failure modes:
  • Feature update problem (e.g., 20H2 → newer release fails)
  • Quality/security updates failing (monthly cumulative updates fail)
  • Driver updates breaking things (audio/chipset/GPU/storage)
  • Update installs fine but the machine becomes unstable after reboot
  • Updates interrupt uptime (reboots / downtime are the main issue)

What to capture​

  • The exact error code (Windows Update page or Event Viewer)
  • The last failed update KB number
  • Whether it fails at download, install, or reboot/configure

3) Hardware + driver risk factors (the usual culprits)​

These three categories cause most “updates broke my system” stories:

A. Storage / disk health​

  • Free space on C: (aim for 25–30 GB free for upgrades)
  • If possible: SMART status (or at least “any disk errors?”)

B. Audio stack (since you mentioned music workloads)​

  • Audio interface model (USB/PCIe), driver version
  • ASIO driver or vendor control panel involved?
  • Any “enhancement” software (Nahimic, Sonic Studio, DTS, etc.)

C. Chipset + storage controller​

  • Motherboard/laptop model
  • Storage mode (AHCI/RAID) if known
  • Any Intel RST / AMD RAID drivers?

4) Uptime vs patching: pick your “operating posture”​

Answer these two questions:
1) Is this PC internet-facing daily?
2) Is uptime more important than being fully patched?
Typical safe postures:
  • Stable + still patched: defer feature upgrades, control reboot timing, keep security updates
  • Airgapped/isolated stability: network isolation + controlled patch windows (still risky, but manageable)
  • “No updates ever”: not recommended unless truly isolated—and even then, it becomes a security and recovery planning problem

5) Choose the least invasive control method (in order)​

1) Supported controls (Active hours, restart scheduling, pause short-term, metered connection for big downloads)
2) Policy-based controls (Pro/Enterprise): defer feature updates, manage update rings, block driver updates if that’s the trigger
3) Containment: Windows 11 VM / dual-boot Linux / separate machine for the critical workload
4) Last resort: deep registry/service blocks (high chance of future repair installs, broken servicing, or security exposure)

6) Quick “data pack” you can post here (best next step)​

If you want, reply with this filled in:
  • winver output (version + OS build):
  • Edition (Home/Pro):
  • What exactly happens (symptom + when):
  • Error code / failed KB:
  • CPU + RAM:
  • Disk type (SSD/HDD) + free space on C::
  • Audio device/interface + driver version:
  • Any third-party AV or “tweaker” tools:

One important note (so expectations are realistic)​

If you truly are on Windows 10 20H2, you’re fighting an uphill battle because it’s been out of servicing for a long time—Windows will keep trying to move you forward one way or another. In many cases, the “fix” isn’t to block updates harder, it’s to get to a stable supported baseline (or isolate the workload with a VM/dual-boot).
Post your winver + the last failed KB/error code and we can recommend the safest route for your exact scenario.
 

ChatGPT said:
Hi Tim — a couple key points first:
1) Windows 10 version 20H2 is very old and is out of support (and Windows 10 itself is out of support as of October 14, 2025). So if your machine is still trying to install 20H2 in February 2026, something is “stuck” in Windows Update (pending update loop) or your install source/management policy is unusual.
2) That blue “time to reboot” screen is typically a pending reboot/update deadline behavior. We can stop the interruptions immediately, and then either fix Windows Update properly (best), or block updates as much as Windows allows.
Below are the most effective steps, in the order I’d do them.

A) Stop the forced reboot prompts immediately (so you can use the laptop)​

1) Set Active Hours + restart notifications​

Go to:
  • Settings → Update & Security → Windows Update
    • Change active hours (set it as wide as it allows)
    • Advanced options → turn on restart notifications (wording varies by build)
This won’t fix the underlying failure, but it usually stops Windows from interrupting you mid-task.

2) If you have Windows 10 Pro: set “Notify” (no auto-download/install)​

  1. Press Win + R, type gpedit.msc
  2. Go to:
    Computer Configuration → Administrative Templates → Windows Components → Windows Update → Manage end user experience
  3. Set:
    • Configure Automatic Updates = Enabled → option 2 - Notify for download and auto install
    • No auto-restart with logged on users… = Enabled
(If you have Windows 10 Home, tell me and I’ll give the registry equivalent.)

B) Fix the update loop (recommended)​

Even if you ultimately want to reduce updates, you’ll usually need to clear the broken/pending update state first.

1) Get the error code (very important)​

Please check:
  • Settings → Update & Security → Windows Update → View update history
  • Find the failed “Feature update to Windows 10, version 20H2” entry and tell me the error code (example: 0x80070002, 0xC1900101, etc.)
Also press Win + R → type winver and tell me your Version and OS Build.

2) Reset Windows Update components (safe + commonly fixes this)​

  1. Open Command Prompt (Admin) or Windows Terminal (Admin)
  2. Run these commands:
Code: 
net stop wuauserv
net stop bits
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 bits
net start wuauserv
  1. Reboot the PC.
  2. Try Windows Update again.

3) Repair Windows system files​

In Terminal/Command Prompt (Admin):
Code: 
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
Reboot afterward.

4) Bypass the broken “20H2” offer by doing an in-place upgrade to the newest Win10 build (or Win11)​

Because 20H2 is obsolete, the cleanest repair is usually an in-place upgrade repair install using a newer installer.
  • If the laptop supports it, Windows 11 is the better long-term answer in 2026.
  • If you must stay Windows 10, go straight to Windows 10 22H2 (still out of support, but at least it tends to install cleanly and won’t keep chasing 20H2).
Method: mount an ISO and run setup.exe, choose Keep personal files and apps.
If you tell me your current winver details, I’ll point you to the exact best path for your starting version.

C) If you truly want updates “shut down totally” (not recommended, but doable-ish)​

Windows is designed to resist permanent disabling, but here are realistic options:

Option 1 (best “permanent”): Keep it offline​

If this laptop is a dedicated music/service machine, the only truly reliable way is:
  • Don’t connect it to Wi‑Fi / Ethernet
    (or connect only when you decide to update manually)

Option 2: Metered connection (limits most downloading)​

  • Settings → Network & Internet → Wi‑Fi → (your network) → Metered connection = ON

Option 3: Disable Windows Update service (often gets re-enabled later)​

  • services.msc → Windows Update → Startup type Disabled
Note: Windows Update Medic / Orchestrator can re-enable updates later, which matches what you’re seeing (“works for a day or so then comes back”).

Quick questions so I can give you the exact fix​

1) What does winver show right now (Version + OS Build)?
2) What error code shows in View update history for the 20H2 failure?
3) Are you on Windows 10 Home or Pro?
4) Approximately how much free space is on C: (roughly)?
Answer those and I’ll tell you the most direct “do this, then this” path to either (a) get it updated cleanly, or (b) stop the interruptions without breaking the system.
Click to expand...
I've actually done much of the stuff listed here. I tried using the update installer tool today for 22h2 several times today with no luck. I tried the in place reboot with no luck. I tried just installing 20h2 with no luck. Here is the error code from the 20h2 attemps. 0x80240034
There is a post above listing which says 20h2 SOLVED. Tried everything on that one with no luck. The current verison is 1809.

Still trying.
 

Tim — thanks, that detail helps a lot.

What your info means​

  • You’re on Windows 10 version 1809 (build 17763.x). That’s very old.
  • 0x80240034 is a Windows Update/download-style failure, and it commonly shows up when Windows Update components are broken or when the upgrade path is trying to pull something that’s no longer properly offered via WU. (It’s also a classic “Windows Update is not going to get you there” symptom.)
  • Trying to install 20H2 in 2026 is a dead-end. The correct target would have been 22H2 (19045), or ideally Windows 11 if the laptop supports it.
Given you’ve already tried “Update Assistant” and “in-place” and they’re failing, the next step is an offline in-place upgrade that does not rely on Windows Update downloads.

1) Do the upgrade the “offline” way (most reliable from 1809)​

This is the method that has historically solved stubborn “can’t upgrade” cases when Windows Update/Assistant won’t cooperate.

Step A — get the ISO (on another PC if needed)​

Use Microsoft’s Media Creation Tool to create an ISO (or USB) for Windows 10 22H2.

Step B — copy ISO locally + disconnect internet​

  1. Copy the ISO to the laptop (e.g. C:\ISO\Win10_22H2.iso)
  2. Unplug Ethernet / turn off Wi‑Fi (important for this attempt)
  3. Temporarily uninstall 3rd-party antivirus / “PC cleaner” / endpoint tools (disabling often isn’t enough).

Step C — clean boot (prevents driver/service interference)​

  1. Win+R → msconfig
  2. Services tab → check Hide all Microsoft services → click Disable all
  3. Startup tab → open Task Manager → disable all startup items
  4. Reboot

Step D — run Setup and block “Dynamic Update”​

  1. Right-click the ISO → Mount
  2. Run setup.exe
  3. When asked about updates, choose Not right now
If it still insists on downloading or fails early, do it from an elevated Command Prompt:
D:\setup.exe /DynamicUpdate disable
(Replace D: with the mounted ISO drive letter.)

2) If the offline upgrade fails, we need the setup logs (they pinpoint the exact blocker)​

On failure, please zip and attach these (they can be large):
  • C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
  • C:\$WINDOWS.~BT\Sources\Panther\setupact.log
  • C:\Windows\Panther\setuperr.log
  • C:\Windows\Panther\setupact.log
If C:\$WINDOWS.~BT is hidden, enable View → Hidden items in File Explorer.
Those logs will tell us if it’s:
  • a storage driver problem (common on gaming laptops),
  • a reserved/EFI partition size issue,
  • a specific driver/service blocking migration,
  • or component store corruption that requires DISM with an ISO source.

3) About “permanently shutting off updates”​

On Windows 10, Microsoft actively resists permanent disabling (you already noticed it “comes back”). Also, staying on 1809 is unsafe if the machine ever touches the internet.
If this laptop must remain stable for music:
  • Best practical method: keep it offline (or only connect when you choose).
  • If you have Windows 10 Pro, we can set policy to Notify only (no auto install/restarts). That’s the closest to “stop” without fighting the OS.

Quick questions (so I can tailor the next step precisely)​

1) Is this Windows 10 Home or Pro?
2) When you tried the “in-place upgrade”, did it fail with a different code (like 0xC1900101 etc.) or just “couldn’t install”?
3) Roughly how much free space is on C: (aim for 30GB+)?
If you can attach those Panther logs after the next failed offline attempt, I can usually tell you the exact driver/service/component that’s blocking the upgrade and what to remove/update.
 

ChatGPT said:
Tim — thanks, that detail helps a lot.

What your info means​

  • You’re on Windows 10 version 1809 (build 17763.x). That’s very old.
  • 0x80240034 is a Windows Update/download-style failure, and it commonly shows up when Windows Update components are broken or when the upgrade path is trying to pull something that’s no longer properly offered via WU. (It’s also a classic “Windows Update is not going to get you there” symptom.)
  • Trying to install 20H2 in 2026 is a dead-end. The correct target would have been 22H2 (19045), or ideally Windows 11 if the laptop supports it.
Given you’ve already tried “Update Assistant” and “in-place” and they’re failing, the next step is an offline in-place upgrade that does not rely on Windows Update downloads.

1) Do the upgrade the “offline” way (most reliable from 1809)​

This is the method that has historically solved stubborn “can’t upgrade” cases when Windows Update/Assistant won’t cooperate.

Step A — get the ISO (on another PC if needed)​

Use Microsoft’s Media Creation Tool to create an ISO (or USB) for Windows 10 22H2.

Step B — copy ISO locally + disconnect internet​

  1. Copy the ISO to the laptop (e.g. C:\ISO\Win10_22H2.iso)
  2. Unplug Ethernet / turn off Wi‑Fi (important for this attempt)
  3. Temporarily uninstall 3rd-party antivirus / “PC cleaner” / endpoint tools (disabling often isn’t enough).

Step C — clean boot (prevents driver/service interference)​

  1. Win+R → msconfig
  2. Services tab → check Hide all Microsoft services → click Disable all
  3. Startup tab → open Task Manager → disable all startup items
  4. Reboot

Step D — run Setup and block “Dynamic Update”​

  1. Right-click the ISO → Mount
  2. Run setup.exe
  3. When asked about updates, choose Not right now
If it still insists on downloading or fails early, do it from an elevated Command Prompt:
D:\setup.exe /DynamicUpdate disable
(Replace D: with the mounted ISO drive letter.)

2) If the offline upgrade fails, we need the setup logs (they pinpoint the exact blocker)​

On failure, please zip and attach these (they can be large):
  • C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
  • C:\$WINDOWS.~BT\Sources\Panther\setupact.log
  • C:\Windows\Panther\setuperr.log
  • C:\Windows\Panther\setupact.log
If C:\$WINDOWS.~BT is hidden, enable View → Hidden items in File Explorer.
Those logs will tell us if it’s:
  • a storage driver problem (common on gaming laptops),
  • a reserved/EFI partition size issue,
  • a specific driver/service blocking migration,
  • or component store corruption that requires DISM with an ISO source.

3) About “permanently shutting off updates”​

On Windows 10, Microsoft actively resists permanent disabling (you already noticed it “comes back”). Also, staying on 1809 is unsafe if the machine ever touches the internet.
If this laptop must remain stable for music:
  • Best practical method: keep it offline (or only connect when you choose).
  • If you have Windows 10 Pro, we can set policy to Notify only (no auto install/restarts). That’s the closest to “stop” without fighting the OS.

Quick questions (so I can tailor the next step precisely)​

1) Is this Windows 10 Home or Pro?
2) When you tried the “in-place upgrade”, did it fail with a different code (like 0xC1900101 etc.) or just “couldn’t install”?
3) Roughly how much free space is on C: (aim for 30GB+)?
If you can attach those Panther logs after the next failed offline attempt, I can usually tell you the exact driver/service/component that’s blocking the upgrade and what to remove/update.
Click to expand...
 

Right now I don’t see any of the uploaded log files (Panther / SetupDiag / CBS) in what I can access from the thread/files — the only “files” I can find are the thread JSON/index entries and activity feed, not your actual setuperr.log / setupact.log content.
So I can’t yet tell what is blocking the upgrade on your ASUS GL503V — and at this point (Win10 1809 + repeated upgrade failures), the blocker will almost certainly be something specific like a driver/service, disk/partition layout, or component-store corruption that only shows up in those logs.

What I need you to do next (2 options)​

Option A (best): run Microsoft SetupDiag and upload its ZIP​

  1. Download and run SetupDiag (it generates SetupDiagResults.log and often a ZIP with relevant setup logs).
  2. Upload SetupDiagResults.log (and the ZIP if it makes one).

Option B: zip and upload these 2 Panther logs​

After a failed upgrade attempt, zip and upload:
  • C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
  • C:\$WINDOWS.~BT\Sources\Panther\setupact.log
(Those are the ones that usually contain the exact reason, and they’re exactly what we need to move from “general steps” to “do this driver/service fix”.)

One important correction / direction​

Since you’re on Windows 10 1809, chasing 20H2 is not the right goal anymore. Your goal should be an offline in-place upgrade to Windows 10 22H2 using an ISO, with Dynamic Update disabled (no internet during setup). That’s still the most reliable route when Windows Update throws download-style failures like 0x80240034.

Quick confirm (so I stop guessing)​

Reply with:
1) Windows 10 Home or Pro
2) How much free space on C:
3) When you run the 22H2 ISO “offline”, does it fail immediately, or after the first reboot?
And please re-upload the logs (Option A or B). Once I can actually read them, I’ll tell you the exact component blocking the upgrade and the next precise step.
 

I've tried several times to load the 22h2 update with no luck. I don't believe there was a code but I will run it again to see. I also tried running the windows 10 install with no luck. There are installers for both, the ask all the right questions and go through the whole process but in the end they both say the update failed.

This is windows home by the way.

In the SOLVED post it says to run SFC /scannow and DISM /restorehealth. How do I repair errors found in DISM. There are errors.

I see there is another post asking for logs. That's my next project.
 

Got it — and thanks for confirming it’s Windows 10 Home (so no Group Policy editor).

1) DISM doesn’t “repair errors” manually — you fix it by re-running DISM with a valid repair source​

When DISM /Online /Cleanup-Image /RestoreHealth reports errors, the most common reason is it can’t find the required repair files (or the component store is too damaged to self-repair).
The standard “next level” fix is to run DISM again but point it at Windows installation files (ISO) as the source. This is a known working approach when DISM can’t repair itself.

Step A — mount a Windows ISO​

  • Right-click the Windows ISO you downloaded → Mount
  • Note the new drive letter (example: E:)

Step B — check whether the ISO contains install.wim or install.esd​

Look in:
  • E:\sources\
If you see install.wim, use the WIM command below.
If you see install.esd, use the ESD command below.

Step C — run DISM using the ISO as the repair source​

Open Command Prompt (Admin) and run:
If you have install.wim:
DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:E:\Sources\Install.wim:1 /LimitAccess
(Replace E: with your ISO drive letter.)
If you have install.esd:
DISM /Online /Cleanup-Image /RestoreHealth /Source:ESD:E:\Sources\Install.esd:1 /LimitAccess
Important: the :1 is the “index”. If index 1 doesn’t match your edition, DISM may fail. If that happens, run:
DISM /Get-WimInfo /WimFile:E:\Sources\Install.wim
(or /WimFile:E:\Sources\Install.esd)
…and tell me which index says Windows 10 Home, then we’ll plug that index number into the command.
Click to expand...

Step D — run SFC again after DISM succeeds​

sfc /scannow

2) If DISM still fails, I need the exact DISM error code​

Please copy/paste the last ~10 lines of the DISM output, especially the line that contains the error code (examples: 0x800f081f, 0x800f0906, etc.).
Also, zip and attach:
  • C:\Windows\Logs\DISM\dism.log
  • C:\Windows\Logs\CBS\CBS.log
(Those logs show why DISM can’t repair.)

3) About your 22H2 upgrade failing “at the end”​

That’s exactly when Panther logs or SetupDiag become necessary, because Windows Update often only shows a generic “failed” message.
After the next failed attempt, please zip and attach:
  • C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
  • C:\$WINDOWS.~BT\Sources\Panther\setupact.log
If you can’t attach files here, paste the last ~50 lines from setuperr.log.

Quick questions (so we don’t waste another day on generic steps)​

1) How much free space is on C: (GB)?
2) What DISM error code are you getting right now?
3) When the 22H2 upgrade fails, does it fail before the first reboot, or after reboot while “configuring updates”?
Answer those and I’ll tell you the next precise move based on the actual failure mode.
 

ChatGPT said:
Got it — and thanks for confirming it’s Windows 10 Home (so no Group Policy editor).

1) DISM doesn’t “repair errors” manually — you fix it by re-running DISM with a valid repair source​

When DISM /Online /Cleanup-Image /RestoreHealth reports errors, the most common reason is it can’t find the required repair files (or the component store is too damaged to self-repair).
The standard “next level” fix is to run DISM again but point it at Windows installation files (ISO) as the source. This is a known working approach when DISM can’t repair itself.

Step A — mount a Windows ISO​

  • Right-click the Windows ISO you downloaded → Mount
  • Note the new drive letter (example: E:)

Step B — check whether the ISO contains install.wim or install.esd​

Look in:
  • E:\sources\
If you see install.wim, use the WIM command below.
If you see install.esd, use the ESD command below.

Step C — run DISM using the ISO as the repair source​

Open Command Prompt (Admin) and run:
If you have install.wim:
/Cleanup-ImagDISM /Onlinee /RestoreHealth /Source:WIM:E:\Sources\Install.wim:1 /LimitAccess
(Replace E: with your ISO drive letter.)
If you have install.esd:
DISM /Online /Cleanup-Image /RestoreHealth /Source:ESD:E:\Sources\Install.esd:1 /LimitAccess

Step D — run SFC again after DISM succeeds​

sfc /scannow

2) If DISM still fails, I need the exact DISM error code​

Please copy/paste the last ~10 lines of the DISM output, especially the line that contains the error code (examples: 0x800f081f, 0x800f0906, etc.).
Also, zip and attach:
  • C:\Windows\Logs\DISM\dism.log
  • C:\Windows\Logs\CBS\CBS.log
(Those logs show why DISM can’t repair.)

3) About your 22H2 upgrade failing “at the end”​

That’s exactly when Panther logs or SetupDiag become necessary, because Windows Update often only shows a generic “failed” message.
After the next failed attempt, please zip and attach:
  • C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
  • C:\$WINDOWS.~BT\Sources\Panther\setupact.log
If you can’t attach files here, paste the last ~50 lines from setuperr.log.

Quick questions (so we don’t waste another day on generic steps)​

1) How much free space is on C: (GB)?
2) What DISM error code are you getting right now?
3) When the 22H2 upgrade fails, does it fail before the first reboot, or after reboot while “configuring updates”?
Answer those and I’ll tell you the next precise move based on the actual failure mode.
Click to expand...
I will have to go with this one,

About your 22H2 upgrade failing “at the end​

I have over 700 gig free on C: drive. The 22H2 upgrade doesnt reboot. I'll have to check that next attempt but I'm sure it didnt. Problem with the panther logs, they are dated 2023 even though the directory is yesterday 2026. I also tried running the SetupDiag and it only comes up with the help page.
I am going to run the 22h2 install again and will watch for error codes.
 

700GB free rules out the usual “not enough space” issue — good. If the 22H2 setup fails without ever rebooting, that almost always means it’s failing in the online/pre-check phase (compat/driver check, servicing stack/component store, or dynamic update/download step), not the “SAFE_OS / first reboot” phase.

1) Why your Panther logs show 2023​

That can happen for two reasons:
  • The logs are being reused/appended from older upgrade attempts (very common). The folder timestamp can be “new” even when the log contains older entries.
  • Your system clock was wrong during past attempts (worth checking).
Quick check: confirm Windows clock is correct: Settings → Time & Language → Date & time → enable Set time automatically + correct time zone.
Most important: even if the file contains old dates, the real failure is usually at the bottom of setuperr.log / setupact.log. Scroll to the end and you should see the most recent attempt.

2) Force Windows Setup to generate “fresh” logs (recommended)​

To avoid digging through old 2023 attempts, do this before you try 22H2 again:
  1. Disk Cleanup (built-in)
    • Start → type Disk Cleanup → run it
    • Click Clean up system files
    • Check these if present:
      • Temporary Windows installation files
      • Previous Windows installation(s) (if present)
      • Windows upgrade log files
    • OK / delete
This is the safest way to clear out old $WINDOWS.~BT remnants so the next run produces clean new Panther logs.

3) Run 22H2 again in the most “controlled” way (no downloads, no interference)​

  1. Do a Clean Boot:
    • Win+R → msconfig
    • Services tab → Hide all Microsoft services → Disable all
    • Startup tab → open Task Manager → disable everything
    • Reboot
  2. Mount your Windows 10 22H2 ISO and run setup with Dynamic Update disabled:
    • Open Command Prompt (Admin)
    • Run (replace D: with your mounted ISO drive):
      D:\setup.exe /DynamicUpdate disable
      This prevents Setup from trying to “phone home” for drivers/updates during the upgrade (which can cause failures that never reach reboot).
  3. After it fails, immediately grab these:
    • C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
    • C:\$WINDOWS.~BT\Sources\Panther\setupact.log
If you can’t upload them yet, paste the last ~60 lines of setuperr.log (the bottom is what matters).

4) SetupDiag only opening the help page​

That usually means you didn’t actually run the SetupDiag.exe analyzer (or Windows is treating it like “open with browser/help”).
Try this exact method:
  1. Put SetupDiag.exe on your Desktop
  2. Open Command Prompt (Admin)
  3. Run:
    Code: 
    cd /d "%USERPROFILE%\Desktop"
SetupDiag.exe /Output:"%USERPROFILE%\Desktop\SetupDiagResults.log"
  4. Then upload SetupDiagResults.log

5) About DISM errors (yes, they matter)​

If DISM is reporting corruption, it can block upgrades. The correct “repair” is often DISM with an ISO source (not just running the same command repeatedly). The working format looks like:
dism /online /cleanup-image /restorehealth /source:wim:X:\sources\install.wim:1 /limitaccess
When you get a moment, paste your exact DISM error code (the 0x… number). The fix differs depending on whether it’s “source files could not be found” vs “component store corrupt” vs “pending reboot”, etc.

What I need from your next attempt​

After you run the controlled 22H2 setup again, reply with:
1) The exact message at the end (and any code if shown)
2) The last ~60 lines of C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
3) Your DISM error code from /RestoreHealth
With that, we can stop guessing and pinpoint the exact blocker (often it’s one specific driver/service or a servicing-store issue).
 

ChatGPT said:
700GB free rules out the usual “not enough space” issue — good. If the 22H2 setup fails without ever rebooting, that almost always means it’s failing in the online/pre-check phase (compat/driver check, servicing stack/component store, or dynamic update/download step), not the “SAFE_OS / first reboot” phase.

1) Why your Panther logs show 2023​

That can happen for two reasons:
  • The logs are being reused/appended from older upgrade attempts (very common). The folder timestamp can be “new” even when the log contains older entries.
  • Your system clock was wrong during past attempts (worth checking).
Quick check: confirm Windows clock is correct: Settings → Time & Language → Date & time → enable Set time automatically + correct time zone.
Most important: even if the file contains old dates, the real failure is usually at the bottom of setuperr.log / setupact.log. Scroll to the end and you should see the most recent attempt.

2) Force Windows Setup to generate “fresh” logs (recommended)​

To avoid digging through old 2023 attempts, do this before you try 22H2 again:
  1. Disk Cleanup(built-in)
    • Start → type Disk Cleanup → run it
    • Click Clean up system files
    • Check these if present:
      • Temporary Windows installation files
      • Previous Windows installation(s) (if present)
      • Windows upgrade log files
    • OK / delete
This is the safest way to clear out old $WINDOWS.~BT remnants so the next run produces clean new Panther logs.

3) Run 22H2 again in the most “controlled” way (no downloads, no interference)​

  1. Do a Clean Boot:
    • Win+R → msconfig
    • Services tab → Hide all Microsoft services → Disable all
    • Startup tab → open Task Manager → disable everything
    • Reboot
  2. Mount your Windows 10 22H2 ISO and run setup with Dynamic Update disabled:
    • Open Command Prompt (Admin)
    • Run (replace D: with your mounted ISO drive):
      D:\setup.exe /DynamicUpdate disable
      This prevents Setup from trying to “phone home” for drivers/updates during the upgrade (which can cause failures that never reach reboot).
  3. After it fails, immediately grab these:
    • C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
    • C:\$WINDOWS.~BT\Sources\Panther\setupact.log
If you can’t upload them yet, paste the last ~60 lines of setuperr.log (the bottom is what matters).

4) SetupDiag only opening the help page​

That usually means you didn’t actually run the SetupDiag.exe analyzer (or Windows is treating it like “open with browser/help”).
Try this exact method:
  1. Put SetupDiag.exe on your Desktop
  2. Open Command Prompt (Admin)
  3. Run:
    Code: 
    cd /d "%USERPROFILE%\Desktop"
SetupDiag.exe /Output:"%USERPROFILE%\Desktop\SetupDiagResults.log"
  4. Then upload SetupDiagResults.log

5) About DISM errors (yes, they matter)​

If DISM is reporting corruption, it can block upgrades. The correct “repair” is often DISM with an ISO source (not just running the same command repeatedly). The working format looks like:
dism /online /cleanup-image /restorehealth /source:wim:X:\sources\install.wim:1 /limitaccess
When you get a moment, paste your exact DISM error code (the 0x… number). The fix differs depending on whether it’s “source files could not be found” vs “component store corrupt” vs “pending reboot”, etc.

What I need from your next attempt​

After you run the controlled 22H2 setup again, reply with:
1) The exact message at the end (and any code if shown)
2) The last ~60 lines of C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
3) Your DISM error code from /RestoreHealth
With that, we can stop guessing and pinpoint the exact blocker (often it’s one specific driver/service or a servicing-store issue).
Click to expand...
ChatGPT said:
700GB free rules out the usual “not enough space” issue — good. If the 22H2 setup fails without ever rebooting, that almost always means it’s failing in the online/pre-check phase (compat/driver check, servicing stack/component store, or dynamic update/download step), not the “SAFE_OS / first reboot” phase.

1) Why your Panther logs show 2023​

That can happen for two reasons:
  • The logs are being reused/appended from older upgrade attempts (very common). The folder timestamp can be “new” even when the log contains older entries.
  • Your system clock was wrong during past attempts (worth checking).
Quick check: confirm Windows clock is correct: Settings → Time & Language → Date & time → enable Set time automatically + correct time zone.
Most important: even if the file contains old dates, the real failure is usually at the bottom of setuperr.log / setupact.log. Scroll to the end and you should see the most recent attempt.

2) Force Windows Setup to generate “fresh” logs (recommended)​

To avoid digging through old 2023 attempts, do this before you try 22H2 again:
  1. Disk Cleanup(built-in)
    • Start → type Disk Cleanup → run it
    • Click Clean up system files
    • Check these if present:
      • Temporary Windows installation files
      • Previous Windows installation(s) (if present)
      • Windows upgrade log files
    • OK / delete
This is the safest way to clear out old $WINDOWS.~BT remnants so the next run produces clean new Panther logs.

3) Run 22H2 again in the most “controlled” way (no downloads, no interference)​

  1. Do a Clean Boot:
    • Win+R → msconfig
    • Services tab → Hide all Microsoft services → Disable all
    • Startup tab → open Task Manager → disable everything
    • Reboot
  2. Mount your Windows 10 22H2 ISO and run setup with Dynamic Update disabled:
    • Open Command Prompt (Admin)
    • Run (replace D: with your mounted ISO drive):
      D:\setup.exe /DynamicUpdate disable
      This prevents Setup from trying to “phone home” for drivers/updates during the upgrade (which can cause failures that never reach reboot).
  3. After it fails, immediately grab these:
    • C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
    • C:\$WINDOWS.~BT\Sources\Panther\setupact.log
If you can’t upload them yet, paste the last ~60 lines of setuperr.log (the bottom is what matters).

4) SetupDiag only opening the help page​

That usually means you didn’t actually run the SetupDiag.exe analyzer (or Windows is treating it like “open with browser/help”).
Try this exact method:
  1. Put SetupDiag.exe on your Desktop
  2. Open Command Prompt (Admin)
  3. Run:
    Code: 
    cd /d "%USERPROFILE%\Desktop"
SetupDiag.exe /Output:"%USERPROFILE%\Desktop\SetupDiagResults.log"
  4. Then upload SetupDiagResults.log

5) About DISM errors (yes, they matter)​

If DISM is reporting corruption, it can block upgrades. The correct “repair” is often DISM with an ISO source (not just running the same command repeatedly). The working format looks like:
dism /online /cleanup-image /restorehealth /source:wim:X:\sources\install.wim:1 /limitaccess
When you get a moment, paste your exact DISM error code (the 0x… number). The fix differs depending on whether it’s “source files could not be found” vs “component store corrupt” vs “pending reboot”, etc.

What I need from your next attempt​

After you run the controlled 22H2 setup again, reply with:
1) The exact message at the end (and any code if shown)
2) The last ~60 lines of C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
3) Your DISM error code from /RestoreHealth
With that, we can stop guessing and pinpoint the exact blocker (often it’s one specific driver/service or a servicing-store issue).
Click to expand...
here is some of the setupact file.


2026-02-23 20:30:56, Info MOUPG WimLayout: Leaving Execute Method
2026-02-23 20:30:56, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting WINDLP data point [0x2004]
2026-02-23 20:30:56, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting WINDLP data point [0x2003]
2026-02-23 20:30:56, Info MOUPG ProgressHandlerAction: Sending final progress message for action [0].
2026-02-23 20:30:56, Info MOUPG ProgressHandlerAction FinalUpdate: 0x0, 0x64 / 0x64, 0x5E
2026-02-23 20:30:56, Info MOUPG Action: 100%, Delta: 98.56s, 100 ticks, Avg: 1.015 ticks/s
2026-02-23 20:30:56, Info MOUPG Action progress: [100%]
2026-02-23 20:30:56, Info MOUPG Task progress: [100%]
2026-02-23 20:30:56, Info MOUPG Overall progress: [100%]
2026-02-23 20:30:56, Info MOUPG Mapped Global progress: [100%]
2026-02-23 20:30:56, Info MOUPG ProgressHandlerAction: Sending final progress message for action [0].
2026-02-23 20:30:56, Info MOUPG ProgressHandlerAction FinalUpdate: 0x0, 0x64 / 0x64, 0x64
2026-02-23 20:30:56, Info MOUPG Signalling actions thread to shut down.
2026-02-23 20:30:56, Info MOUPG Waiting for actions thread to exit.
2026-02-23 20:30:56, Info MOUPG Actions thread has exited.
2026-02-23 20:30:56, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting WINDLP data point [0x2004]
2026-02-23 20:30:56, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting WINDLP data point [0x2000]
2026-02-23 20:30:56, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting WINDLP data point [0x3000]
2026-02-23 20:30:56, Info MOUPG DlpTask: Leaving Execute Method
2026-02-23 20:30:56, Info MOUPG SetupManager: Successfully completed current mode
2026-02-23 20:30:56, Info MOUPG CSetupUIManager: Showing exiting Setup
2026-02-23 20:30:56, Info MOUPG CInstallUI::ShowExitingSetup: Posted MSG_INSTALLUI_SWITCH_TO_PROGRESS_PAGE
2026-02-23 20:30:56, Info MOUPG SetupManager::OpenOrCreateTask: Creating new task [Exit].
2026-02-23 20:30:56, Info MOUPG CreateTask: Name = [Exit], WorkingPath = [C:\$Windows.~WS\Sources], TransportId = [00000000-0000-0000-0000-000000000000], Flags = [0x0]
2026-02-23 20:30:56, Info MOUPG Finalize: Entering Prepare Method
2026-02-23 20:30:56, Info MOUPG Finalize: Leaving Prepare Method
2026-02-23 20:30:56, Info MOUPG DlpTask: Entering Execute Method
2026-02-23 20:30:56, Info MOUPG DlpTask: Transport not set. Skipping download phase.
2026-02-23 20:30:56, Info MOUPG DlpTask: Executing Actions...
2026-02-23 20:30:56, Info MOUPG Action execution thread timeout period: [1000 ms]
2026-02-23 20:30:56, Error MOUPG CSetupManager::GetDUSetupResults(6511): Result = 0x80070490
2026-02-23 20:30:56, Info MOUPG InitializeRoutine: MOSETUP_ACTION_IMAGE_EXIT
2026-02-23 20:30:56, Info MOUPG ImageExit: Initializing SetupResult: [0x0]
2026-02-23 20:30:56, Info MOUPG ImageExit: Initializing Extended: [0xb0003]
2026-02-23 20:30:56, Info MOUPG ImageExit: Initializing Scenario: [7]
2026-02-23 20:30:56, Info MOUPG ImageExit: Initializing Mode: [8]
2026-02-23 20:30:56, Info MOUPG ImageExit: Initializing Target: [C]
2026-02-23 20:30:56, Info MOUPG ImageExit: Initializing SQM: [TRUE]
2026-02-23 20:30:56, Info MOUPG ImageExit: Initializing PostReboot: [FALSE]
2026-02-23 20:30:56, Info MOUPG ProgressHandlerAction: Sending initial progress message for action [0].
2026-02-23 20:30:56, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting WINDLP data point [0x2002]
2026-02-23 20:30:56, Info MOUPG CInstallUI::OnActionChanged
2026-02-23 20:30:56, Info MOUPG CInstallUI::OnActionChanged: Exit is requested. Ignoring OnActionChanged
2026-02-23 20:30:56, Info MOUPG Finalize: Entering Execute Method
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Identifier -> [FinalizeExit]
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Loading Setup Platform...
2026-02-23 20:30:56, Info MOUPG CInstallUI::CInstallUIMessageWindow::SwitchToProgressPage
2026-02-23 20:30:56, Info MOUPG CInstallUI::SwitchToProgressPage
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Determine if the expected version of Setup Platform has been loaded...
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Platform and Setup binaries match!
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Attempting resurrect of Setup Platform object...
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Creating Setup Platform object...
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Setup Platform object created!
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Enable diagnosis mode
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Setting Correlation vector
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Persisting telemetry data
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Restartable: [yes]
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Not persisting telemetry data
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Resurrecting NewSystem object from [C:\$Windows.~BT\Sources]
2026-02-23 20:30:56, Warning MOUPG ImageExit: Unable to resurrect NewSystem object. hr=0x80070002
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Upload telemetry data
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Setting Watson bucketing parameter -> [0]=[7]
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Setting Watson bucketing parameter -> [1]=[8]
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Setting Watson bucketing parameter -> [4]=[0x0]
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Setting Watson bucketing parameter -> [5]=[0xB0003]
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Setting Watson bucketing parameter -> [3]=[0]
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Setting Watson bucketing parameter -> [6]=[17763]
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Setting Watson bucketing parameter -> [7]=[rs5_release]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [SetupBuildString]=[10.0.19041.572.x86fre.vb_release_svc_prod1.201007-1724] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SetupCompilationType]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SetupVersionMajor]=[0xA] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SetupVersionMinor]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SetupVersionBuildNumber]=[0x4A61] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SetupVersionCSDBuildNumber]=[0x23C] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SetupBuildDate]=[0x3112F] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [SetupBranchName]=[vb_release_svc_prod1] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SetupBranchHash]=[0x4C0851F0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SystemPhysicalMemory]=[0x1FF4F68] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SystemProcessorCount]=[0x8] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SystemCpuModel]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SystemProcessorArchitecture]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [SystemManufacturer]=[ASUSTeK COMPUTER INC.] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [SystemProductName]=[GL503VMF] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [SystemCpuDescription]=[Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [NativeProcessorArchitecture]=[0x9] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [Setup360Scenario]=[0x7] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [Setup360Mode]=[0x8] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [IsWebSetupCreatedMedia]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [LegacySetupInterrupt]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [ReflectDrivers]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [PostRollbackContext]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SetupUpgradeAttempts]=[0xA] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SetupPriority]=[0x1] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [EulaTime]=[0x22] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [WebSetupInputMediaType]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [WebSetupInputUpgradeNow]=[0x1] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [WebSetupDownloadTotalTime]=[0x131] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [DecryptTime]=[0xB] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [WimLayoutTime]=[0x62] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [HostOsMajorVersion]=[0xA] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [HostOsMinorVersion]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [HostOsBuildNumber]=[0x4563] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [HostOsArchitecture]=[0x2] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [HostOsStageType]=[0x1] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [HostOsEditionType]=[0x2] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SetupFailureCount]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [HostOsLanguage]=[0x409] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [HostOsSkuId]=[0x2BD] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [HostOsSuiteMask]=[0x300] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [HostOsProductType]=[0x1] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [HostOsCompact]=[0x1] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [HostOsWimBoot]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SourceOsMajorVersion]=[0xA] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SourceOsMinorVersion]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SourceOsBuildNumber]=[0x4563] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [SourceOsBuildQFE]=[0x629] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [QUADWORD] -> [SetupStartTime]=[0x1dca53cd65f5104] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [WuId]=[214c0972-465e-43b1-8469-d34a30dd97f3] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [WebSetupOnlineStoreVersion]=[1.4.1] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [WebSetupInputDefaultLang]=[en-us] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [WebSetupInputDefaultEdition]=[Core] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [WebSetupInputDefaultArch]=[x64] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [WebSetupTransport]=[3d5edec5-37a4-4a4f-b5be-9a0a396c2f85] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [HostOsEditionId]=[Core] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [HostOsInstallationType]=[Client] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [HostOsSkuName]=[Windows 10 Home] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [HostOsBranchName]=[rs5_release] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [SourceOsEditionId]=[Core] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [STRING] -> [SourceOsLanguage]=[en-US] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Warning MOUPG Finalize: Compat instance not found.
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Upload telemetry data
2026-02-23 20:30:56, Info MOUPG Finalize: Reporting result value: [0x0]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [Setup360MappedResult]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [Setup360Result]=[0x0] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [Setup360Extended]=[0xB0003] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [CUSTOM] -> [WindowsUpdateExit] -> [Web360][ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [CUSTOM] -> [UnexpectedEvent] -> [Web360][ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][214c0972-465e-43b1-8469-d34a30dd97f3][][Succeeded][Windows 10 Home][17763][7][8][0x0][0xB0003][19041]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: TraceOneSettingsEvent -> [0x0][0][os=windows;scenarioId=7;platformEdition=Core;platformInstallationType=Client;sku=101;AppVer=10.0.19041.572;appBuildLab=vb_release_svc_prod1][][Web360][ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG Finalize: Retrieving downlevel ticks from registry...
2026-02-23 20:30:56, Info MOUPG Finalize: Converting [98] downlevel ticks to seconds...
2026-02-23 20:30:56, Info MOUPG Finalize: Reporting total downlevel time: [490 seconds]
2026-02-23 20:30:56, Info MOUPG CSetupDiagnostics: Tracing Data [DWORD] -> [Setup360DownlevelTime]=[0x1EA] [ca535717-fa75-48d0-a3c8-d01fdfb9cef8][][][0x7]
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: Release Identifier -> [FinalizeExit]
2026-02-23 20:30:56, Info MOUPG MoSetupPlatform: SuspendAndReleasing Setup Platform object...
2026-02-23 20:30:57, Info MOUPG MoSetupPlatform: Setup Platform object suspended!
2026-02-23 20:30:57, Info MOUPG MoSetupPlatform: Setup Platform object released!
2026-02-23 20:30:57, Info MOUPG Finalize: Leaving Execute Method
2026-02-23 20:30:57, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting WINDLP data point [0x2004]
2026-02-23 20:30:57, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting WINDLP data point [0x2003]
2026-02-23 20:30:57, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting WINDLP data point [0x2001]
2026-02-23 20:30:57, Info MOUPG ProgressHandlerAction: Sending final progress message for action [0].
2026-02-23 20:30:57, Info MOUPG ProgressHandlerAction FinalUpdate: 0x0, 0x0 / 0x0, 0x0
2026-02-23 20:30:57, Info MOUPG ProgressHandlerAction: Sending final progress message for action [0].
2026-02-23 20:30:57, Info MOUPG ProgressHandlerAction FinalUpdate: 0x0, 0x0 / 0x0, 0x0
2026-02-23 20:30:57, Info MOUPG Signalling actions thread to shut down.
2026-02-23 20:30:57, Info MOUPG Waiting for actions thread to exit.
2026-02-23 20:30:57, Info MOUPG Actions thread has exited.
2026-02-23 20:30:57, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting WINDLP data point [0x2004]
2026-02-23 20:30:57, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting WINDLP data point [0x2000]
2026-02-23 20:30:57, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting WINDLP data point [0x3000]
2026-02-23 20:30:57, Info MOUPG DlpTask: Leaving Execute Method
2026-02-23 20:30:57, Info MOUPG SetupManager: Launching setup.
2026-02-23 20:30:57, Info MOUPG SetupMgr: Deleting environment variable SP_UPLOAD_ASIMOV.
2026-02-23 20:30:57, Info MOUPG SetupManager: Requesting cleanup level [0x1] from parent process.
2026-02-23 20:30:57, Info MOUPG SetupManager: Resetting WinDlp state for full cleanup...
2026-02-23 20:30:57, Error MOUPG CDlpTask::Cancel(982): Result = 0xC1800104
2026-02-23 20:30:57, Error MOUPG CDlpTask::Cancel(982): Result = 0xC1800104
2026-02-23 20:30:57, Error MOUPG CDlpTask::Cancel(982): Result = 0xC1800104
2026-02-23 20:30:57, Error MOUPG CDlpTask::Cancel(982): Result = 0xC1800104
2026-02-23 20:30:57, Info MOUPG CSetupUIManager: Showing exiting Setup
2026-02-23 20:30:57, Info MOUPG CInstallUI::Quit: Posted MSG_INSTALLUI_FORCE_QUIT
2026-02-23 20:30:57, Info MOUPG CInstallUI::CInstallUIMessageWindow::ForceQuit
2026-02-23 20:30:57, Info MOUPG Force ending Message pump
2026-02-23 20:30:57, Info MOUPG CInstallUI::ExitInstance
2026-02-23 20:30:57, Info MOUPG SetupUI: Calling PowerClearRequest with type [0x1]...
2026-02-23 20:30:57, Info MOUPG SetupUI: Power request cleared!
2026-02-23 20:30:57, Info MOUPG **************** SetupHost Logging End ****************



Here is the Setuperr.

2026-02-23 20:22:41, Error MOUPG CInstallUI::GetDefaultLanguage(2027): Result = 0x80070002[gle=0x00000002]
2026-02-23 20:30:56, Error MOUPG CSetupManager::GetDUSetupResults(6511): Result = 0x80070490
2026-02-23 20:30:57, Error MOUPG CDlpTask::Cancel(982): Result = 0xC1800104
2026-02-23 20:30:57, Error MOUPG CDlpTask::Cancel(982): Result = 0xC1800104
2026-02-23 20:30:57, Error MOUPG CDlpTask::Cancel(982): Result = 0xC1800104
2026-02-23 20:30:57, Error MOUPG CDlpTask::Cancel(982): Result = 0xC1800104
 

That setuperr.log snippet is actually very useful — it shows Setup is bailing out during the Dynamic Update / Web-setup (“$Windows.~WS”) portion, not during the reboot/apply phase.

What your log is saying (in plain English)​

  • CSetupManager::GetDUSetupResults... Result = 0x80070490
    0x80070490 = “Element not found”. In upgrade scenarios, this usually means the web-setup / dynamic update result/state that Setup expects to read is missing/corrupt.
  • You’re running from C:\$Windows.~WS\Sources (that’s the web setup / Update Assistant-style working folder), not a “clean” offline ISO/USB run.
  • Then Setup cancels download/DU state and exits (CDlpTask::Cancel... 0xC1800104).
So the fastest path is: purge the web-setup leftovers + run the upgrade from full ISO/USB with Dynamic Update disabled.

Step 1 — remove the broken “web setup” leftovers (safe)​

Reboot first, then do this:
1) Open Command Prompt (Admin)
2) Run these (they remove only upgrade working folders/caches):
Code: 
rd /s /q C:\$WINDOWS.~WS
rd /s /q C:\$WINDOWS.~BT
rd /s /q C:\Windows10Upgrade
rd /s /q C:\ESD
If one of those folders doesn’t exist, that’s fine.

Step 2 — upgrade using a full ISO/USB (not Update Assistant)​

1) Use Microsoft’s Media Creation Tool to create a Windows 10 22H2 USB (or download the ISO and mount it).
2) Disconnect the internet (turn off Wi‑Fi) for the attempt.
3) Run from the USB/ISO, but disable Dynamic Update explicitly:
If your mounted ISO/USB is drive D::
D:\setup.exe /DynamicUpdate disable
This directly avoids the part of the process your log shows is failing (DU result retrieval).

Step 3 — fix DISM corruption (because it can block upgrades)​

You mentioned DISM shows errors. The correct “repair” is usually DISM with a source (your mounted ISO), not just repeating /RestoreHealth.
After you mount the ISO (say it becomes D:), run:
Code: 
DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:1 /LimitAccess
sfc /scannow
That /Source:WIM:... pattern is the standard way to repair the component store when Windows can’t self-repair.
If your ISO has install.esd instead of install.wim, tell me and I’ll give the exact command (it’s nearly identical).

What I need from you after the next attempt (2 small items)​

1) Copy/paste the final on-screen message from Setup (even if it’s generic).
2) Paste the last ~30 lines of:
  • C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
  • (and if possible) setupact.log
Also: please tell me the exact DISM error code you get (the 0x... number). The fix depends heavily on that.
If you do the folder purge + ISO run with /DynamicUpdate disable, there’s a very good chance it will finally get past the phase that’s failing in your excerpt.
 

ChatGPT said:
That setuperr.log snippet is actually very useful — it shows Setup is bailing out during the Dynamic Update / Web-setup (“$Windows.~WS”) portion, not during the reboot/apply phase.

What your log is saying (in plain English)​

  • CSetupManager::GetDUSetupResults... Result = 0x80070490
    0x80070490 = “Element not found”. In upgrade scenarios, this usually means the web-setup / dynamic update result/state that Setup expects to read is missing/corrupt.
  • You’re running from C:\$Windows.~WS\Sources (that’s the web setup / Update Assistant-style working folder), not a “clean” offline ISO/USB run.
  • Then Setup cancels download/DU state and exits (CDlpTask::Cancel... 0xC1800104).
So the fastest path is: purge the web-setup leftovers + run the upgrade from full ISO/USB with Dynamic Update disabled.

Step 1 — remove the broken “web setup” leftovers (safe)​

Reboot first, then do this:
1) Open Command Prompt (Admin)
2) Run these (they remove only upgrade working folders/caches):
Code: 
rd /s /q C:\$WINDOWS.~WS
rd /s /q C:\$WINDOWS.~BT
rd /s /q C:\Windows10Upgrade
rd /s /q C:\ESD
If one of those folders doesn’t exist, that’s fine.

Step 2 — upgrade using a full ISO/USB (not Update Assistant)​

1) Use Microsoft’s Media Creation Tool to create a Windows 10 22H2 USB (or download the ISO and mount it).
2) Disconnect the internet (turn off Wi‑Fi) for the attempt.
3) Run from the USB/ISO, but disable Dynamic Update explicitly:
If your mounted ISO/USB is drive D::
D:\setup.exe /DynamicUpdate disable
This directly avoids the part of the process your log shows is failing (DU result retrieval).

Step 3 — fix DISM corruption (because it can block upgrades)​

You mentioned DISM shows errors. The correct “repair” is usually DISM with a source (your mounted ISO), not just repeating /RestoreHealth.
After you mount the ISO (say it becomes D:), run:
Code: 
DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:1 /LimitAccess
sfc /scannow
That /Source:WIM:... pattern is the standard way to repair the component store when Windows can’t self-repair.
If your ISO has install.esd instead of install.wim, tell me and I’ll give the exact command (it’s nearly identical).

What I need from you after the next attempt (2 small items)​

1) Copy/paste the final on-screen message from Setup (even if it’s generic).
2) Paste the last ~30 lines of:
  • C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
  • (and if possible) setupact.log
Also: please tell me the exact DISM error code you get (the 0x... number). The fix depends heavily on that.
If you do the folder purge + ISO run with /DynamicUpdate disable, there’s a very good chance it will finally get past the phase that’s failing in your excerpt.
Click to expand...
Will make a USB. That's the next step.
 

Perfect — making the 22H2 USB is the right next step (it gets you away from the flaky “web setup / Update Assistant” path and onto a clean install media path).

1) Create the Windows 10 22H2 USB​

On any working PC (can be the laptop if it’ll cooperate):
  1. Download Microsoft’s Media Creation Tool for Windows 10.
  2. Run it → Create installation media (USB flash drive, DVD, or ISO).
  3. Pick:
    • Language: your choice (usually English US)
    • Edition: Windows 10
    • Architecture: 64-bit
  4. Choose USB flash drive (8GB+).

2) Do an in-place upgrade from the USB (keep files/apps)​

Important: Don’t boot from the USB for this part.
You want to start it from inside Windows 10 1809 so it’s an “upgrade/repair install”:
  1. Reboot once first.
  2. In Windows, open the USB in File Explorer.
  3. Run setup.exe.
When prompted:
  • Choose Not right now (don’t download updates during setup).
If you want to force it, you can launch it from an elevated Command Prompt like this:
X:\setup.exe /DynamicUpdate disable
(Replace X: with your USB drive letter.)

3) Optional but recommended before you run setup (clears stuck upgrade state)​

Since your log showed the web-setup path (C:\$Windows.~WS\Sources) was involved, it’s worth clearing the leftovers first:
Open Command Prompt (Admin) and run:
Code: 
rd /s /q C:\$WINDOWS.~WS
rd /s /q C:\$WINDOWS.~BT
rd /s /q C:\Windows10Upgrade
rd /s /q C:\ESD

4) If DISM is still reporting corruption, fix it using the USB/ISO as the repair source​

After you plug in/mount install media, you can repair the component store using the install image as the source (this often matters for upgrades). The correct pattern looks like:
dism /online /cleanup-image /restorehealth /source:wim:X:\sources\install.wim:1 /limitaccess
If you want, after you make the USB, tell me whether it contains install.wim or install.esd in X:\sources\ and I’ll give you the exact command for your case.

What I want you to report back after the USB attempt​

1) The exact final message setup shows when it fails
2) The last ~30 lines of:
  • C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
That will let us identify the specific blocker (driver/service/servicing corruption) instead of guessing.
 

You must log in or register to reply here.
Back
Top