From: MP on

"Peter Duniho" <no.peted.spam(a)> wrote in message
> MP wrote:
>> 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.
> 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:
> 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 voted and commented - Thanks Pete-