1

I am currently working on fixing a project for a client. A little information about the project first:

  1. Originally developed in Visual Studio 2012 using xp_v110 build tools
  2. Multiple projects in the solution
  3. Currently updating/debugging in Visual Studio 2017 using VS 2015/xp_v140 build tools
  4. Working on Windows 10

The application will run in debug mode, however if I just leave the application after starting the debug session (i.e. not opening/clicking on the application to open it as it starts minimized in the tray), the application crashes after 1-2 minutes.

Unfortunately the IDE is showing that the crash is taking place in chkstk.asm with the following message:

Exception thrown at 0x0064EDF9 in <<exe name>>: 0xC00000FD: Stack overflow (parameters 0x00000000, 0x000A2000).

I have updated the exception settings to break when all C++ Exceptions are thrown, checked the box that says "Break when this exception type is thrown", and wrapped the initial method that runs in a try block, however I can never catch the error in the C++ code; it always occurs in the chkstk.asm file.

Any suggestions on how I can find out where in the C++ code the exception is occurring. Like I said, this is an update for a client and the original programmer is not available, and they never commented their code, so it is difficult enough trying to go through all this. Any help/suggestions would be greatly appreciated. Thanks in advance.

fewlinesofcode
  • 3,007
  • 1
  • 13
  • 30
Dominick
  • 322
  • 1
  • 3
  • 16
  • Read [How to debug small programs](https://ericlippert.com/2014/03/05/how-to-debug-small-programs/). Consider trying some other *recent* compiler and debugger (e.g. [GCC](http://gcc.gnu.org/) and `gdb`, perhaps in its [MINGW](http://www.mingw.org/) variant). – Basile Starynkevitch Nov 01 '18 at 09:04
  • 4
    Unfortunately there's a mixup of terms here: Low-level crashes that happens on a hardware or operating-system level is often called *exceptions*. However, such exceptions are not C++ exceptions, and therefore can not be caught as such. – Some programmer dude Nov 01 '18 at 09:04
  • As for your problem, if you're really running inside the debugger then the debugger should catch the crash as it happens, and let you examine the function call stack, and also let you walk up the function call stack to your code. – Some programmer dude Nov 01 '18 at 09:06
  • Perhaps you have some [stack overflow](https://en.wikipedia.org/wiki/Stack_overflow). Put several breakpoints in your debugger to understand why is that happenning – Basile Starynkevitch Nov 01 '18 at 09:06
  • 3
    The code ran out of function call stack. Most likely cause is some kind of infinite recursion call. To catch these exceptions in debugger when they are thrown check "Win32 Exceptions" instead of "C++ Exceptions". And when the debugger pauses look into the "Call stack" view. – Dialecticus Nov 01 '18 at 09:11
  • Do you have any C++ experience? Jumping into bugfixing large poorly written legacy projects may be tricky. – user7860670 Nov 01 '18 at 09:15
  • If you can, use breakpoints to pin down EXACTLY where/when the crash occurs. You say its in the .asm file, can you determine which line? – Tom Nov 01 '18 at 09:23
  • @VTT - Yes, I have C++ experience, just been a long time since I've done it and I never had an issue down in the ASM code like this. – Dominick Nov 01 '18 at 10:01
  • 1
    @Tom - Yes, the error is occurring at line 99 in chkstk.asm (test dword ptr [eax],eax ; probe page. – Dominick Nov 01 '18 at 10:01
  • 1
    From my understanding of chkstk, it's not that there is a bug with chkstk, it's that there is a function somewhere in the project that is allocating too much stack space. I'd see @Dialecticus suggestion. – jacob Nov 01 '18 at 10:03
  • 1
    as @Dialecticus says - although it is sometimes easier to just break the program manually before the offending stack overflow happens - then use F10 and F11 to start investigation into why the recursing doesn't stop. – darune Nov 01 '18 at 10:26

0 Answers0