1

After "more time than was prudent" debugging an issue with handlers not being applied correctly, I've determined that the SiteRoot/web.config shown in IIS Manager is not actually used by IIS.

How do I know this? I've replaced Web.config with invalid XML - the site continues to run with default handlers and modules, while IIS Manager will, rightfully, throw an error on the invalid XML.

Information:

  • The test/invalid Web.config is not being read by IIS, or it would fail to parse.
    • Static content is being served, with a root relative to the Web.config.
  • The test/invalid Web.config is being read by IIS Manager, as it fails to parse/load (as expected).
    • Using "Explore" correctly opens up the folder the Web.config file exists in.
  • The NTFS case-sensitivity is disabled per this answer. The same issue persists with both web.config and Web.config casings.
  • The AppPool is running under a local account and the effective NTFS access has been verified.
  • There are no related Windows Application or System event logs indicating there was an error reading or parsing the configuration.

What might be occurring, and what further diagnosis can be done?

user2864740
  • 111
  • 1
  • 5

1 Answers1

0

While I have no idea what the initial cause was..

One of these two things 'fixed' it. Unfortunately, the specific change was change was not identified.

  1. Copied inetsvr's applicationHost.config from another machine.

    While this might have affected various globalModules, etc, the same AppPool and Site definitions were used as they are installed through automation.

    Due to this being a 'recovery' as VS Code truncated the original file, it is not feasible to diff for the relevant changes.

  2. Deleted the contents of C:\inetpub\temp\appPools.

    Due to the timing of changes, I cannot confirm if this operation was more/less relevant than using a different applicationHost.

user2864740
  • 111
  • 1
  • 5