since I am using vs 2017 I am missing one of my most used features I was using in vs 2008 and 2010.
In previous Visual Studio versions you were able to setup exception handling.
VS2010 for expamle:
Debug=>Exceptions=> CLR Exceptions => Thrown checkbox
When I checked this checkbox he would break on every exception which was thrown (did not matter if handled or unhandled). This was a huge bonus because in bad code were logging was very bad you allways found the issue pretty fast.
Now I am working on a project with pretty bad logging and I am getting a lot of exceptions in the output window but not in the log. But I simply can't find the damn code line and the studio debugger is not breaking at the exception.
I found this this and checked "all exceptions in this list". But it did nothing and the studio just ignored it. I am desperately looking for that good old "thrown" features from 2010. It obviously has to be a handled exception.
Anyone knows where I find that must have feature in this new fancy studio?
Best regards
The provided solution here does work. I did not work in my case because he had and still has issues loading the debug informations of other libraries. If you have similar issues, make sure that he has loaded the necessary debug informations. I am not working with project references because of the project size. We are working with post build events which do copy the output libraries to a common directory which we are refering to as reference path. In my case deleting the libs there and rebuilding them did the job. He loaded the debug informations correct and was able to break even at handled exceptions.
Best regards
Related
I wanted to be able to step through/debug the source code of the .Net Core framework, since it is open source now and everything.
So I followed some answer on here, or something, but I've forgotten exactly what I did.
The problem is that the loading of the symbols took forever each time I started debugging and, worse, Visual Studio would no longer break on most exceptions and whenever there was some issue it would break but show me the exception in some esoteric class or file that I, presume, is part of .Net Core even though I know the actual exception is being thrown in my own code.
So, now I want to fix that and have the symbols loaded once and then used from the cache and VS breaking on exceptions like it should normally.
Failing that I'd like to undo whatever I did but, like I said, don't remember exactly what I did. Here's what I think I did:
Go to Tools -> Options -> Debugging -> General and check the following options:
Enable .Net Framework source stepping
Enable source server support
and unchecked:
Require source files to exactly match the original version.
I also have both "Microsoft Symbol Servers" and "Nuget.org Symbol Servers" in my "Symbols" section and the option "Load all modules, unless excluded" selected.
So, how can I still step through .Net Core source and have VS behave like normal with exceptions and not load symbols for 5 minutes every time I start debugging
-OR-
How do I undo any options to have everything like before?
I have a frequent work scenario where I run my app in the debugger, with "break on exceptions" turned on, but run into a series of "garbage exceptions" that are thrown in framework code and caught/handled just fine within the framework. These exceptions have nothing to do with the code I'm debugging.
Visual Studio allows me to ignore exceptions by type, but I have to do that one by one, by unchecking a box when they cause the debugger to break. Once I have done that once for every exception type, I'm fine for a while, but I notice that whenever I do a git clean -fdx, Visual Studio forgets the list of exception types I want to ignore.
Is there a way to maintain a list of exceptions types to ignore in the debugger that I can check into git?
[I like doing a git clean every once in a while to start with a clean slate (and it also is sometimes the only way to get Visual Studio out of its confusion) and don't want to forego that practice.]
My .NET application can load multiple versions of the same assembly into memory. Assemblies are not signed but every time new copy of assembly is complied and loaded it automatically gets a new assembly version (in minor part). I do not have any issues with types since instantiation ob objects is under by control, so I know from which assembly the object is created.
This was working ever since VS 2003, but with the latest VS 2015 the debugging of this scenario is broken. All works fine while only single version of assembly is loaded into memory but whenever second version is being loaded all Locals/Watch windows become empty. And trying to evaluate any expression in QuickWatch gives a compiler exception "error CS1704: An assembly with the same simple name 'MyAssembly' has already been imported. Try removing one of the references (e.g. 'MyAssembly.dll') or sign them to enable side-by-side."
Here are screenshots of the same application with attached debuggers from VS2013 and VS2015 (when two assemblies are loaded):
VS2013 Debugger:
VS2015 Debugger:
And the selected parts from loaded assemblies list:
So this makes debugging with VS 2015 almost impossible.
Since originally this is a compliler error (which to my belief is used under the cover of VS 2015 debugger) internet search is not very useful. Here is the only link related to Debugger problem that I was able to find:
Visual Studio Debugger Failing to inspect variables. The difference to my case is that there having two assemblies in memory was a mistake while in my case this is an intent.
So now I am thinking on my options.
Of course, ideally I would like to have some patch to VS 2015 that will fix the issue. But being realistic I am not sure this will happen.
Signing assemblies (as compiler suggests) is not an option since assemblies are generated on clients' machines and it is not possible to provide them with a key for signing.
I could try to play with AppDomains to see if debugger could handle the case when assemblies are loaded to different domains. But even if it could, this would be quite a huge (and unplanned) change to my appliction.
So may be anyone could suggest some more ideas? Thnaks.
I've found a workaround for this problem. There is an option in Visual Studio "Debug - Options - General - Use the legacy C# and VB expression evaluator", enabling it restores previous debugger behaviour.
This option is described in VS 2015 Known Issues for different debugger issue but also works for described case.
I also filed a bug to Microsoft. I do not believe they will do anything about it, but here is the link just in case.
Assuming this is an option in your situation, you could try to rename the class or namespace before loading the assembly.
There are libraries that can modify assembly files: http://www.codeproject.com/Articles/20565/Assembly-Manipulation-and-C-VB-NET-Code-Injection
This of course assumes that you are loading the assembly and types at runtime.
I am having a nuisance problem with a C# app. To simplify the scenario, I have a main .exe project which references another C# library as a direct DLL dependency. This DLL throws exceptions in a particular place, and the debugger is breaking on those. However, the exception is handled and not re-thrown. My exceptions dialog in VS is checked to only have the debugger break on User-Unhandled exceptions of this type (InvalidOperationException), yet it is still breaking.
However if I link the same library as a project reference (rather than to the compiled DLL) the debugger no longer breaks on this exception.
As well, if I run the .exe program directly (outside the debugger) I see no evidence that this exception is not being handled as I expect. No errors, and my logging indicates the expected control flow.
The related code has been mostly unchanged for some time, but I have refactored my solutions and projects; I was previously using only project references, so perhaps never spotted this issue until I went to DLL references.
Can anyone suggest anything else I might look at as to why the debugger is breaking on this handled exception?
I did some more googling and fiddling, and I have settled on the idea that it seems the 'Enable Just My Code' is what is causing the debugger to break
This link gave me some clear insights into how this option affects the Debugger: http://www.jaylee.org/post/2010/07/05/VS2010-On-the-Impacts-of-Debugging-with-Just-My-Code.aspx
I am using a third-party DLL. For some particular cases, a function in the DLL is throwing an exception. Is it possible to debug the DLL in the Visual Studio?
After the answer from Andrew Rollings, I am able to view the code, but is there any easy way to debug through the code in Visual Studio?
If the DLL is in a .NET language, you can decompile it using a tool like .NET Reflector and then debug against the source code.
Or you could ask the vendor if source code is available. That's probably the easiest way.
Building on Andrew's answer, you just treat the decompiled source code as a new library within your project and set breakpoints in the source. Remove all references to the 3rd party DLL so that it is the decompiled code that is executing.
Other things:
You may be breaking the law by decompiling the code, or breaching a licensing agreement with the 3rd party vendor. Make sure to review this with someone.
You will want to make sure that you remove references to your decompiled version if you are shipping to other developers, or checking into a larger source tree. Easy to forget this!
There are two methods I've come across:
1) Accessing the DLL project from the using project.
This involves building the DLL in a separate instance of Visual Studio and then accessing the DLL through a different project in Visual Studio (this assumes you have the source code).
There a number of ways to accomplish this:
You can add Trace.WriteLine
statements in the DLL that will show
up in the 'Output' window in Visual Studio.
You can add System.Diagnostics.Debugger.Break() statements to the DLL code. When
running the calling project in Visual Studio,
program execution will stop there.
From here you can add access the
call stack (including all function
calls in DLL itself) and set break
points (although the icon for
the breakpoint will appear disabled
and the hover text for the break
point will read "The breakpoint will
not currently be hit. No symbols
have been loaded for this document").
If the DLL is throwing an exception (which you can see from
the 'Output' window if the exception
is caught and handled by the DLL)
you can tell Visual Studio to always break when
that type of exception is thrown.
Hit Ctrl + Alt + E, find the type of
exception being thrown, and click
the 'Throw' column for that
exception. From here it is exactly
as if you had used
System.Diagnostics.Debugger.Break()
(see above).
2) Attaching a using process to the DLL project.
This involved hooking the Visual Studio debugger into a running process.
Open the DLL project in Visual Studio.
Run an application that uses the DLL (this
application can't be run from
another instance of Visual Studio since the
process will already have a debugger
attached to it).
From here you can add break points and step through
the DLL code loaded in Visual Studio (although
the break point will appear disabled
the same as in method 1).
Something that has worked for me with debugging a couple of third-party libraries as well as .NET itself is WinDbg. It is an awesome debugger from Microsoft that I have used to troubleshoot some sticky problems that were occuring deep inside the framework.
You need to use the Son of Strike (SOS) extensions if it is a managed DLL. It can debug native also. You will need to know a bit about callstacks and assembly/CIL instructions to be good at using it. You should be able to determine the exception and what is causing it. We have used WinDbg/SOS to find for instance that in HttpWebResponse, if you are using Gzip compression to download a page and the server returns a bad Gzip header, .NET runs the decompression in the threadpool and a crash will take out your process. Happy debugging.
One more option we should mention here is dotPeek 1.2 (a free decompiler from creators of ReSharper). Here is a nice post describing how to configure VS symbol server and dotPeek 1.2 to debug decompiled code from VisualStudio: http://blog.jetbrains.com/dotnet/2014/04/09/introducing-dotpeek-1-2-early-access-program
As Cesar Reyes mentioned in Stack Overflow question Visual Studio - Attach source code to reference, ReSharper 5 (and later) has this capability.
.NET Reflector 6 comes with a Visual Studio Addin that lets you use Visual Studio's step-through-debugging on assemblies that you don't have the source code for.
Have a look at this blog post:
http://www.simple-talk.com/community/blogs/alex/archive/2009/09/22/74919.aspx for more details.
This is still a very early build. So no guarantee that it'll work, and it might break your visual studio configuration or project configuration. Make sure you have backups (or source control) for any projects you use this on.
Download here:
http://www.red-gate.com/MessageBoard/viewforum.php?f=109
I thought .NET Reflector got some debugging plugins. That'd be a so much better idea because decompiling and recompiling code generally fails, and you need to do so many changes in the code to fix it.
Give .NET Reflector debugger a try. It might help you a lot.