0

According to

at the moment it's not possible to catch StackOverflowException programmatically, but I was wondering if it's possible to use debugger api (Debug or Debugger) and react to stack overflow exception?

Has anyone done something similar?

TarmoPikaro
  • 4,723
  • 2
  • 50
  • 62
  • 1
    Sounds like an[XY problem](https://xyproblem.info/) to me. – Uwe Keim Dec 10 '20 at 07:14
  • That does makes sense indeed - but for example we have difficult to catch problem where code works on 3 build machines out of 4. I'm also not sure with what probability problem manifests on 4th machine. Ideally I would like to halt application in a problematic point and at least get the call stack where it was going. At the moment application just terminates and call stack is not seeing. But need to test also whether problem can be easily reproduced on 4th machine. – TarmoPikaro Dec 10 '20 at 07:46
  • 1
    You should never catch it. You should fix the reason to why it's thrown. Anything else would corrupt your application. – jgauffin Dec 10 '20 at 08:01
  • How about creating a [Dump File](https://learn.microsoft.com/de-de/previous-versions/visualstudio/visual-studio-2015/debugger/using-dump-files) on the machine in question and then analyse this MDMP file in Visual Studio on your dev machine? – Uwe Keim Dec 10 '20 at 08:04

2 Answers2

0

A Stack Overflow caused by an endless recursive method call or an infinite loop actually saturates the stack of the current processus which leads to an unrecoverable process crash like a bulldozer that has crushed the entire alley of trees.

It is then impossible for the current process to catch this exception which goes out of the context of the process that lost the control and "does not exist anymore", and then only a debugger or a host application as explained in the link you provided can retrieve this information.

Nothing can be done at this point.

So before Windows 95 and especially NT, a stack overflow in a process usually and relentlessly caused a system crash because the processes were not isolated, not being in protected mode, and they crushed the whole land.

https://www.tutorialspoint.com/operating_system/os_processes.htm

Stack overflow

Protected virtual address mode

So you can't use a debugger API.

But you can write a special host that runs your app and controls it like the debugger do, perhaps for example:

Hosting EXE Applications in a WinForm project (CodeProject)

Creating a host application for the .NET Common Language Runtime (CodeProject)

Using HostBuilder and the Generic Host in .NET Core Microservices

.NET Generic Host

0

You can monitor your current call stack framecount using System.Diagnostics.Stacktrace.FrameCount. No way to determine the max framecount however, but if this number gets up very high you can bet you'll get in trouble soon.

André Boonzaaijer
  • 764
  • 4
  • 13
  • Indeed, at the beginning of the method you check a trigger to cause the escape... 100 calls for example. Also you can simply use an int counter: `if ( CheckOverflow++ > 100 ) return;`, having somewhere a private member or a local `int CheckOverflow;` that you set at `0` just before the first recursive call. This will break the chain. This also work for infinite complex imbricated loops. But this work only for dedicated processing and code, planned in advance and securized. –  Dec 10 '20 at 09:50