Hi @RC-21051146-0 ,
Thank you for providing those additional details. This information significantly narrows down the possible cause.
Based on your findings:
- These are System Views.
- The issue occurs with both standard and custom fields.
- The problem occurs for all users.
- Most importantly, a newly created System View with the same columns also reproduces the issue.
This makes it less likely that the problem is caused by corruption or an invalid definition of a particular existing SavedQuery/System View.
Since the issue can be reproduced with a newly created view and affects all users, the problem appears to be more likely related to one of the following:
- A server-side/query rendering issue introduced after the upgrade.
- A metadata resolution problem involving Lookup/Currency attributes.
- A problem with the upgraded CRM web application or one of its required resources/endpoints.
- A regression specific to the Dynamics 365 On-Premises build currently installed.
One important point regarding the URL you provided:
The following URL is the URL used to open the entity view page:
main.aspx?...&pagetype=entitylist...
However, it may not be the actual request that is returning the 404 / 0x80072503 error.
I would recommend checking the issue again using the browser Developer Tools:
Please capture the actual failing request
- Open the affected view.
- Press F12 to open Developer Tools.
- Go to the Network tab.
- Clear the existing requests.
- Reload the view.
- Filter for failed requests, especially requests returning 404.
- Identify the exact request that fails and share:
- Request URL
- HTTP Status Code
- Response/Error message
- Request/response details if possible
This is important because the main.aspx page itself may load successfully while another CRM endpoint, JavaScript resource, API request, or metadata-related request fails in the background.
Additional server-side checks
Since the issue started immediately after the upgrade, I would also recommend checking the following while reproducing the issue:
- CRM Trace logs
- IIS logs
- Windows Event Viewer
- Application Event logs
Ideally, enable CRM tracing, reproduce the issue with the problematic Currency or Lookup column, and then check whether the trace identifies a specific attribute, entity, endpoint, assembly, or resource that cannot be resolved.
Important troubleshooting test
Since you mentioned that the problem is related to Currency and Lookup columns, I would also suggest testing the fields individually and documenting the exact results.
For example:
| Test | Result |
|---|
| View with standard fields only | Works / Fails |
| Add Lookup Field A | Works / Fails |
| Add Lookup Field B | Works / Fails |
| Add Currency Field A | Works / Fails |
| Add Currency Field B | Works / Fails |
The key question is whether:
- every Lookup/Currency field fails, or
- only specific Lookup/Currency fields fail.
If every Lookup and Currency field causes the same behavior, that would further support the possibility of a platform-level issue after the upgrade.
If only specific fields fail, we should investigate the metadata and dependencies of those particular attributes.
My recommendation at this stage
Because:
- the issue did not exist in 9.0.47.08,
- it started after upgrading to 9.1.46.06,
- it affects all users,
- it affects System Views, and
- it can be reproduced even with a newly created view,
I would now treat this as a possible upgrade regression or server-side issue rather than a SavedQuery/view definition problem.
The next most useful step would be to capture the actual failing Network request and corresponding CRM trace entry.
Also, I would recommend verifying that the environment is fully updated to the latest supported Dynamics 365 On-Premises cumulative update, including any required server-side components. If the issue still reproduces after applying the latest supported update, the reproducible scenario would be strong evidence for opening a Microsoft Support case.
If you can share the actual request from the Network tab that returns HTTP 404, or the relevant CRM trace error generated at the same time, we can investigate further and potentially identify exactly which CRM component or resource is failing.
