When launching or adding an account to New Outlook, the sign-in window may stop responding and display a “Script Error” dialog. The message typically warns that an error has occurred in the script on this page, pointing to code failures at URLs such as login.microsoftonline.com, aadcdn.msftauth.net, or a third-party Identity Provider (IdP) endpoint like Okta or PingFederate. This prevents the OpenID Connect (OIDC) token exchange from completing, leaving the client stuck on a blank frame or an authentication loop.
Fast Fix
Terminate all Outlook processes in Task Manager, press
Win + R, paste%localappdata%\Microsoft\Olk, and delete the contents of that folder to clear the WebView2 authentication cache. If your organization uses an identity provider like Okta, open Internet Options > Security, and reset your Trusted Sites zone to default.
Diagnostic Snapshot
| Property | Details |
|---|---|
| Error Message | “An error has occurred in the script on this page” (Char / Line syntax error) |
| Protocol Impacted | OpenID Connect (OIDC) / OAuth 2.0 Modern Authentication |
| Engine Involved | Microsoft Edge WebView2 embedded browser runtime |
| Common Causes | Stale WebView2 cache, strict legacy Internet Options script blocking, or SSL inspection |
Why Script Errors Interrupt OIDC Sign-In
New Outlook does not use a native Win32 window to authenticate users. Instead, it embeds the Microsoft Edge WebView2 runtime to render modern authentication pages.
During an OpenID Connect (OIDC) handshake:
- The app directs the WebView2 frame to your identity authority (such as Microsoft Entra ID or Okta).
- The identity page executes JavaScript to process multi-factor authentication (MFA), evaluate device health (Conditional Access), and return an authorization code.
- New Outlook captures this authorization code and exchanges it for a secure token.
New Outlook (olk.exe)
└── Launches WebView2 Browser Frame
└── Loads OIDC Auth Page (login.microsoftonline.com)
├── JavaScript runs MFA / Device Health checks
│ └── SCRIPT BLOCKED / CACHE CORRUPT?
│ └── Dialog: "Script Error on this page" (Handshake Fails)
└── On Success: Returns OAuth token to Outlook
A script error indicates that the embedded browser failed to execute a critical JavaScript library required by the identity provider. This is typically triggered by corrupted local web storage, misconfigured Windows security zones, or an enterprise security gateway modifying web scripts in transit.
Progressive Troubleshooting Steps
Step 1: Clear the New Outlook WebView2 Runtime Cache
Corrupted cookies, expired session states, or damaged DOM storage in the app’s local user data folder are the most frequent causes of authentication script failures:
- Press
Ctrl + Shift + Escto open Task Manager. - Locate and end any tasks named:
olk.exemsedgewebview2.exe
- Press
Win + Rto open the Run box. - Enter the following path and press Enter:
%localappdata%\Microsoft\Olk - Select all files and folders inside the
Olkdirectory and press Delete. - Relaunch New Outlook. The embedded browser will download a fresh copy of the login scripts.
Step 2: Reset Legacy Internet Security Zones
Although WebView2 is modern, certain system-level proxy configurations and security restrictions are still inherited from legacy Windows Internet Options (WinINet). If JavaScript execution is restricted in your security zones, OIDC logins will break:
- Press
Win + R, typeinetcpl.cpl, and press Enter to open Internet Properties. - Go to the Security tab.
- Click Reset all zones to default level.
- Select the Trusted sites zone and click Sites.
- Ensure your identity provider endpoints are present if your organization enforces strict site lists:
https://login.microsoftonline.comhttps://aadcdn.msauth.net- Your custom IdP URL (e.g.,
https://yourcompany.okta.com)
- Switch to the Advanced tab, click Restore advanced settings, and verify that TLS 1.2 and TLS 1.3 are enabled.
- Click Apply and OK.
Internet Properties > Security Tab
├── [ Reset all zones to default level ]
└── Trusted Sites > Sites
├── <https://login.microsoftonline.com>
└── <https://aadcdn.msauth.net>
Step 3: Repair Edge WebView2 Runtime
If the script error appears as an empty white box with no text, or if the script engine crashes repeatedly, the underlying Windows WebView2 runtime may be corrupt:
- Open Windows Settings > Apps > Installed apps.
- Search for Microsoft Edge WebView2 Runtime.
- Click the three dots (…) and select Modify, then click Repair.
- If the repair option is grayed out or fails, download the Evergreen Bootstrapper from Microsoft’s WebView2 page and run the installer with administrative privileges.
For complete steps on resolving embedded browser crashes, see:
Step 4: Clear Stale Windows Identity Tokens
If the script error references an invalid token format or identity mismatch, clear the stored tokens in Windows:
- Open Windows Settings > Accounts > Access work or school.
- If your account shows a warning badge, click it and select Manage or re-authenticate.
- For persistent modern authentication token lockups, clear the local token cache using our dedicated guide:
Enterprise Escalation: Proxy and TLS Inspection Conflicts
In corporate network environments, script errors during OIDC authentication often originate from network perimeter devices:
- SSL/TLS Decryption: Security proxies (such as Zscaler, Palo Alto Networks, or Fortinet) that perform deep packet inspection may intercept and re-sign certificates for
login.microsoftonline.comor authentication CDN endpoints (aadcdn.msftauth.net). - Content Modification: If an intermediary proxy strips headers or injects custom script blocks into the authentication payload, WebView2’s strict Content Security Policy (CSP) will block the script from executing, throwing a syntax error.
Action for IT Admins: Configure your security appliances to bypass SSL inspection and proxy authentication for all official Microsoft 365 identity and login endpoints.