Microsoft 365 Excel crashes with 0xc0000005 in ntdll.dll during ASP.NET Excel COM automation on Windows Server 2022

Question

Microsoft 365 Excel crashes with 0xc0000005 in ntdll.dll during ASP.NET Excel COM automation on Windows Server 2022

Kumar, Prakash (MTSL) 0

Microsoft 365 Excel crashes with 0xc0000005 in ntdll.dll during ASP.NET Excel COM automation on Windows Server 2022

Issue description

We are experiencing a production issue in our GPPS ASP.NET application, which generates Excel reports using Microsoft Excel COM Interop.

Excel crashes on the client production server when generating a report. The same report generates successfully in our local development environment.

We need help identifying the root cause of the Excel crash and determining whether it is related to the Microsoft 365 Apps build, Windows Server, Office updates, COM automation, or Excel cleanup/shutdown.

Environment details

Client production server:

Operating system: Windows Server 2022

OS build: 10.0.20348.5386

Office product: Microsoft 365 Apps

Excel version: 16.0.5569.1003

Process: EXCEL.EXE

Application: ASP.NET / IIS-based GPPS application

Application pool identity reported in our earlier logs: NT AUTHORITY\SYSTEM

Local development environment:

Excel version: Microsoft 365 Apps, Version 2609, Build 16.0.20430.20032, 64-bit

The report generates successfully in the local environment.

Windows Error Reporting details

Event ID: 1001

Event type: APPCRASH

Faulting application: EXCEL.EXE

Faulting application version: 16.0.5569.1003

Faulting module: ntdll.dll

Faulting module version: 10.0.20348.5386

Exception code: 0xc0000005

Fault offset: 0x00000000000a4637

Crash date: October 8, 2026, at 14:46:10 UTC

Application error details

Our ASP.NET application log reports the following call sequence:

Excel Application.Quit()

clsManageExcel.Dispose, line 55

clsGPPFC021Excel.PrepareExcelTemplate_SEWS

The failure occurs in the production environment, whereas the same report generation process succeeds locally.

We can provide the full Application Error logs, Windows Error Reporting details, and crash dump if required.

We would appreciate a root-cause analysis and recommended corrective actions that preserve the existing GPPS report output and functionality.

Error Details:

System
- Provider
[ Name] Windows Error Reporting
- EventID 1001
[ Qualifiers] 0 Version 0 Level 4 Task 0 Opcode 0 Keywords 0x80000000000000
- TimeCreated
[ SystemTime] 2026-10-08T14:46:10.5927558Z EventRecordID 4167 Correlation
- Execution
[ ProcessID] 0 [ ThreadID] 0 Channel Application Computer VMGPPAPP1.sewsna.com Security

EventData 2268655713847480686 4 APPCRASH Not available 0 EXCEL.EXE 16.0.5569.1003 6a96c16c ntdll.dll 10.0.20348.5386 534da4b0 c0000005 00000000000a4637 \?\C:\Windows\TEMP{C5363874-07EF-434B-ADAB-61D08D0979DA} - OProcSessId.dat \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.f776a38a-05a7-4e8d-975a-888453eed89d.tmp.dmp \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.92115edf-0622-4c72-8554-2f9f95b97f3a.tmp.WERInternalMetadata.xml \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.298e66c9-69da-4f5a-9142-46ccdc96b72f.tmp.xml \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.5b11aec8-991f-4fdb-a8da-9d278d749be9.tmp.csv \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.4fd42c4e-c642-48cc-b1a7-6209ef7336d9.tmp.txt \?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_EXCEL.EXE_448d7bcb1a1abaf877c81d1cd3b052c468e7b_cc5715d8_9fdbf3c1-9bfe-4658-8357-23789b70be13 0 8b05e682-1164-453d-9e20-c3954962476d 268435456 f1dbad4be42dd8f3ef7be25a158a116e 0

Viorel 127.3K Reputation points

2026-10-13T17:20:02.55+00:00
Maybe it is not a supported scenario.

https://support.microsoft.com/en-us/visio/considerations-for-server-side-automation-of-office

1 answer

Your answer

Viorel 127.3K Reputation points

2026-10-13T17:20:02.55+00:00

Maybe it is not a supported scenario.

https://support.microsoft.com/en-us/visio/considerations-for-server-side-automation-of-office

Answer 1

0xc0000005 indicates an access violation. In crash analysis guidance, this means a component of the application tried to perform an invalid memory access. When the faulting module is a common Windows module such as ntdll.dll, that module can be the victim rather than the true root cause.

For this case, the supported next step is to capture and analyze a full Excel process dump on the production server.

Verify prerequisites first:
- Confirm Windows Server 2022 is fully updated.
- Confirm the impacted Excel build is up to date.
- If antivirus is installed, confirm it is current and that required exclusions are in place.
Use Event Viewer correctly:
- Event ID 1000 is the actual application crash event.
- Event ID 1001 shows Windows Error Reporting information.
- The ntdll.dll fault does not by itself prove ntdll.dll is the root cause.
Configure Windows Error Reporting to collect full dumps for EXCEL.EXE.
- Run the WER dump-collection setup from an elevated command prompt on the production server.
- Configure it for the crashing executable name EXCEL.EXE.
- Monitor the dump folder for created dumps after reproducing the crash.
Enable page heap for EXCEL.EXE with GFlags.
- This is specifically recommended to trace corruption.
- Command:
```
     Gflags.exe /i EXCEL.EXE +hpa
```
- Restart the Excel process path so the setting takes effect.
- Warning: page heap adds overhead and should be used only for troubleshooting.
Reproduce the report generation from the ASP.NET/IIS application.
- Since the crash appears around Application.Quit() and cleanup, the dump captured at crash time is the key artifact.
- If dumps are created, analyze them with windbg.exe and !analyze, or provide them to the product owner for analysis.
Interpret the dump based on the exception:
- 0xc0000005: look for the failing call stack and identify application code or add-in/module involvement.
- If repeated functions appear, correlate them with the report-generation and cleanup path.
If the crashing code path uses multiple Excel instances or parallel copy/paste automation, reduce that immediately.
- A documented Excel known issue states that when an add-in or automation component performs clipboard-based copy/paste in parallel Excel instances, Excel can error or crash.
- Workarounds:
  - Use APIs that do not interact with the clipboard, such as getting and setting values by array where possible.
  - Avoid running clipboard-based tasks in multiple Excel instances or processes in parallel.
If the server recently migrated Office from 32-bit to 64-bit and the automation client is 32-bit, check for orphaned Office TypeLib registry entries.
- Documented symptoms include COM and .NET errors after Office architecture migration.
- The supported remediation is the Office TypeLib remediation script, or manual review of orphaned WOW6432Node\TypeLib entries that still point to missing Program Files (x86) Office executables.
- Warning: manual registry deletion is risky and should be backed up and validated before changes.
After data collection, remove the troubleshooting settings:
- Delete the WER registry key created for the process.
- Disable page heap:
```
     Gflags.exe /i EXCEL.EXE -hpa
```

Supported root-cause position from the available guidance:

The crash is consistent with an access violation, not enough to attribute directly to Excel, ntdll.dll, Windows Server 2022, or a specific Microsoft 365 Apps build from the event alone.
ntdll.dll as the faulting module can be incidental.
The decisive evidence must come from the Excel crash dump and failing call stack.
The most relevant documented areas to validate in this scenario are memory corruption during shutdown/cleanup, parallel clipboard-based Excel automation, and orphaned COM registration after Office architecture migration.

References: