Office Crashes 0xc0000374 and 0xc0000409: Heap and Stack Corruption at Runtime

Fix it now

Windows killed the Office process because a memory safety check failed inside it: 0xc0000374 is the heap manager finding its own structures corrupted, 0xc0000409 is a detected stack buffer overrun. The module named in the crash record is usually a victim, not the culprit, so find the culprit by removing components until the crash stops.

excel /safe
winword /safe
outlook /safe

1. If the application is stable in safe mode, the fault is in something safe mode did not load, and that is nearly always a COM add-in.
2. Open the crashing application normally, go to File then Options then Add-ins, set Manage to COM Add-ins and Go, and clear every tick. Confirm the crash has gone.
3. Re-enable half the add-ins and test, then half of whichever half brings the crash back. Four restarts finds one bad add-in among sixteen.
4. If safe mode also crashes, turn off hardware graphics acceleration in File, Options, Advanced, and install the display driver from the hardware vendor.
5. If the crashes follow printing or page setup, set the default printer to Microsoft Print to PDF while you test.
6. If none of that changes anything, repair the installation from Settings, Apps, Installed apps, your Office entry, Modify, then Online Repair.

Note the faulting module in the Event ID 1000 record, but do not act on it. Microsoft’s own guidance is that ntdll.dll, kernel32.dll and kernelbase.dll are frequently named as victims of corruption done earlier by another module.

If the application now survives the work that used to kill it, you are done. If not, the next section explains why the crash record cannot tell you who did the damage.

Why it happens

These are not ordinary errors. They are Windows deciding that the process has been damaged badly enough that continuing is unsafe, and terminating it without giving the application a chance to save anything. Microsoft publishes 0xc0000374 as STATUS_HEAP_CORRUPTION, the structure of the heap is corrupted, with the note that this condition can cause unpredictable behaviour. 0xc0000409 is STATUS_STACK_BUFFER_OVERRUN, a detected stack buffer overrun, described as often being a precursor to a memory corruption vulnerability.

A process gets one heap and shares it between everything running inside it, Office code and add-in code alike. When a component writes past the end of a block it allocated, it overwrites the heap manager’s bookkeeping for the block next door. Nothing happens at that moment. The failure arrives later, when some entirely unrelated code allocates or frees memory and the heap manager finds the structure it depends on is nonsense. That is when the process is killed, and the module named in the event is whichever one happened to be making that call.

That is not a theory about crash records; it is what Microsoft’s own application crash guidance says. Its wording is that modules such as ntdll.dll, kernel32.dll and kernelbase.dll are frequently caught as victims of corruption previously performed by misbehaving modules, because they are so heavily used. Reading the faulting module and going to that vendor is the commonest way to waste a day on this, and it is why the steps above are a bisection rather than a checklist.

Full reference

What each code is telling you

None of the five names a culprit. Three of them name the moment the damage was noticed. That is the whole reason this article is structured around removing components rather than around reading logs.

Where to aim the search

Page heap, and when it is worth it

If you have to hand a vendor evidence rather than a story, Microsoft’s documented tool for heap corruption is the page heap flag in GFlags. It makes the heap manager fail at the moment of the bad write rather than at the next unrelated allocation, which is what turns an unreadable dump into a useful one.

Page heap slows the target application considerably and increases its memory use. Microsoft’s instruction is to restart the process for the setting to take effect and to turn the flag off once the investigation is complete. Enable it for one image, on one machine, and set yourself a reminder to remove it.

When every common cause is ruled out

• Check whether the crash follows the user or the machine. Sign the same user in elsewhere, and sign a different user in here. That one test separates a profile problem from a machine problem in ten minutes.
• Run the Windows memory diagnostic overnight. Failing memory is an uncommon cause but a cheap one to rule out, and it explains crashes that follow no pattern at all.
• If one document reproduces it and others do not, the fault is in that file’s content. Copy the content into a new file in stages rather than repairing the old one.
• Check whether the add-in set is being restored by policy or by a management tool at every start. A bisection that keeps resetting itself looks like a random crash.
• Look for shell extensions as well as Office add-ins where the crash happens around file open and save dialogues rather than inside the document.

What not to do

• Do not reinstall Windows. Nothing about these codes points at the operating system, and you will still have the add-in afterwards.
• Do not disable the memory checks. They are not the fault; they are the thing that stopped a corrupted process from writing to your files.
• Do not chase the faulting module. Microsoft says plainly that it is usually a victim.
• Do not collect more crash dumps hoping for a pattern. A dump of a corruption crash shows the moment the damage was noticed, not the moment it was caused.

Every code this article covers

Confirm the fix worked

1. Repeat the action that used to crash at least three times, in a normally started application with the add-ins you intend to keep loaded.
2. Confirm no new Event ID 1000 with these exception codes has appeared in the Application log since the change.
3. Print, scroll and open a chart or a large document, so you exercise the drawing and printing paths as well as the one that failed.
4. If you enabled page heap, confirm you have turned it off again.
5. Leave the machine in normal use for a working day and check the log once more before calling it fixed.

Questions people ask about this