Ghosted pages in SharePoint don't render

After you install one of the following updates, some ghosted pages in Microsoft SharePoint don't render:

• Description of the security update for SharePoint Server 2019: September 8, 2020 (KB 4484505)
• September 21, 2020, update for SharePoint Server 2019 (KB4461512)
• Description of the security update for SharePoint Enterprise Server 2016: September 8, 2020 (KB 4484506)
• Description of the security update for SharePoint Foundation 2013: September 8, 2020 (KB 4484525)
• Description of the security update for SharePoint Foundation 2010: September 8, 2020 (KB 4486667)

For example, Microsoft Identity Manager (MIM) portal pages and some customized pages that are deployed through SharePoint Solution don't render.

Additionally, you may experience one or more of the following scenarios.

Scenario 1

The blocked ghosted page displays one of the following error messages: 

Scenario 2

The blocked ghosted page displays the following error message:

Scenario 3

The blocked ghosted page displays the following error message:

Ghosted pages are stored in the file system. Their security level is enhanced by forbidding server-side scripts and unsafe controls. A ghosted page may be blocked from rendering if the following conditions are true:

• The ghosted page contains in-line code or server-side script.
• The code-behind type or web part type isn't registered as safe.

To resolve this issue, add a new PageParserPath element that has a VirtualPath attribute to the Web.config file under the configuration/SharePoint/SafeMode/PageParserPaths element.

For example, you receive the following error message:

"The attribute 'autoeventwireup' is not allowed in this page."

In this case, you can add a PageParserPath element, as follows:

<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="15" TotalFileDependencies="250" AllowPageLevelTrace="false">
    <PageParserPaths>
        <PageParserPath VirtualPath="/<relativepath>/page.aspx" CompilationMode="Always" AllowServerSideScript="true" AllowUnsafeControls="true" IncludeSubFolders="True"/>
    </PageParserPaths>
</SafeMode>

If all pages in the same virtual directory have to be unblocked, you can use a PageParserPath element, as follows:

<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="15" TotalFileDependencies="250" AllowPageLevelTrace="false">
    <PageParserPaths>
        <PageParserPath VirtualPath="/<relativepath>/*" CompilationMode="Always" AllowServerSideScript="true" AllowUnsafeControls="true" IncludeSubFolders="True"/>
    </PageParserPaths>
</SafeMode>

To resolve this issue, add a new SafeControls element for the given type, namespace, and assembly strong name to the Web.config file under the configuration/SharePoint/SafeControls element, as described in SafeControls element (Solution). Then, set the Safe attribute to TRUE.

For more information about the format of the attribute values in the SafeControls element, refer to the table in step 12 in the "Marking Safe Controls in the Package Designer" section of How to: Mark controls as safe controls.

To resolve this issue, add a new SafeControls element that uses the Src attribute to the Web.config file under the configuration/SharePoint/SafeControls element.

For example, you receive the following error message:

"The referenced file '/_layouts/somedirectory/affectedusercontrol.ascx' is not allowed on this page."

In this case, you can add the SafeControls element, as in the following examples:

< SafeControls>
    <SafeControl Src="~/_layouts/somedirectory/*" IncludeSubFolders="True" Safe="True" AllowRemoteDesigner="True" SafeAgainstScript="True" />
</SafeControls>

< SafeControls>
    <SafeControl Src="~/_layouts/somedirectory/*" IncludeSubFolders="True" Safe="True" />
</SafeControls>