1

I want the debugger to stop when:

  • A handled or unhandled exception occurs.
  • An unhandled exception occur in a function that has a DebuggerStepThrough or DebuggerHidden attibute. Debugger should stop where this function is being called.

There is no problem so far, I could able to make Visual Studio 2015 work like that. However when an handled exception occurs inside a function that has a DebuggerStepThrough or DebuggerHidden attibute, the debugger stops where this function is being called.

I couldn't find a way to fix this. I don't remember this behavior on Visual Studio 2010 or 2013. I've searched about it, and did not find anybody asking about the same issue.

Edit: I have tried DebuggerNonUserCode, result is the same. It says "Exception thrown". No it does not! enter image description here

My settings: enter image description here

Koray
  • 1,768
  • 1
  • 27
  • 37
  • You asked the debugger to stop on the "first-chance" exception. Nice feature, pretty important to debug code that swallows exceptions when it shouldn't. You could simply uncheck the "Break when this exception type is thrown" checkbox in the dialog. But more likely you want to reset Debug > Windows > Exception Settings. If you want to leverage the attribute then turn Tools > Options > Debugging > General > Enable Just My Code" back on. – Hans Passant Feb 01 '17 at 07:36
  • I think you got me wrong. I have tried those and couldn't solve my problem. I **do want the debugger to break** for an exception. But don't want it to break for an exception that is **handled** in an **DebuggerHidden** function. – Koray Feb 01 '17 at 07:57
  • 1
    Hmm, no, pretty sure I know exactly what you mean. Why you don't want to restore the settings I described is very hard to guess. As-is, it looks like you don't yet realize that you accidentally changed them. If you *intentionally* changed them then it is important that you explain why you did that. – Hans Passant Feb 01 '17 at 08:02
  • Ok, I may not understood you. I will try again, with the things that you have write. – Koray Feb 01 '17 at 08:12
  • I have tried check-uncheck Enable Just my code, and "Warn if no user code..." properties. Nothing changes. In the Exception Settings Window exceptions are selected, becouse I want them all to stop the debugger. Restoing to defults also does not change anything. I hope I have understood you. – Koray Feb 01 '17 at 08:26
  • @Hans why do you try to offend me? Yes I have learned if form Jack's answer so what? In my first respose to you may see "I have tried those." – Koray Feb 01 '17 at 08:35
  • 2
    @Koray the MSDN article actually proves you aren't imagining things, and it's not a bug either. The explanation and workaround though is the very last paragraph. It's caused by a debugging performance feature. Perhaps you should look for ways to *minimize* exceptions instead of ignoring them? If they are so frequent that breaking hurts you, it also hurts runtime performance – Panagiotis Kanavos Feb 01 '17 at 08:40
  • @Panagiotis Kanavos minimize exceptions is always one of my main concern actually. However having handled exceptions is sometimes inevitable, especially when the control of the entire code is not in your hands. – Koray Feb 01 '17 at 08:51
  • @Panagiotis Kanavos I use Visual Studio 2015 Update3 and this article did not solve my problem. I still think that its a bug. It says "Exception thrown" for an handled exception that is not thrown. – Koray Feb 01 '17 at 09:24
  • 1
    Duplicate of: http://stackoverflow.com/questions/39382551 – crokusek Mar 08 '17 at 22:29
  • @crokusek thanks, I didn't see that question. I am still searching a workaround for this issue that will work with edit and continue. – Koray Mar 09 '17 at 05:11

2 Answers2

1

You could use the DebuggerNonUserCode Attribute instead of the DebuggerStepThrough or DebuggerHidden attribute in VS2015 since there are a few small differences between them:

https://blogs.msdn.microsoft.com/visualstudioalm/2016/02/12/using-the-debuggernonusercode-attribute-in-visual-studio-2015/

Update:

I get the same issue as yours using the VS2015. I found that it would be related to on debugging option, please enable the option "Use Managed Compatibility Mode" under TOOLS->Options->Debugging. Debug it again.

enter image description here

Jack Zhai
  • 6,230
  • 1
  • 12
  • 20
  • Whilst this may theoretically answer the question, [it would be preferable](http://meta.stackoverflow.com/q/8259) to include the essential parts of the answer here, and provide the link for reference. As it is, the article contains an important warning that is *NOT* described in this answer – Panagiotis Kanavos Feb 01 '17 at 08:31
  • In VS2013 DebuggerStepThough attribute used to do the thing I want. If I'm not remebering it wrong. – Koray Feb 01 '17 at 08:31
  • 1
    @Koray, please enable the option "Use Managed Compatibility Mode", debug it again:) – Jack Zhai Feb 02 '17 at 08:39
  • 1
    Managed compability mode has a drawback: cannot edit and continue while debugging :( – Koray Feb 02 '17 at 13:29
1

The MSDN article Using the DebuggerNonUserCode Attribute in Visual Studio 2015 explains what the DebuggerNonUserCode does and why it doesn't ignore exceptions.

This is caused by a performance improvement in VS 2015

when Just My Code is enabled, the debugger no longer gets notified of exceptions that are thrown and handled outside of “your code”.

This leads to a big performance improvement because:

The debugging performance improved because when Just My Code is enabled, the debugger no longer gets notified of exceptions that are thrown and handled outside of “your code”.

This behaviour can be switched off through a registry key introduced with Update 2:

To enable this, run the following command from your command line that will tweak the registry for you:

reg add HKCU\Software\Microsoft\VisualStudio\14.0_Config\Debugger\Engine /v AlwaysEnableExceptionCallbacksOutsideMyCode /t REG_DWORD /d 1

You'll have to experiment and see what is more important, ignoring exceptions or better debugger performance.

Panagiotis Kanavos
  • 120,703
  • 13
  • 188
  • 236
  • @Koray consider *not* throwing too. If the exceptions are so frequent that they hurt you, they also hurt runtime performance. Returning a result object (which forces the caller to check for success) is one solution used in functional languages. That's how HttpClient works for example – Panagiotis Kanavos Feb 01 '17 at 08:42
  • @Panagiotis Kanavos, thanks for your assistance, it provided more detailed and useful information:) – Jack Zhai Feb 01 '17 at 08:43
  • Actually I don't write codes that depends on throwing exceptions. Thanks for your great answer and your comment. – Koray Feb 01 '17 at 08:45
  • I am sorry but this didn't solve the problem. I thought it was the solution. I forgot to check the exception settings before trying, and thought that this was working. Very sorry for that. – Koray Feb 01 '17 at 09:18