Share via

WIndows 11, Microsoft Edge (v145.0.3800.97) - iexplorere.exe Class not registered Error Code3: 0x8004011

Zeshan Uddin 0 Reputation points
2026-05-19T12:16:02.85+00:00

Dear all,

I am experiencing a strange issue affecting some of the USERS on the network‑connected computers.

All machines are deployed via SCCM, have identical builds, and are the same make/model.

Environment

All devices deployed via SCCM

Identical hardware (same make/model)

Identical OS build and application baseline

Microsoft Edge (latest enterprise channel)

Domain‑joined Windows environment

Issue Description

Recently, a user reported that Microsoft Edge displays Error Code 3: 0x80040111 – “We could not create a component.”

At the same time, when clicking certain intranet hyperlinks, the system shows “iexplore.exe – Class not registered.”

When User A logs into Computer A and browses our intranet using Microsoft Edge, they click a hyperlink that should open a network directory. Normally, this opens the folder directly in Windows Explorer.

However, instead of opening the directory, the following error appears:

iexplore.exe – Class not registered

User A has used Computer A previously without any issues.

Observation

Microsoft Edge → About page shows:

Error Code 3: 0x80040111 – “We could not create a component.”

When clicking intranet hyperlinks that should open a network directory in Windows Explorer, the system displays:

“iexplore.exe – Class not registered.”

Not a hardware issue

Not a global user account issue

Not a global OS image issue

Something corrupts or modifies the user profile on a specific machine after login

Troubleshooting Performed

Test 1:

User A logs into Computer B → No issue.

Test 2:

User B logs into Computer A → No issue.

Test 3:

I deleted User A’s profile on Computer A. When User A logs back in, a new profile is created → Issue temporarily resolved. However, the problem returns within 24 hours.

My Understanding So Far

It does not appear to be a machine issue, because other users do not experience the problem on the same machine

It does not appear to be a user account issue, because the same user does not experience the problem on other machine.

The issue seems tied to something that becomes corrupted within the user profile on a specific machine, possibly related to Edge components or legacy Internet Explorer integration.

When the issue occurs, the Microsoft Edge > About page shows:

Error Code 3: 0x80040111 – We could not create a component

Deleting the user profile fixes the issue temporarily, but it returns, suggesting something is being corrupted or overwritten after login.

I would really appreciate, if someone has any idea how can this issue be resolved.

Thank you very much .

Microsoft Edge | Other | Windows 11
0 comments

Answer recommended by moderator

Zeshan Uddin 0 Reputation points
2026-06-03T14:00:44.19+00:00

I installed all pending updates (including MS WebView2 and others). I also reset Microsoft Edge and deleted the existing profiles.

After deleting the profile, Edge restarted. I closed it immediately and then restarted the computer.

This has resolved the issue.

Was this answer helpful?

0 comments

3 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-05-19T12:16:30.64+00:00

    The behavior matches a per‑user corruption affecting Edge and legacy Internet Explorer components on a given machine, and the tests already performed strongly indicate a profile‑specific problem on that device rather than a global image, hardware, or account issue.

    From the available context, the closest supported guidance is:

    1. Treat this as a profile‑level corruption
      • Similar to the roaming‑profile issue where Edge and other apps crash after second logon because the profile service resets registry permissions, this scenario points to damaged or mis‑permissioned per‑user registry keys or COM registrations that Edge/IE rely on.
      • Deleting the profile and letting Windows recreate it temporarily fixes the issue, which is consistent with profile data or registry hives becoming invalid after some subsequent operation (e.g., GPO, logon script, or profile sync process).
    2. Validate whether a profile or logon process is resetting permissions
      • In the documented roaming‑profile case, the cause is: “the profile service unexpectedly resets the permissions on some registry keys during logon,” which then breaks Edge and other apps.
      • In this environment, check whether:
        • Roaming profiles, folder redirection, or third‑party profile tools are in use on the affected machine.
        • Any logon scripts, GPOs, or management tools are modifying HKCU or user‑specific COM/IE/Edge keys after the first successful logon.
    3. Compare a “good” and “bad” state for the same user on the same machine
      • Immediately after recreating User A’s profile on Computer A (when Edge works and no “Class not registered” error appears), export the relevant user registry hives (especially HKCU\Software\Microsoft\Edge and HKCU\Software\Microsoft\Internet Explorer and related COM keys under HKCU\Software\Classes).
      • After the issue reappears (within 24 hours), export the same keys again and compare for:
        • Missing keys or values.
        • Permission changes (ACLs) on keys.
        • Unexpected entries introduced by scripts or third‑party tools.
    4. Check for Windows and Edge updates that address profile‑related crashes
      • The documented Windows 10 issue where Edge and other apps crash with roaming profiles was resolved only by installing a specific cumulative update and then running the associated EasyFix.
      • Ensure all Windows 11 devices are fully updated and that any equivalent cumulative updates addressing profile/registry permission issues are installed.
    5. If a profile management or roaming solution is in use
      • Review its configuration to ensure it is not:
        • Restoring stale registry hives from another device.
        • Applying incorrect ACLs to HKCU keys on subsequent logons.
      • Temporarily exclude Edge/IE‑related registry paths from roaming or redirection to see if the issue stops recurring for User A on Computer A.
    6. If the issue persists after eliminating profile tools and confirming updates
      • As with the documented roaming‑profile problem, the durable fix may require both:
        • Ensuring the OS is on a build that includes the relevant cumulative fixes.
        • Resetting the affected user’s profile one final time after the environment is corrected so that the corruption does not reoccur.

    Because the context does not provide a specific Edge policy or setting that directly causes “Error Code 3: 0x80040111 – We could not create a component” or “iexplore.exe – Class not registered,” the supported path is to focus on user‑profile registry/permission integrity, Windows update level, and any roaming/profile‑management components that might be altering HKCU after logon.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

    1 person found this answer helpful.
  2. Zeshan Uddin 0 Reputation points
    2026-06-03T14:01:12.7366667+00:00

    Thank you for your help

    Was this answer helpful?

    0 comments
  3. Alex-L 7,060 Reputation points Microsoft External Staff Moderator
    2026-05-23T00:35:18.4133333+00:00

    Hi Zeshan Uddin

    I can understand how frustrating this kind of intermittent, profile‑specific issue can be, especially when you’ve already done thorough isolation and keep seeing it return after a clean profile rebuild.

    Have you got the chance to review the Q&A Assist suggestions? If you haven't, one additional angle to consider is that the combination of Edge “component could not be created (0x80040111)” and “iexplore.exe - Class not registered” usually indicates a failure in COM activation or user‑level protocol/shell handlers, rather than a browser‑only fault. These errors generally occur when required components or registrations are missing, corrupted, or no longer accessible to the user context.

    Given that the issue is triggered specifically by intranet links handing off to Explorer (e.g., UNC paths), it would be useful to verify whether file/protocol handlers or shell associations (such as file://, folder, or directory handlers) are being altered for the affected user after login.

    Also keep in mind that on Windows 11, Internet Explorer is no longer a standalone component, and related functionality relies on Edge integration and compatibility layers. Any inconsistency in that integration can surface as “iexplore.exe - Class not registered” even though IE itself is no longer actively used.

    Because the issue reappears after some time, it’s worth focusing on processes that execute post‑logon or periodically, such as:

    • Scheduled tasks running in the user context
    • Security or endpoint protection tooling modifying browser/COM behavior
    • Edge or WebView2 update/repair processes affecting per‑user components

    As a quick validation when the issue is present, you can try opening the same UNC path directly via Run (Win + R) or File Explorer. If that works normally, it helps confirm the fault is isolated to browser-to-shell handoff or handler resolution, rather than Explorer itself.

    I hope this helps point you in a direction that gets closer to identifying the exact trigger, feel free to share any additional findings here should anything come up.

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.