You should follow the workaround as outlined in the connect bug:

Hi,

This is a known bug with x64 versions of Windows and the way exceptions are handled. One way to work around this issue while debugging is to go to the Debug -> Exceptions and select 'Thrown' for for the exception types you are interested in. This will stop the debugger when the exception is first hit (and before Windows eats it up).

Thanks,
Visual Studio Debugger Team

Thanks for your answer which is highly appreciated.

The workaround you mention is not too helpful as most of the time it is unknown which sort of exception is being thrown thus you must setup the VS to break on all clr exceptions causing the debuging session to break very often on handled and unrelated exceptions.

I am aware of the other workaround (Start without debugging -> System.Diagnostics.Debugger.Break() -> Attach process to debugger) and am using it where possible, however the workaround causes the runtime to stall when debuging a project where many assemblies are involved (prism - wpf ui). Not too mention that the workaround does not help on productivity having to attach to the debugger process whenever wanting to run my project.

Please forgive that I have allowed myself to unmark your reply as an answer as it does not answer my question, which was when a fix will be available? (if at all?) and if this bug is fixed in VS2010? We are unfortunately seriously considering going back to windows x86 because of this problem as it impacts our productivity.

Hello,

I am sorry that the bug has not been fixed yet. I have tested it in both Vista x64 and Windows 7 x64 with VS 2008 and VS 2010.

This bug is not as easy to fix as it looks like. It requires changes in both OS and CLR. Product group will balance resources and user impaction before they fix a bug. I think that's why the bug fix is posponed.

The best channel for users to tell product group how important of a bug is to vote at the connect site. The vote data will be one important factor for PG to make a decision to fix a bug.

I still can't answer when the issue will be fixed right now. I will appreciate if you can understand that we are trying to fix most important bugs and your vote will help us to make the decision. Thanks.

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

You can also open a new connect bug. That will give you direct feedback on whether or not they will be fixing this issue.

Thank you for your replies. Although this doesn't fix the bug (which looks like a nasty one), it puts me at ease to understand the process and know that it has been flagged. I have cast my vote on the connect link you provided. Many thanks again for the responses and look forward to the fix.

Ok, thanks for your responses, I have also voted on the connect site. I suppose we will be transitioning back to 32-bit windows as this bug is affecting our productivity too much.

Your best bet is to vote for the connect bug.

Would that help? I see the status of the bug on connect is "Closed", I would assume that means nobody on the visual studio debugger team is monitoring this.