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
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 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.
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 am trying to debug a windows form application which has a large number of events: button presses, timers, etc..
Is there a way to catch every line of code being executed by the application without setting a break point?
edit:
The program was not written by me, so I am unfamiliar with the code. I wish to step through the entire program, catching every line of code being executed. Setting break points in every event is impractical as various controls are created dynamically.
For debugging a button click without setting breakpoints:
Start the app with the debugger.
Get to the state immediately before the intended click.
Go back to the debugger and press Pause then F11 (Step Into) -- nothing will happen.
Go to the app and press the button -- the debugger should take over and drop you into the event handler.
Note: This will not work if Paint, any Mouse event, or probably some other events are handled. The debugger will drop you into those handlers any time you attempt the steps above.
If you're using the Ultimate edition of your Visual Studio 2010 you can use its new feature called IntelliTrace (previously Historical Debugger). This will allow you to do exactly what you want - be able to see all method calls and events that happened during execution of your program, and you'll be able to jump back to the event which you need.
To enable IntelliTrace, go to Tools → Options → IntelliTrace, and check the "Enable IntelliTrace" checkbox, and select one of two modes: "events only" or "events and call information", then run your application with a debugger (F5).
The difference between the two modes is that the latter uses the profiler to collect all runtime information, so you get a complete call stack, however you won't be able to use edit-and-continue features of the debugger.
You can find more in this series of articles, and of course, on MSDN.
You could also try a code coverage tool.
For example, if you have Resharper and dotCover, you can run your application (via the dotCover->Cover Application... menu item) and when the application finishes, dotCover will show you which lines of code were run in the VS IDE by highlighting them in green. Lines of code which where not run are coloured in red.
I don't know if there are other tools which do this, but it's an option.
I developed the Runtime Flow tool to solve exactly this problem - to understand a large unfamiliar .NET codebase via realtime function calls monitoring. It's similar to IntelliTrace, but places more emphasis on control flow than on debugging.
Why would you want to break on every line? This would be very onerous and time consuming. If you want to see the activity of your program as it executes, use a logging mechanism or Debug.Writeline to output information to the Immediate window.
You cannot trace lines of code, but you can use Trace.TraceInformation calls where you want to have an idea of what's executed. There's also Debug.Write. Both output will write in the output window of Visual Studio.
Another solution would be to add logging to your application, for example with log4net, but that may be overkill for your needs.
This isn't exactly what you're asking for, but in case you didn't know you can toggle an existing breakpoint on or off. In your case, you could add break points at key places throughout your code and just disable them when you don't want to debug them. That way, you'll be able to re-enable them later when you want to use them again.
Enabling/disabling is available through the Breakpoints window found under the Debug > Windows > Breakpoints menu (CTRL+D, B). You can also include "Function" and "File" columns in the window, which might help you identify which breakpoints are in the event handlers that you care about
Not really, but you can set one breakpoint and single-step (F10/F11) through the rest of the code.
Nope 'fraid not - you need to set each breakpoint yourself.
If it helps F9 is the shortcut key for assigning a breakpoint - just set a breakpoint on the start of each method and use step through (F10) / step into (F11) from there.
There is a program where I work that works fine when running the .exe file but works differently from expected when opened in VS2005 and played from there. I am therefore asking on here if anyone knows of anything that would work in the .exe file but not the debug from VS? I am not able to post the code for the buttons I'm talking about but I'll try to explain the best I can.
There is a receiver hooked up to the computer. When the button is pressed on the program, it shows a message and waits for a signal to be received. After the signal is heard the first message box is supposed to close and another is supposed to open. When using the .exe file this happens just fine. However when playing from the program from VS2005 (the same one from which the .exe was made) the second message doesn't come up when it is supposed to and when I can make it come up, the first box doesn't close. There is also a timer involved if that helps.
Also, is there a fundamental difference between how the two operate when executing the program?
If I need to make anything more clear or give more details please let me know.
Running a program under the supervision of a debugger can change the timing of events compared to running the program standalone. The debugger slows things down. Normally, this doesn't make any difference to the operation of the program, but if you have code that is dependent on the "coincidental" rapid timing of some activity, that happy coincidence may be broken when things slow down under debugger control.
The debugger can also cause changes in focus and activation depending on where you set your breakpoints - generally not a good idea to set a breakpoint in focus change or activation events because stopping at the breakpoint will change focus to the debugger, away from your app. But these are interaction issues. Just running your program under the debugger with no breakpoints shouldn't affect focus or activation in your app.
Review your code carefully. Consider what could happen to your program flow if you inserted delays between every source code statement. If that could lead to problems, you have a design bug that needs to be fixed. Reliance on coincidental timings will lead to bug reports and support calls, particularly if your customers have slower hardware than your development machine.
When you run under the debugger, or even in the VS testing host, there are some subtle differences. This shouldn't effect your program under normal circumstances, however, since most of the differences are similar to running (the debug version) of your application on a slower system.
Given your descriptions, I suspect that your problem is actually due to calling to the UI from a different thread than the control was constructed with. Make sure to always marshal any calls to the UI using Control.Invoke or Control.BeginInvoke.
It may be an issue with the Host Process, disabling it is a painless click and just as easy to re-enable. It may be worth giving a try.
Disable Host Process
I know this can effect Direct X and other API but I've never had exactly the situation you are in so I make no promise.