I was wondering how can I get an exception details encountered by VS 2012 debugger? The exception details will be used by a plugin installed within the IDE.
DebuggerEvents.OnExceptionThrown from dte.Events.DebuggerEvents provides ExceptionType, Name, Code, Description for an exception thrown.
Related
Using keyhelp.ocx to display popup HtmlHelp in a modern Visual Studio C++ application fails.
I get a COM exception with no sensible error code. Looking at the debug output, there seems to be an Access Violation behind the scenes.
Your executable is build with Data Execution Prevention enabled, via /NXCOMPAT. That's the default in Visual Studio.
keyhelp.ocx is built using ATL7, which is incompatible with DEP - see http://support.microsoft.com/kb/948468
You need to disable DEP (/NXCOMPAT:NO) for your executable or find an alternative to keyhelp.ocx (I don't know of one).
(Note that's it's possible to enforce DEP system-wide - your code will still fail on such machines.)
I added a new console application project to my VS2012 solution.
When it encounters an exception, I get an error dialog, and VS2012 does not break and go to the source line that threw the exception.
The original project that was created together with the Solution does break on exceptions properly, so I think the issue is that the newly created executable is not marked as relevant for breaking on exceptions. (The debugger is "not attached"? I'm not sure if this is the right term)
How can I make VS2012 start breaking on exception in a project?
I am using the Debug configuration, the pdb is being generated.
There is an issue with recent x64 Windows systems when they do not propagate exception properly back to the x64 application when function calls cross kernel boundaries.
There are plenty of posts here on SO and all over the internet about it, for example the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64
You can fight it to some extent by going to Debug->Exceptions and flagging CLR exceptions Thrown column. But note that then VS would break even on the exceptions handled by you.
Problem description:
Whenever an exception is thrown and not catched a dialog pops up. I want Visual Studio Express 2012 just to break and stop grabbing all my input with this modal dialog window. Example of the dialog:
Wanted solution:
VS 2010 does not show this annoying pop-up window but something called exception assistant. How an I can get the same type of break on exceptions in 2012 as in 2010? Even if that's not possible I really want the pop-up to be gone while keeping the break.
Things I've tried to solve this problem:
Search for a solution on both Google and here on StackOverflow (some of the keywords I used: visual studio 2012, pop-up, window, dialog, exception assistant, exception, break)
Run repair on VS 2012
Uninstall and delete settings (folder: C:\Users\<username>\Documents\Visual Studio 2012) followed by an install
Tools -> Import and Export Settings -> "Reset all settings"
Enable the "Break when exception type is thrown"
Change settings in the: "Tools -> Options -> Debugging -> General"
Edit:
I'm using the Express edition, no exception assistant anymore! :(
Edit2:
Found a (very ugly) workaround using AutoHotkey:
#SingleInstance force
#Persistent
loop
{
WinWaitActive, Microsoft Visual Studio Express 2012 for Windows Desktop
WinClose, Microsoft Visual Studio Express 2012 for Windows Desktop
}
return
Based off of answers on the following forum, VS 2012 Express no longer has the exception assistant option:
http://connect.microsoft.com/VisualStudio/feedback/details/762652/enable-exception-assistant-option-missing-from-vs2012-express-for-desktop
Hopefully we'll see it back in future versions of VS Express. VS 2010 Express is still available to my knowledge, and 2012 can read 2010 projects without destroying compatibility. So if it's a big deal to you, you can go back to 2010 to trace the bugs. Not a particularly exciting solution, but I'm still impressed that Microsoft has given out as many features as they have in the Express editions.
In VS2012, when I unchecked Tools -> Options ->Debugging -> General -> "Enable Exception Assistant" I get the annoying dialog box.
I get the following exception: 'Cannot find the method on the object instance' when I hover over a property of one of my classes in Visual Studio 2010.
Any ideas?
I changed the target platform for the project from x86 to AnyCPU and rebuilt. Some of the projects in the solution were set to target AnyCPU and some x86, initially. Hope this helps someone ...
I am using Visual Studio 2008 Express and am writing unit tests where there are many expected unhandled exceptions. This cause numerous exception assistant popups to display when running these tests in the debugger.
I have disabled the exception assistant in the VS options, but a different unhandled exception dialog pops up instead. I know it is possible to get rid of these with Visual Studio Professional, but how do you do this with the express edition?
By the way, I am using Assert.Throws instead of the ExpectedException attribute (NUnit), which causes this, but I want to use the Assert.Throws instead. Thanks!
In the Debug menu, go to Exceptions (Ctrl+Alt+E). From here you can tell the debugger not to break when an exception is thrown. Just uncheck all the boxes for the lazy option, or go digging for the specific exceptions you don't want it to break on.
Note however, that this may not be what you want to happen under normal debugging situations, so don't forget to turn it back on later if you're trying to debug something & want to find the exception.
Edit: My apologies, even though it's written several times in the question (including the title), I failed to notice you were talking about the express edition... teach me for skim reading the question. Not sure if the above works or not in express edition, so it might still be worth a try.
Edit 2: Ok, looks like the Exceptions dialog is still available in express edition.
I'll take a guess that you're encountering one of the following:
You're throwing a "special" exception like StackOverflowException that the runtime handles differently from other exceptions.
Your test code creates a new thread, and on that thread an exception is thrown.