I develop a server-side Blazor application in Visual Studio, my application uses Kestrel web server.
I can use a debugger, I TRY to use it at least.
When I set any breakpoint in any point of my code, the breakpoint is hit, Visual Studio debugger is shown, everything works like in any other NORMAL .NET application.
What I try to achieve is investigate / debug an exception that is thrown in my C# code in Blazor application. Exactly - it's a component code. I click a button in my app UI, an event handler is called, it starts executing code, I can insert a break point, so VS stops the program execution and shows me the line with the breakpoint, variable values and all. It's weird I'm even explaining it.
However, if an exception occurs in my program, Visual Studio debugger is NOT shown. The exception is intercepted in Blazor and show to the console instead. It makes debugging of the application super tedious and annoying chore. It also increases development time like 10x, to say at least.
I'm almost sure Blazor cannot be as stupidly designed and there must be an option allowing to debug it normally, using debugger that is already connected and working. Catching errors and logging them to the console or other log makes sense for deployed / released application. For development, especially in debug session in Visual Studio - the exceptions should be sent to the debugger. So there must be an option to enable such basic behavior, am I right?
I bet on appsettings.json file.
I spent several hours trying to find that information on Google and Microsoft Docs, but it seems either I'm the first person in the world asking that, or I just cannot figure out the right question or...
I'm really the first person in the world trying to use Visual Studio debugger to debug exceptions in my code. I mean in Blazor. Because I searched for "Debugging exceptions in Visual Studio" and it returns obvious (at least for me) results, like pictures of VS debugger showing exceptions. But if I only add "Blazor" to the question, the results are just crazy and totally unrelated.
Fun fact: when using NavigationManager.NavigateTo("/Identity/Account/Login") in my code, Visual Studio actually stops on exception, that is not really exception. I mean Blazor devs on GitHub say, the exception is a normal way how it operates. Feature not bug. So, when my application doing a normal, expected thing and works totally properly - Visual Studio debugger is suddenly shown and I see exception I don't care for. When my program performs invalid operation (a REAL exception occurs) - Visual Studio debugger does not show. The event is hidden and I either have to guess what has happened, or write some extra code to investigate. If that's not crazy I don't know what is.
BTW, I know there are workarounds for it. I'm not interested. I can use Debug.Print, I can insert a breakpoint and analyze the executed code step by step. I just want the debugger to be run as intended, automatically without hiding exceptions.
It works as designed :) . Blazor, or any other asp.net framework has try/catch block somewhere in request handling flow. It's just to not terminate whole application if any exception is thrown. So exception is catched and you are not informed by debugger.
You can configure debugger to break when any exception is thrown. Look in docs.
Related
I would like to learn and know, how can I examine my WPF application in Visual Studio 2019 in running / debugging mode.
Exactly what I expect: how can I trace my code what step is executed in background if the application running( communicate with port; modifies string and so on...).
I would like to see what happening if I click on the button and it calls methods and those again do something . Like visually trace the behind code.
I used the breakpoints but tell the truth it is not that I am looking for. I would like if the VS can indicate what line is executed e.g. if the textbox changed the code where continues and soo on. I think this way is existing. :)
The purpose of it to find a intermitted failure that I have made (maybe) even if it is not appears in every case and the VS not drop for it an exception. But the business requirement is not allowed that hidden failure/ unexpected slow processing, and I would like to find where it got stuck.
Someone can suggest what I have to use? In VS I also tried the in Debug menu-->Calls, Thread, Task window but these not give me that I want.
I'm probably missing something trivial here, but I can't seem to get Visual Studio to break on AssertionException's raised by Unity assertions.
I can break on other exceptions (invalid arguments etc.), so I know Visual Studio is set up correctly, and I can see the exception being raised in the log (so I know assertions are set up correctly), it's just not breaking in the debugger.
I tried adding custom exceptions to Visual Studio's Exceptions panel (e.g. UnityEngine.Assertions) but that didn't change anything.
I'm thinking that's the answer but I'm just not adding these custom exceptions in the right spot or with the right syntax?
Note: if I break on ALL exceptions that will probably work but I don't want to because that causes Visual Studio to break on a ton of otherwise-benign exceptions in third-party modules/libraries. I would like to know what is the unity assertion exception and catch that one.
OK so turns out I was right to expect this behavior to be possible! I am not sure if this should have been configured by Unity by default and my settings got corrupted somehow, but either way:
If you want Visual Studio to BREAK (through an exception) on a Unity assertion (e.g. Assert.Istrue(...)), you must add the following exception to your "Common Language Runtime Exceptions" setting (Debug-> Exception Settings):
UnityEngine.Assertions.AssertionException
since 2019.2 what you want should actually be the default behavior:
Assert throws exceptions by default whenever an assertion fails. You can however set Assertions.Assert._raiseExceptions to false and Unity then logs a message using LogType.Assert instead.
and that flag is actually going to be removed entirely.
In 2019.1 and before it was the other way round
A failure of an assertion method does not break the control flow of the execution. On a failure, an assertion message is logged (LogType.Assert) and the execution continues. If Assert.raiseExceptions is set to true, an AssertionException is thrown instead of logging a message.
and you need to actively set
Assert.raiseException = true;
I had similar issue before and it was related to whether process is running in 32 or 64 bits mode. I had to run it in 32 bits mode to make it break
I'm having a really strange problem that I just can't figure out. Things I compile in Visual Studio 2015 (C# projects in WinForms and WPF) will not launch outside of Visual Studio. This includes a project that is completely new and untouched. As in, create a new WPF Application, build in debug and release. Go to containing folders click on EXEs and...nothing.
When I run them I get 3 processes appearing in Task Manager (named the same as my application) than cannot be killed (through task manager or command prompt) and nothing else occurs. Nothing in event viewer that seems to correspond to the app. I've attached an instance of VS 2015 to the process and I get the following message: WpfApplication.exe has triggered a break point. Pressing Break takes me to a screen that tells me no debug information is available and pressing continue has no visible effects (I can occasionally see slight movement in the cpu % but not a lot else). Any attempt to stop debugging will cause visual studio to hang and when I end its process VS closes but its memory is not freed up according to Task Manager. All of these same things occur when building in VS2013 and attempting to run outside of VS. Everything runs just fine when run in debug mode inside Visual Studio but outside of it...not a chance.
I literally have no idea where to proceed from here. I can find no error messages or clues to point me in a direction to look. Is there something I'm missing/doing wrong? What steps can I take from here to find the source of the problem?
I've considered it may be something wrong with my computer but I want to explore the possibilities before I do something drastic like a clean install. If the prevailing opinion lies that way then I'll seek help elsewhere!
tl;dr: launching the exe of a compiled application results in no running application and no obvious error messages, how can I proceed from here?
I'm going to post an answer to this because I found out what was wrong but it probably isn't useful to have it hanging around so I'll just delete the question at some point soon.
The main lesson to remember is that the main purpose of anti virus software is to frustrate you as much as possible and if something weird is happening try turning it off briefly and see what happens. You'll probably find that things are now working correctly.
EDIT: I should restate this in a more serious fashion.
Anti virus can sometimes affect things in unexpected ways and turning it off temporarily can save you a lot of time. Keep it up to date too, mine was a version or so old and was not functioning correctly. I updated it and the deep scan now functions as expected rather than silently failing.
I have two solutions, one is my main app and the other is a plugin. I am editing the plugin for my app so I have added the plugins project to my apps solution and referenced it instead of the .dll
I am having problems with the breakpoints in the plugin. I have put some breakpoints where the plugin is waiting for a response. The plugin fires off an event once it has processed the data and my main app is subscribed to the event. The debugger always breaks on the event in the main app but in my plugin the debugger will only hit the breakpoints when I first start of the program. When the breakpoints aren't hit I look at the call stack and it shows me that it has gone past that piece of code with the breakpoint in.
I have no idea what is going on here and it has only just started happening. The last thing that I did was add a task into the plugin which would go off and process results when it has received the data.
Can anyone help me?
My code is running in debug
UPDATE
Basically my problem is I am getting data from a list of objects and am getting one, then processing it in my Task while I get another. This was working fine however when the issue with the break points started I noticed that the data that was being return was exactly the same all the time and is always the first element that I get.
I don't know whether that is of any use or not but it may be a caching problem that I can't identify.
You might be able to put a Debugger.Launch() statement in place of a breakpoint. I have had to use this many times when debugging applications that I don't control the application start and need more of a remote debugging scenario. The Debugger.Launch() will allow you to attach a new or existing VS instance to a running application.
By doing that in your scenario, you can start to inspect the threads (both in your current VS, and any new VS you attach with the Debugger.Launch() to ensure that they are both aware of the same threads. Your original VS may be losing access to the threads that your callback are on and thereby is unable to break.
https://msdn.microsoft.com/en-us/library/system.diagnostics.debugger.launch%28v=vs.110%29.aspx
Hi I have been working on a c# application which invokes a dll function. the dll is c code which actually initializes sockets to read/write/manipulate data. dll is compiled with debug info. The problem is under some conditions the c# application pops up a message a saying MemoryAccessViolation in the dll, but does not show any more information. i am basically a linux developer, so i want to know any mechanism to debug such an issues.
Within Visual Studio in the project properties, you can enable debugging of unmanaged code by clicking on the Debug tab and choose that option (Enable unmanaged code debugging). In addition, you can tell the debugger to stop when an exception occurs in you unmanaged code by pressing <ctrl><alt>e (or choosing that option under the Debug menu) to bring up the exceptions dialog.
In the Debug tab, set up unmanaged debugging.
If that doesn't help, it's probably quickest to debug it with WinDbg which should halt execution right on the memory access violation.
Problem is that the violation might be the result of an action that happened far earlier.
There might be better answers but the general route I'd take would be to:
Try and get it to cause the exception on demand. In other words determine what exact conditions cause the error. This might take some time.
Try and capture the exception at the point it happens in the C# code. If your lucky then this may at least lead you to the steps needed for repeating the problem in #1.
If I have access to change the dll written in c; add lots of logging. Hopefully you at least have an idea of where this is coming from.
Here is a forum post with some tips:
http://social.msdn.microsoft.com/Forums/en/netfxcompact/thread/69e84750-6636-4656-bbd4-8d3586290af3
Launch your managed code as usual using VS debugger. Now you would need to launch second copy of VS and attach it to the process you're debugging. Select native code for this second debugger instance. Now assuming DLL is already loaded (anything from that DLL already executed) you should be able to set a break point.
Sometimes it helps to show message box in the native DLL so execution would stop at the point you're interested in and you can attach native debugger and continue.