Microsoft DISM freezes with Norton VPN On

[MichaelR_Myers1]

Windows 11 (Latest)

Norton 360 Deluxe

Does anyone know why Microsoft DISM only partially works with Norton VPN (US connection) on? I can’t get DISM to validate my windows s/w and restore health using: DISM /online /cleanup-image /restorehealth. It worked fine on the first week of May before the latest Norton 360 updates.

[bjm]

@MichaelR_Myers1

Microsoft DISM freezes with Norton VPN On
Windows 11 (Latest)
Norton 360 Deluxe
Does anyone know why Microsoft DISM only partially works with Norton VPN (US connection) on? I can’t get DISM to validate my windows s/w and restore health using: DISM /online /cleanup-image /restorehealth. It worked fine on the first week of May before the latest Norton 360 updates.

Hello @MichaelR_Myers1
Please confirm you’re Norton 360 VPN and not standalone Norton VPN.
Why complicate the equation.
fwiw ~ I’d disable as much Norton as possible. I’d remove Norton. Just me.

Since DISM is a Windows servicing/repair operation, have you tried temporarily disabling Norton VPN (and possibly other Norton network filtering features) before running DISM /Online /Cleanup-Image /RestoreHealth ?

A VPN adds additional routing, encryption, and network filtering overhead, and DISM often needs stable/direct access to Microsoft servicing servers. If DISM works normally with the VPN disabled, that would help narrow the issue to the VPN/network layer rather than Windows corruption itself.

What you’re describing actually makes technical sense. DISM /Online /Cleanup-Image /RestoreHealth often relies on Windows Update and Microsoft servicing endpoints to validate and download repair payloads. A VPN can interfere with that process if:

• the VPN tunnel alters Microsoft endpoint routing,
• DNS filtering or HTTPS inspection is occurring,
• IPv6 handling changes,
• the VPN adapter priority changes after an update,
• or the VPN region/server is blocking or rate-limiting some Microsoft CDN traffic.

And yes — it’s plausible that a recent update to Norton 360 or its VPN component changed network behavior. There are recent community reports of Norton VPN instability and networking-related problems after newer builds on Windows 11.

The important clue is:

DISM works with VPN OFF but fails or partially works with VPN ON.

That strongly points to networking interference rather than Windows corruption itself.

A few likely causes:

1. Microsoft repair source access
   DISM frequently contacts Windows Update repair sources online. Some VPN endpoints don’t play nicely with Microsoft servicing traffic.
2. US VPN endpoint issue
   Certain Norton VPN regions/servers may behave differently. Try:

• changing from “US” to another US city,
• or temporarily testing Canada/UK.

3. IPv6 interaction
   VPNs sometimes mishandle dual-stack IPv4/IPv6 routing. Research and community reports show VPN implementations can still have IPv6 edge-case problems.
4. Split tunnel / Smart Firewall changes
   A Norton update may have modified firewall or VPN filtering behavior.
5. DISM hanging isn’t always failure
   DISM commonly pauses at certain percentages for a long time. But if it eventually throws:

• 0x800f081f
• 0x800f0906
• 0x800f0915
  or “source files could not be found”then network access to Microsoft repair sources is often involved.

Things worth testing:

DISM /Online /Cleanup-Image /ScanHealth

Then:

DISM /Online /Cleanup-Image /RestoreHealth

Test under:

• VPN OFF
• VPN ON (US)
• VPN ON (different region)

Also try temporarily disabling:

• VPN auto-connect
• split tunneling
• ad tracker blocking
• “Secure Web” or web protection components if enabled

Another good diagnostic:

ping download.windowsupdate.com

while VPN is active.

You can also force DISM to avoid online repair sources by using a local Windows ISO:

DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:X:\sources\install.wim:1 /LimitAccess

That bypasses Microsoft online servicing entirely, which is a good way to confirm the VPN is the actual trigger.

I would not immediately assume your Windows install is damaged. The timing with recent Norton updates makes the VPN/network layer the more likely culprit.

AI sourced content may make mistakes

[bjm]

and the whole SFC then DISM or DISM then SFC. I’ve read both arguments.
— that debate has been around for years, and both sequences have logic behind them.

The traditional modern recommendation is usually:

1. Run DISM first
2. Then run SFC

Reasoning:

• DISM repairs the Windows component store (WinSxS)
• SFC (sfc /scannow) uses that component store as its repair source

So if the component store itself is damaged, DISM repairs the source first, then SFC can properly repair system files afterward.

That sequence is often presented as:

DISM /Online /Cleanup-Image /RestoreHealth

then:

sfc /scannow

But the opposite order also has practical logic:

1. Run SFC first
2. Only run DISM if SFC reports corruption it cannot fix

Reasoning:

• SFC is faster and simpler
• many systems don’t actually need DISM
• avoids unnecessary servicing operations/downloads

So some admins use:

“SFC first as a quick integrity check, DISM only if needed.”

Honestly, in real-world troubleshooting, both approaches are defensible.

A lot depends on:

• symptoms,
• whether Windows Update is healthy,
• whether servicing corruption is suspected,
• and how invasive you want to be.

Your broader philosophy throughout this conversation has actually been pretty consistent:

reduce variables and avoid unnecessary overhead during repair operations.

Which is why your instinct toward:

• minimal background activity,
• VPN off,
• less third-party filtering,
• and simpler servicing flow

fits naturally with the “SFC first unless DISM is needed” school of thought.

Note — modern Microsoft guidance generally leans toward:

1. DISM first
2. Then SFC

especially on Windows 10 and Windows 11.

Microsoft’s logic is basically:

• repair the component store first,
• then let SFC use that repaired store to fix protected system files.

The common Microsoft-style sequence is:

DISM /Online /Cleanup-Image /RestoreHealth

followed by:

sfc /scannow

Historically, back in older Windows 7-era discussions, many users/admins often did:

• SFC first,
• DISM/System Update Readiness Tool second.

But with modern Windows servicing architecture, Microsoft documentation and support articles tend to present DISM → SFC as the preferred order.

That said, Microsoft does not usually frame SFC-first as “wrong.” It’s more:

DISM first is the comprehensive repair workflow.

While many experienced admins still pragmatically use:

“Run SFC first because it’s quick; escalate to DISM only if needed.”

So the debate persists mostly because both workflows often succeed in practice.

Guess, I’m old school. I like SFC then DISM.

That’s a pretty common old-school admin workflow.

The logic is straightforward:

• sfc /scannow
  = quick integrity check and possible easy fix

Then only escalate to:

• DISM /RestoreHealth
  = heavier servicing operation involving the component store and sometimes Windows Update sources.

A lot of longtime Windows users prefer:

start simple, escalate only if necessary.

Especially because DISM:

• can take much longer,
• may contact Microsoft servers,
• may involve servicing stack operations,
• and introduces more moving parts.

Your approach also aligns with your broader troubleshooting style from earlier:

• reduce noise,
• avoid unnecessary complexity,
• avoid extra overhead unless needed.

Microsoft’s newer guidance leans DISM-first because of how modern component-store servicing works, but your SFC-first mindset is still very defensible operationally.

What does SFC do after DISM?

SFC can still actively repair files after DISM.

The distinction is:

• DISM
  repairs the Windows component store (WinSxS)
• SFC
  repairs the actual protected system files in use

Think of it roughly like:

Tool	Primary Job
DISM	Repair the repair source
SFC	Repair the live system files

So if the component store is damaged:

• SFC may fail,
• or repair only partially,
• because its source files are corrupted too.

After DISM repairs the component store, then SFC can:

• re-scan the active OS files,
• compare hashes,
• and replace corrupted live files using the now-repaired store.

So the modern Microsoft logic is:

Repair source → Repair live files

That’s why DISM → SFC became the preferred official flow.

Your old-school approach still makes operational sense though:

• many systems have no component-store corruption at all,
• so SFC alone often fixes minor issues,
• making DISM unnecessary in many cases.

AI sourced content may make mistakes

[bjm]

@bjm

You can also force DISM to avoid online repair sources by using a local Windows ISO:
DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:X:\sources\install.wim:1 /LimitAccess

That’s basically the “don’t trust Windows Update as the repair source” approach.

Normally, when you run:

DISM /Online /Cleanup-Image /RestoreHealth

DISM may contact Microsoft’s Windows Update servers to obtain clean replacement files for damaged components.

But sometimes:

• Windows Update itself is broken,
• networking is unreliable,
• VPN/filtering interferes,
• or the needed files are unavailable online.

So Microsoft allows you to provide your own repair source from a Windows ISO.

Example:

DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:X:\sources\install.wim:1 /LimitAccess

What the switches mean:

Switch	Meaning
/Source:	tells DISM where to get clean files
install.wim	Windows image file from ISO
:1	image index inside the WIM
/LimitAccess	do NOT contact Windows Update

So DISM repairs Windows using:

• the mounted ISO files,
• instead of downloading anything online.

That can be useful when:

• Windows Update is corrupted,
• internet access is flaky,
• VPN causes issues,
• or servicing repeatedly fails online.

The important caveat:

• the ISO should closely match the installed Windows version/build/edition.

Example:

• Windows 11 25H2 Home ↔ matching 25H2 ISO preferred.

Otherwise DISM can complain that:

“The source files could not be found.”

This ISO-based method is often considered the more controlled/clean repair workflow because it removes:

• network variables,
• CDN issues,
• and Windows Update dependencies.

@bjm

So, I’d need to have the ISO and then mouth the ISO – as a known good file source?

Yes — exactly.
You would:

1. Download the matching Windows ISO from Microsoft
2. Mount the ISO in Windows
3. Use the mounted image as DISM’s repair source

When you right-click an ISO in Windows 10/11 and choose Mount, Windows creates a virtual DVD drive with a drive letter like:

• D:
• E:
• F:

Inside that mounted ISO is typically:

X:\sources\install.wim

or sometimes:

X:\sources\install.esd

Then DISM uses those files as the “known good” source instead of going online.

So conceptually:

Installed Windows ← repaired from ← mounted Windows ISO

That’s why many advanced users like the ISO method:

• fewer network dependencies,
• avoids VPN/CDN issues,
• avoids Windows Update weirdness,
• more deterministic repair source.

And yes — your phrase “known good file source” is basically the idea.

AI sourced content may make mistakes

[SoulAsylum]

The larger question is WHY run DISM with a VPN active? Is infection suspected?

SA

[MichaelR_Myers1]

OK to all. The information is helpful for future monthly system checks I will perform. FYI: DISM ran to 63% and stayed there for a very long time, then it progressed slowly to completion over about three hours. Mounting the ISO as suggested may be my next move!