DriversRecommendedOutdated drivers can make a good PC feel brokenScan driver issues before chasing fixes manually.Scan NowHalloween DealsAmazon USHalloween week deals: useful picks before month-endAmazon US: current deals, useful picks and tech finds.Check DealsSlow PC?RecommendedPC slow today? Run a repair scan before it gets worseResolve common Windows issues and optimize system performance.Scan Now×
FREEDOM251

Freedom251 › Blog › 0x80070057

How to Fix IIS 0x80070057 “Access Denied” Errors

By Freedom251 Team · · 11 min read

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The code in the title is probably transposed. Microsoft documents 0x80070057 (one zero after the 7) as ERROR_INVALID_PARAMETER: one or more values supplied to IIS are incorrect or null. A genuine IIS access-denied configuration failure more commonly reports 0x80070005. Copy the HRESULT from the detailed IIS page, Event Viewer, or deployment log before changing anything; the exact code, HTTP status and substatus determine the correct repair.

Use the sequence below to separate a bad request from a configuration or permissions problem. It covers local files, UNC shares, HTTP.sys request rejection and one documented SMB edge case that can produce the same hexadecimal value.

As an Amazon Associate I earn from qualifying purchases.

What 0x80070057 means in IIS

In Microsoft’s IIS Application Host COM protocol, 0x80070057 means “one or more parameters are incorrect or null.” It does not, by itself, prove that Windows denied a file operation. The wording shown by a browser, deployment tool or custom application can be less precise than the underlying HRESULT.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Evidence you see What it usually indicates First direction to investigate
0x80070057 An invalid, missing or malformed parameter supplied to an IIS component Capture the complete request, module and configuration context
0x80070005 Access denied Check the application identity, IIS_IUSRS, NTFS ACLs and share permissions
HTTP 500.19 IIS could not read or apply configuration Validate applicationHost.config, web.config, section locks and read permissions
HTTP 400 or a 400.x substatus IIS or HTTP.sys rejected the request before the application handled it Inspect the raw request, limits, parsing errors and proxy rewriting

The spelling 0X800070057 contains an extra zero compared with the documented value. Do not silently “correct” it in a ticket or script: preserve the value that was actually emitted, then compare it with 0x80070057 and 0x80070005.

Collect the IIS evidence before making changes

Changing permissions or request limits without recording the failure can hide the original cause. Create a short incident record and reproduce the error once if possible.

  1. Copy the complete HRESULT. Include every digit and letter from the detailed error page, Event Viewer entry, deployment output or application log.
  2. Record the HTTP status and substatus. Examples include 400.x and 500.19. A substatus often identifies the failing IIS stage more precisely than the headline text.
  3. Write down the failing URL, site and application. Note whether the URL is local or remote, whether a virtual directory is involved, and whether only one application fails.
  4. Record the module and notification. The detailed IIS page may identify a module such as configuration, authentication, request filtering or another component, along with the notification stage.
  5. Identify the process identity. In IIS Manager, open Application Pools, select the pool, choose Advanced Settings and note its Identity. A custom account, a built-in service identity and an application-pool identity have different file and network rights.
  6. Capture the time and server name. Use the timestamp to correlate the request with IIS logs, HTTP error logs, Event Viewer and any reverse-proxy log.
  7. Preserve the request shape. Record the client, proxy path, HTTP method, headers, URL encoding and approximate request size. For a 400 response, capture the request with a client trace or network monitor rather than relying only on the browser message.

IIS access logs are normally under %SystemDrive%inetpublogsLogFiles; HTTP.sys error records are commonly under %SystemRoot%System32LogFilesHTTPERR. The exact location can vary with server configuration, so use the paths configured on the affected machine. Export or copy the relevant entries before clearing logs.

Choose the troubleshooting branch from the status

HTTP 500.19 or a configuration-read failure

Start with configuration and permissions. IIS has to read the server-level configuration, the site’s configuration and any configuration inherited by the application. A malformed XML document, a section that is locked at a parent level, an unsupported section or a missing module can all prevent the site from loading. If the detailed page names a file and line number, begin there rather than changing unrelated settings.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

HTTP 400 or another request-rejection response

Start with HTTP.sys and request evidence. IIS can reject malformed or nonconforming requests, requests that exceed configured limits or timeouts, and requests whose headers or URL cannot be parsed. A proxy that rewrites a URL or header can make a request fail on the server even though the same page works when requested locally.

401, 403 or a message explicitly saying access denied

Verify which layer denied the operation. Authentication failures concern the caller’s credentials; authorization failures concern the caller’s rights; a 500.19 failure can occur because the worker process cannot read configuration or content. The hexadecimal value and the detailed module information are more reliable than the browser’s short phrase.

Validate IIS configuration safely

  1. Back up the files first. Copy the current applicationHost.config and the affected site’s web.config to a protected folder. Keep the original timestamps and do not edit the only copy.
  2. Find the site’s physical path. In IIS Manager, open Sites, select the site and choose Basic Settings. Confirm that the path exists and that the application is pointing to the directory you think it is.
  3. Open the configuration named by the error. The server-level file is normally %windir%system32inetsrvconfigapplicationHost.config. A site or application can also contain a web.config. Check the exact file and line identified on the error page.
  4. Check XML structure. Look for an unfinished element, a duplicate attribute, invalid characters, a bad closing tag or a value with the wrong type. Compare a recent known-good backup when one exists.
  5. Check section availability. A section may be locked at a parent level, may require a module that is not installed, or may be unsupported by the installed IIS feature set. The detailed error usually names the section or module; correct that specific dependency instead of deleting broad configuration.
  6. Review recent changes. Roll back the last configuration edit, deployment transform, rewrite rule or installer change in a controlled way. Do not overwrite a working server-wide file with a file from another Windows or IIS version.
  7. Test configuration parsing. Use IIS Manager or the installed IIS command-line tools to list the site configuration. Run administrative tools in an elevated prompt and treat any parser error as useful evidence; do not continue to make edits while the file is syntactically invalid.

Do not remove a section merely because it is reported as locked. A parent administrator may have intentionally restricted it. Unlock only the named section when your server policy permits it, and document the change.

Correct local file and directory permissions

Once the configuration is valid, make sure the worker process can traverse the directory tree and read the files it needs. IIS commonly needs read and execute access to the application directory, configuration files, static content and any parent directories required to reach them.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  1. Identify the effective account. In Application Pools → Advanced Settings → Identity, note whether the pool uses ApplicationPoolIdentity, a built-in account or a named account. For an application-pool identity, the account name is commonly IIS AppPoolPoolName.
  2. Inspect existing ACLs before granting anything. From an elevated Command Prompt, run icacls "D:SitesExample" with your real path, or use the folder’s Security tab. Check the folder, its parents and the specific configuration file named by the error.
  3. Grant the minimum required rights. Where policy allows, grant read and execute access to the application-pool identity or to IIS_IUSRS on the application content. A typical command is icacls "D:SitesExample" /grant "IIS AppPoolExamplePool":(OI)(CI)(RX) /T; replace both names and the path, review the result, and do not run it against a system directory.
  4. Check inheritance and explicit denies. An inherited deny entry, a missing traverse permission on a parent folder or a file moved outside the expected tree can defeat an apparently correct grant. Remove an explicit deny only after confirming that it is not part of your security design.
  5. Retest with the same identity. Recycle only the affected application pool, request the failing URL and check the new log entry. If the failure changes from 500.19 to an application error, the permission problem may be resolved and the next layer is now visible.

Do not grant Everyone full control, disable ACL inheritance across an entire drive or make configuration files writable by the worker process just to make the error disappear. Those changes expand the attack surface and can conceal a deployment mistake.

Check UNC paths, shares and pass-through authentication

If the content or configuration is on a UNC path such as \serversharesite, local NTFS permissions are only half of the check. The account used by IIS must be authorized both at the share and at the NTFS layer.

  1. Confirm the UNC path resolves from the server. Test the exact path from the IIS machine, not from an administrator workstation. A mapped drive in your interactive session is not automatically visible to the IIS worker process.
  2. Review the virtual-directory connection settings. In IIS Manager, open the virtual directory’s Basic Settings and inspect Connect as. Pass-through authentication uses the application’s identity; it can fail when that identity has no rights on the remote server.
  3. Choose an explicitly authorized account when needed. Use a managed domain or service account approved by your administrator, store its credentials through the IIS connection settings, and grant it only the required share and NTFS rights. Verify password rotation and account lockout policy.
  4. Check both permission layers. A share permission that allows read access does not override an NTFS deny, and an NTFS grant does not override a restrictive share permission. Test directory traversal, file reads and configuration reads separately.
  5. Retest without changing unrelated settings. If a local copy works but the UNC path fails, keep the request and application configuration unchanged while you correct the network identity or permissions.

Microsoft specifically identifies UNC pass-through authentication and insufficient read permissions for ApplicationHost.config, Web.config, virtual directories or application directories as causes of some IIS 500.19 failures. That guidance applies to the matching configuration scenario, not to every occurrence of 0x80070057.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Investigate malformed or oversized requests

For HTTP 400 responses, changing ACLs will not help if the request is rejected before the application runs. Compare a failing request with a known-good request and preserve the raw details.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • Headers: look for invalid characters, duplicate or contradictory values, unexpected line breaks and headers enlarged by a proxy.
  • URL and encoding: check malformed percent encoding, illegal characters, an unexpectedly long path and a proxy rewrite that produces a different URL than the client sent.
  • Size and timeouts: check request-header, URL, body and connection limits at HTTP.sys, IIS request filtering, the reverse proxy and the application. Raising one limit can simply move the rejection to another layer.
  • Client and proxy differences: send the same request directly to the IIS server and through the proxy, where policy permits. A direct success with a proxied failure points to rewriting, header limits or timeout settings in the intermediary.
  • Method and protocol: verify that the method, HTTP version and required headers match what the site and any upstream device support.

Use the IIS and HTTP error logs together with a client trace or network monitor. Microsoft’s IIS troubleshooting guidance notes that an HTTP client can receive a 400 response when HTTP.sys parsing rules, limits, timeouts or other required checks reject the request. Preserve that evidence before relaxing a limit.

Best Value
Sale
Learn Windows IIS in a Month of Lunches
  • Used Book in Good Condition

Recognize the documented SMB effective-access edge case

There is a separate, narrowly defined Windows issue that also returns 0x80070057. On Windows 8.1 and Windows Server 2012 R2, viewing effective access on a share hosted by some non-Microsoft SMB 3.0 servers could fail when the security descriptor returned by the server had no owner field. The failure occurs in Windows Explorer’s effective-access view; it is not a general explanation for IIS configuration errors.

  1. Confirm that the operating system is Windows 8.1 or Windows Server 2012 R2.
  2. Confirm that the share is hosted by a third-party SMB 3.0 server and that the error appears while viewing effective access.
  3. Apply the Microsoft update that addresses the issue for the applicable operating-system edition and servicing level.
  4. If updating is not immediately possible, use the documented workaround of mapping the share to a drive letter, then repeat the access check.

Do not apply this workaround to an unrelated local IIS error, a malformed request or a normal ACL problem. The operating-system version, SMB provider and effective-access symptom must match.

Use servicing repair only when logs point to corruption

System repair is a last branch, not the first response to an IIS permission message. Microsoft lists 0x80070057 as ERROR_INVALID_PARAMETER and notes that DISM can help when component or update corruption is involved. Run servicing repair only when Event Viewer, servicing logs or an update failure provide that evidence.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  1. Open an elevated Command Prompt on a maintenance window.
  2. Run the DISM repair procedure approved for your Windows Server build, such as DISM /Online /Cleanup-Image /RestoreHealth, and wait for it to finish.
  3. Review the result and servicing logs for errors rather than assuming completion means IIS is fixed.
  4. Reboot if the servicing operation requires it, then retest the same URL and compare a fresh IIS log entry with the original.

A registry cleaner or a broad “repair” operation is not a substitute for identifying the failing IIS module, configuration file, identity or request.

Quick Recap

SaleBestseller No. 3
SaleBestseller No. 4
SaleBestseller No. 5
Learn Windows IIS in a Month of Lunches
Learn Windows IIS in a Month of Lunches
Used Book in Good Condition
$42.06

Verify the fix and prevent recurrence

  1. Retest the original case. Use the same URL, method, client and proxy route that produced the error.
  2. Test a control case. Request a static file or a known-good application on the same server to determine whether the problem is site-specific.
  3. Check the new logs. Confirm that the original HRESULT and status/substatus no longer appear, and investigate any new code rather than assuming it is unrelated.
  4. Exercise the deployment path. If a deployment caused the failure, repeat configuration validation and a read test under the actual application-pool identity.
  5. Document the change. Record the corrected ACL, account, configuration line, update or proxy setting, along with the server and IIS versions.
  6. Keep least privilege. Remove temporary broad grants, diagnostic mappings and test credentials after verification.

Quick decision table

Observed combination Most useful next action Avoid first
0x80070057 with 500.19 and a named config file Validate XML, section locks, modules and read access to the named file Changing HTTP request limits
Explicit access denied with a local path Check the worker-process identity and NTFS traversal/read rights Granting Everyone full control
500.19 on a UNC path Verify pass-through or explicit credentials plus share and NTFS permissions Relying on a drive mapping from an administrator session
400.x with malformed or large request evidence Capture the request and inspect HTTP.sys, IIS, proxy and client limits Editing ACLs or running system repair
Effective-access view fails on Windows 8.1/Server 2012 R2 with a third-party SMB 3.0 share Apply the applicable update or map the share as the documented workaround Assuming every IIS 0x80070057 report is this SMB bug

After you have collected the IIS evidence and completed the relevant manual checks, Outbyte PC Repair is an optional Windows shortcut for common system issues, settings checks, temporary and cache cleanup, vulnerability checks and crash logging. It runs on Windows 11, 10, 8 and 7, offers a free trial by category for at least two days before a subscription, complements antivirus software rather than replacing it, and results vary; no tool repairs every IIS or application crash.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

0x80070057HTTP 400HTTP 500.19HTTP.sysIISpermissionsUNCWindows Server

Leave a Reply

Your email address will not be published. Required fields are marked *

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Recommended PC Tool
Recommended PC Tool
Windows Errors? Fix Them Before They SpreadFree repair scan
Crashes, No Sound, or Screen Glitches?Free driver scan

Two free Windows tools

One Free Minute Could Fix That PC

Before you go - each of these free tools takes about a minute and tackles what quietly slows a Windows PC down.

Special offer. View Outbyte info, uninstall instructions, EULA, and Privacy Policy.