0

I have an application that has started failing with 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

I have a full crash dump and source code, but this leads me to terminate() and abort() functions in the Windows API and I can't see any application-specific code stepping through the call stack.

The user has indicated they get an Out of Memory error when launching the app UI (it can run on the command line or launch a UI).

My question is, does the above exception indicate the application is trying to load too much data onto the stack and if it does is there any way to detect which variable and preferably which line of code causes the stack buffer overrun to occur? I am analysing the dump file using WinDbg and Visual Studio.

The stack is below.

WARNING: Stack unwind information not available. Following frames may be wrong.
00 0019d2f8 00868f91 MyApp+0x4ccf73
01 0019d308 7490e9a2 MyApp+0x468f91
02 0019d39c 7709d30e KERNELBASE!UnhandledExceptionFilter+0x172
03 0019ffdc 77061b34 ntdll!__RtlUserThreadStart+0x3b7d4
04 0019ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
DLT
  • 139
  • 8
  • You should have MyApp.pdb. Load it for the module MyApp.exe in the debugger. – 273K Apr 05 '22 at 00:53
  • This is frequently due either to overrunning a fixed-length buffer or some sort of pointer naughtiness -- using it before it's assigned a value or after it's freed, for instance. – Joseph Larson Apr 05 '22 at 01:37
  • Most likely something is writing past the end of an array on the stack. The first thing to do is figure out how to reliably reproduce the crash on your own machine; once you know the steps to make the program crash on command, you can start running experiments to narrow down where and how the corruption occurs. Without being able to reproduce the fault, you're limited to guessing-and-hoping, which tends to add bugs rather than remove them. – Jeremy Friesner Apr 05 '22 at 05:48

1 Answers1

1
  1. Activate Application Verifier for your application. It helps finding the problem more closely to the actual root cause.
  2. Then run it using a debugger.
  3. Fix your symbols
  4. Use a large CounterString (16 MB or so; funny generators here) and paste it into every textbox you have. This will probably overflow every unprotected buffer you have in your application.
  5. Wait for the application to throw an exception. It may not be the exact exception you're seeing, because Application Verifier may have introduced his own exceptions.
  6. Analyze the exception and look out for hints given by Application Verifier. It may give you helpful additional information which is only available because you activated Application Verifier.
  7. If needed, make use of the CounterString and find it in the memory (likely on the stack in your case)
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • It turns out the binary file they were opening was too large. the binary file contains data, including historical data. They compacted this file to remove historical data and now the issue has gone. I'm not sure how opening this object on the heap would create this stack buffer overrun but I'll keep investigating. – DLT Apr 06 '22 at 22:04