So after a fairly length discussion (above) - My tuppence worth is that I don't think this is actually possible.
According to MSDN, a StackOverflowException will terminate your process...
Starting with the .NET Framework 2.0, you can’t catch a StackOverflowException object with a try/catch block, and the corresponding process is terminated by default.
If your process is terminated, you cannot then point the debugger back to your source code. that is because there is no reference. A simple example:
class Program
{
static void Main(string[] args)
{
Foo();
}
static void Foo()
{
Foo();
}
}
The above program will go into an infinite loop and throw a Stackoverflow exception. You (should) get a message that your process is terminated, and the debugger will show no stack trace information.
That last part is important; if there is no stack trace information - you (or rather your debugger) cannot walk back up the stack to your code.
Building this same example (and making it public) in release mode with no PDB files and referencing it from a second console application mimics the OP's question - calling 3rd party code with no source that throws a SO exception.
When I do this, I see in my debugger no information other than System.StackOverflowException was unhandled Message: An unhandled exception of type 'System.StackOverflowException' occurred in SoTest.exe
(and this is also the case if I enable 'Just my code') - the program subsequently terminates and I have no pointer as to where the process terminated.
I would recommend implementing AOP logging (I have used postsharp - and last time i checked was free - though this might not be the case anymore) to add logging to all your method boundararies in your inherited code, and then step from where the last line of logging occured to find the rogue call in the 3rd party assembly that is causing a SO exception.