Visual Studio 2008 crashes on C# unhandled exception

  • Thread starter Thread starter MP
  • Start date Start date
M

MP

I just got a new box running Windows 7 64 bit Home premium. And I've
installed VS 2008 with the feature pack and service pack. When I was making
so changes to an existing C# forms application, I managed to generate an
unhandled exception for a system argument. This totally locked up Visual
Studio - I got the dialog asking me to debug or continue and then total
freeze. I had to kill VS with the task manager.

I can't reproduce this on a Vista 32 bit system or an XP 32 bit system.

Any suggestions welcome!

Thanks....

Mike
 
MP said:
I just got a new box running Windows 7 64 bit Home premium. And I've
installed VS 2008 with the feature pack and service pack. When I was
making so changes to an existing C# forms application, I managed to
generate an unhandled exception for a system argument. This totally
locked up Visual Studio - I got the dialog asking me to debug or
continue and then total freeze. I had to kill VS with the task manager.

I can't reproduce this on a Vista 32 bit system or an XP 32 bit system.

Any suggestions welcome!
Click to expand...

You'll have to do the hard work yourself. Trim your project until the
problem goes away. Then add back whatever you last trimmed. Figure out
what, exactly, it is in the project that's causing a problem.

A likely cause is some kind of platform-dependence problem. A project
or dependency with the "CPU Type" set to the wrong setting (e.g. x86
when the whole project is "Any CPU" or something like that), for
example. But there's really no way for any of us to suggest what the
problem is without a concise-but-complete code example, and you can't
provide a concise-but-complete code example without doing a lot of
leg-work first.

For what it's worth, I use VS2008 on 64-bit Windows 7 on a semi-regular
basis without any trouble at all. My primary platform is still x86, but
I know for sure VS2008 typically works fine on 64-bit.

Pete
 
Peter Duniho said:
You'll have to do the hard work yourself. Trim your project until the
problem goes away. Then add back whatever you last trimmed. Figure out
what, exactly, it is in the project that's causing a problem.

A likely cause is some kind of platform-dependence problem. A project or
dependency with the "CPU Type" set to the wrong setting (e.g. x86 when the
whole project is "Any CPU" or something like that), for example. But
there's really no way for any of us to suggest what the problem is without
a concise-but-complete code example, and you can't provide a
concise-but-complete code example without doing a lot of leg-work first.

For what it's worth, I use VS2008 on 64-bit Windows 7 on a semi-regular
basis without any trouble at all. My primary platform is still x86, but I
know for sure VS2008 typically works fine on 64-bit.
Click to expand...

Ok -- here's a concise example:

Create a new project (Windows Forms).
Drop a dateTimePicker on the form.
Add an event for the dateTimePicker 'Value Changed'.
In the event processing, cause an exception.

In the 'Debug/Continue' Dialog, press Debug.

I am now wedged----

Here's the code:

namespace TestExceptions
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private void OnDateChanged(object sender, EventArgs e)
{
string l_csNull = null;
string l_csBoom = l_csNull.Substring(0,1);
}
}
}
 
MP said:
Ok -- here's a concise example:

Create a new project (Windows Forms).
Drop a dateTimePicker on the form.
Add an event for the dateTimePicker 'Value Changed'.
In the event processing, cause an exception.

In the 'Debug/Continue' Dialog, press Debug.
Click to expand...

Your "example" is not complete, lacking some important details.
However, I was able to confirm the problem. It appears to be mainly not
a problem with VS, but a problem with the DateTimePicker control
specifically.

Note also that this isn't a "crash" as you report, but a hang (i.e. VS
becomes "unresponsive"). You can get VS to recover simply by
force-closing the process being debugged.

Doing a little research, I found an existing bug report from about six
months ago, describing this specific problem. I've added my own
comments to the report, which you can read here:
https://connect.microsoft.com/VisualStudio/feedback/details/490277/

In there, you'll note that I also found that if you explicitly set your
project to run as x86 (i.e. 32-bit), the problem does not occur. You
can also see from the original report that you don't need an exception;
simply setting a breakpoint in the event handler is sufficient. But you
_do_ need to interact with the DateTimePicker in a specific way;
changing the current value using just the arrow keys doesn't cause a
problem.

Probably the one thing that makes this bug so bad, in spite of the
relatively narrow repro case, is that it's still there in VS2010!

The bug is marked as "closed", which is of course completely bogus. My
understanding is that if there is activity on the bug report, someone
still has to review it, and presumably the bug will get reopened. At
the very least, you (and anyone else interested) should vote in favor of
fixing the bug, as well as confirming that you can reproduce the
problem. If you have additional comments to add to the report, you
should do that too.

Pete
 
I have similar issues with Vs2008 on Win 7 64 bit. It happens to me
while building a large solution. The frequency is low though. I maybe
see it once every week or two. I have tried lots of different options
but have found nothing that works. For now i just kill VS with task
manager and restart the build. Like you, I have absolutely no problems
at all on Vista or XP.
 
Peter Duniho said:
Your "example" is not complete, lacking some important details. However, I
was able to confirm the problem. It appears to be mainly not a problem
with VS, but a problem with the DateTimePicker control specifically.

Note also that this isn't a "crash" as you report, but a hang (i.e. VS
becomes "unresponsive"). You can get VS to recover simply by
force-closing the process being debugged.

Doing a little research, I found an existing bug report from about six
months ago, describing this specific problem. I've added my own comments
to the report, which you can read here:
https://connect.microsoft.com/VisualStudio/feedback/details/490277/

In there, you'll note that I also found that if you explicitly set your
project to run as x86 (i.e. 32-bit), the problem does not occur. You can
also see from the original report that you don't need an exception; simply
setting a breakpoint in the event handler is sufficient. But you _do_
need to interact with the DateTimePicker in a specific way; changing the
current value using just the arrow keys doesn't cause a problem.

Probably the one thing that makes this bug so bad, in spite of the
relatively narrow repro case, is that it's still there in VS2010!

The bug is marked as "closed", which is of course completely bogus. My
understanding is that if there is activity on the bug report, someone
still has to review it, and presumably the bug will get reopened. At the
very least, you (and anyone else interested) should vote in favor of
fixing the bug, as well as confirming that you can reproduce the problem.
If you have additional comments to add to the report, you should do that
too.

Pete
Click to expand...

I voted and commented - Thanks Pete-

Mike
 
Back
Top