A family of Microsoft spreadsheet software with tools for analyzing, charting, and communicating data
The crash data shows application-crash behavior, but it does not identify a single confirmed root cause from the provided logs alone.
Supported findings from the logs:
- Event ID 1000 indicates an application crash.
- Exception code
0xc0000005in Event View 1 is an access violation crash. - Event View 1 shows the faulting module as
unknown, so that log does not isolate the component causing the crash. - Event View 2 shows
mscorwks.dllas the faulting module with exception code0xc00000fd, which is a stack overflow condition.
Given that the crashes happen while using VBA macros and Power Query, the most practical supported approach is to isolate whether the trigger is:
- an add-in,
- workbook content,
- the runtime environment,
- or a specific crashing component captured in Windows crash data.
Recommended troubleshooting path:
- Check Application log for repeated Event ID 1000 and 1001 pairs Repeated Event ID 1000 and 1001 entries indicate application crashing behavior and can help identify whether the same faulting module appears consistently.
- Start Excel in Safe Mode
- Open Run.
- Type
Excel /safe. - If Excel is stable in Safe Mode, test by disabling COM add-ins:
- File > Options > Add-ins
- Select COM Add-ins > Go
- Clear all check boxes
- Restart Excel normally
- Re-enable add-ins one at a time until the crash returns.
- Test the workbook in the cleanest possible environment
The documented guidance for Excel crash troubleshooting recommends checking whether the issue is file-specific or environmental.
- Test with a new blank workbook.
- Test the same actions outside any third-party-generated workbook.
- If the issue only occurs with one workbook, inspect workbook complexity such as excessive formulas, hidden objects, invalid names, or large numbers of shapes.
- Check whether the workbook is generated or modified by a third-party process If the file is produced by another application, test the same Excel features in a new workbook created directly in Excel. If the problem does not occur there, the workbook source may be contributing to the crashes.
- Move the file locally before testing Save and run the workbook from a local drive instead of a network location, redirected folder, SharePoint/Web folder, Citrix/Remote Desktop path, or other virtualized/network-backed location. This helps separate file corruption from storage-location issues.
- Check calculation behavior
For workbooks with complex formulas, set calculation to manual temporarily:
- Formulas > Calculation Options > Manual If stability improves, recalculation load may be part of the problem.
- Install the latest Office updates The Excel troubleshooting guidance explicitly says that if Excel does not start in Safe Mode, continue with installing the latest updates. Also, recent Excel updates have improved handling of large numbers of shapes and complex objects.
- Collect deeper crash data if the module remains unclear The Windows Server crash troubleshooting guidance recommends using Debugging Tools for Windows to analyze repeated Event ID 1000/1001 crash behavior and determine the faulting module when Event Viewer is insufficient.
What can be concluded from the two events:
- Event View 1: access violation in Excel, but no identified module.
- Event View 2: crash involving
mscorwks.dllwith stack overflow, which points to a runtime/component failure path rather than a normal Excel feature error. - Because the faulting modules are not consistent across the two samples, the logs do not prove one single root cause yet.
Most likely next isolation steps are:
- Reproduce in Safe Mode.
- Disable COM add-ins.
- Test the same macro/Power Query flow in a new local workbook.
- If only one workbook crashes, inspect workbook content and third-party generation.
- If crashes continue and Event Viewer remains incomplete, use Debugging Tools for Windows for crash analysis.
References: