An unhandled exception outside of my program

Question

0.00/5 (No votes)

See more:

Hi!

When I want to try execute my program, This exception occurs:

An unhandled exception of type 'System.StackOverflowException' occurred in Microsoft.VisualStudio.HostingProcess.Utilities.dll

If I click to break button, it says there is no source avaiable. In the call stack none of my program's functions are called. How can I find the problem, or what can I do?

Thanks in advance.

Posted 6-Jan-12 20:55pm

Dávid Kocsis

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Accepted Answer · 2012-01-06T21:38:00

Solution 1

Best guess? Stack Overflow normally means that a method is calling itself - directly or indirectly - and causing too many return addresses to be pushed on the stack.

What causes that is harder to pin down: Try commenting out most of your code until the problem goes away, and then put it back in chunks until it occurs again. You should be able to narrow it down somewhat from that. (You can comment out large blocks by highlighting them and pressing CTRL-K CTRL_C, and uncomment them with CTRL-K CTRL-U)

Sorry, but without looking at your code in some detail, I can't be more precise.

Posted 6-Jan-12 21:38pm

OriginalGriff

Comments

Dávid Kocsis 7-Jan-12 5:27am

Thanks, I'll try to find it. It's 37 166 lines long, so won't be simple.

OriginalGriff 7-Jan-12 5:36am

They never are! :laugh:

Sergey Alexandrovich Kryukov 7-Jan-12 14:17pm

Griff, this time I'm not 100% agree. I know for sure this kind of bug is the easiest to detect and pin-point. Your method of commenting out can be useful (I actually used it sometimes), but it is excessive. One can easily perform debugging without code modification. One problem or commenting out is that there is certain danger to trace back your steps with some additional accidental mistakes. I would advice to make the whole code read-only. However, with good confidence modification can be use as well.

I tried to explain all that in my answer -- please see.
--SA

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-01-07T08:13:00

In my opinion, stack overflow is one of the easiest to find bugs. You just need to work methodically; and I'm not saying it's fast, it's just simple, which is not the same.

You see, fatal issues are always easier to deal with because they are easy to see. In case of stack overflow, you don't even have to modify code as Griff suggests. You make an initial guess on at least one method which is attempted to get called "infinite" number of times. Usually it does not take long to find such place. You put breakpoint(s) on a very beginning of such method(s) and try to confirm it happens. When the execution is stopped on a breakpoint, you can go up the stack or down the stack. It's more effective to go down: you keep the breakpoint and debug just one this method stepwise, making big steps at first, until you catch the same method being called deeper in stack (remember your breakpoint is still there). When it happens, you start over and go in smaller step until you pinpoint where the recursion goes. This time try to figure out why the condition of the recursion end is never met. At the same time you move your breakpoint(s) closer to the source of recursive call, narrowing your net.

It may sound difficult, but with little practice always gives 100% results, unlike the cases with different bugs of some unknown nature. In case of stack overflow, you can be 100% sure that you can find the problem before you start looking.

—SA