Seeing some strange behavior in my IDE and thought I'd run it by ya. I'm running Visual Studio 2010. When an exception occurs in a function that is unhandled, the program simply exits the function and keeps running. I'm used to the debugger breaking, popping up the Exception Assistant, and identifying me of the problem.
I have Exception Assistant turned on in Debugger->Options and I have all "Unhandled Exceptions" checked in Debugger->Exceptions.
Suggestions? Thanks.
Check "Thrown" as well and it should stop on all exceptions, even those that are caught.
Related
I'm using VS 2019, I'm wondering if there is a way to break when an exception is thrown, even if it is caught.
I can't manage to find out where the exception is really thrown since there are many exception handlers and the exception pop-up comes up when the stack is no longer indicating anything.
Thanks
You have to go into the exception settings of Visual studio (you can easily find it with the search bar)
And then you check the exception category that is needed (CLR for example)
Uncheck it after when it is no more needed (or use the restore default button)
The program crashes after 30-45 minutes of operation with the following message:
Exception Thrown at 0xFCA6551 (mfc140d.dll) in WinPDM.exe: 0xC0000005: Access Violation reading location 0x00000008.
The exception occurs when running in both debug mode and from a release build in Visual Studio 2017. The program suddenly shows errors in rendering boxes and buttons, and if one then tries to press a button or select an item, the exception occurs.
The program was originally writtin in Visual C++ 6.0 and ported somewhat successfully to Visual Studio 2017. Many errors were found and removed after running the built-in intellisense analyzer in VS2017, but the exception still occurs. It also occurs in the older versions of the program built in Visual C++ 6.0.
I am looking for suggestions on how to pinpoint where this error is coming from and how to address it.
We have already tried to backtrace using the VS2017 debugger, and also attempted to step into the function call where the exception occurs:
size = m_ShiftList.GetDC()->GetTextExtent(str);
but the debugger refuses to step into the function at this point.
The program can pass through this point with no issues for the first 30-45 minutes of operation. Removing this code (since we can live without knowing the size of the text) moved the same exception to occur at a different point.
When I run a Windows Phone 10 project from Visual Studio 2015 then the following exception pops up after the second run:
Exception thrown at 0x61594533 (WindowsXamlDiagnosticsTap.dll) in remote.exe: 0xC0000005: Access violation reading location 0x00000000.
If there is a handler for this exception, the program may be safely continued.
The exception is raised in debug and release mode. Consecutive runs also fail with this exception. The only fix is to restart Visual Studio after each debug run.
Is there a way to disable this xaml debugging tap? Or what could be the reason for the exception?
Regards,
It might be this known issue: https://github.com/Microsoft/WindowsUIDevLabs/issues/75
Disable Live Visual Tree Debugging as a work around for now.
I'm using Visual Studio 2013 ultimate and I have some problems after reinstalling. Breakpoints don't work in any type of project, even console application. I just start debugging and have new tab "source code is unavailable" with title "code isn't executing" and text "in current thread any code isn't executed now, or call stack is unavailable".. Also this situation appears when any unhandled exception is thrown, I can't read exception message, just this tab
Delete .sou file from your solution directory. This method resolve my issue.
Hello I'm getting this exception thrown at me whenever I try to test a web application via visual studio, any ideas why? I'm building a project using MVC3 model and visual studio 2010
Exception: A first chance exception of type 'StructureMap.StructureMapException' occurred in StructureMap.DLL
First chance exceptions might occur while debugging. They might be handled properly by your code and never propagate when running the application normally but nevertheless Visual Studio shows them in Debug mode. If you don't want to be bothered you could disable them in Visual Studio and they will no longer appear.