I'm having a strange issue on a program that I'm writing.
The language is C#, I'm using Win 10 x64, Visual Studio Community 2019, and the software is client/server (Sql Server Express, installed on the same machine), single thread.
The problem happens in a windows form, when selecting an icon to be displayed.
If I place a breakpoint at the start of the subroutine which manages the icon everything works fine, but when I try to remove it (the breakpoint) the entire form freezes and I can't click anywhere, moreover pushing F5 doesn't change anything and I have to stop the execution to get back to my code.
Even If I pause the execution the call stack results empty.
What do you think can cause such a behaviour?
First of all thank you very much.
I felt the need to answer because trying to show the cpu usage resulted in a change.
The Cpu usage is always very low (less than 10% at worst), but following the instructions on Microsoft Docs I put the execution (while in Cpu usage testing) in Release, as opposed to before when removing the breakpoint I left the execution in Debug, and everything runs fine.
So now the question changes:
why do it's alright in Release mode and freeze when in Debug mode but without the breakpoint?
They are the same, aren't they?
Thank you very much again.
Related
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'm now working on some pretty big application with really nasty code. The problem is that from time to time the whole GUI of the app is freezing and stops responding (and after some time Windows wants to take the app down). I have a really big problem to even look where to debug the app, mostly because when this thing happens and I pause it in the VS debugger, it highlight the line:
CardWindow.ShowDialog();
It's not helpfull at all. Also when this thing happens it tends to grow the app size in the memory, ocasionally throwing OutOfMemoryException.
I also checked whether it might be some kind of an infinite loop in one of created threads, but VS shows me that only the main thread is active, and the rest are either ended or not running at all (the thread implememtation is also really poorly written).
The application uses remote objects within local networks, and some threads are used to transfer photos and other data from clients to server, but I don't know how to check if this is what it's causing it. But when the server app hangs, the clients are still fully capable to connect with it.
Short info of how it's made: the app uses Firebird engine to store its data. The DB is on the server machine, and the clients are connected via local LAN to it using standard Firebird C# library, and the app instances communicates with each other using remote object (the server is also a client).
It's the second week of debugging and I'm getting pretty desperate as I'm getting out of ideas of even how to check what's wrong. The fact that the bug appears randomly also doesn't help.
Can anyone give me some ideas of how to find a trace of this bug?
Using C# .NET 4.5 and WPF with Visual Studio Ultimate 2013 and Firebird 2.5
I'd suggest using a profiling tool to assist in finding the problem
What Are Some Good .NET Profilers?
In addition to #DerekTomes. The System.Windows.ShowDialog method, Described in: Window.ShowDialog Method, all other windows are disabled and return only when the window is closed. Check to make sure the window is eventually closed(this.Close() in the CardWindow.xaml.cs or whatever .cs file) or use CardWindow.Show() instead of CardWindow.ShowDialog() so other windows remain running while the CardWindow is running.
I finally figured it out.
When the function that usually hanged the app after 30th run launched, I could see that some of it ran (the window's title changed as it was supposed to). I've found this function and after every single line put:
this.Title = "1";
SomeFunction();
this.Title = "2";
AnotherFunction();
this.Title = "3";
// and so on
I localized what was causing the problem; there was a function that changed the GUI significantly (lots of foo.Visibility and foo.Opacity) and ran in some weird loop. It was fine for the first 20 times to run it, but after 30th it slowed down the app, and after 40th - caused crash.
It now runs only once when it needs to and the problem does not appear. I suppose it caused GUI memory overflow of some kind.
Anyway, thank you for your answers - I ran memory profiling, but it slowed my app down to that point it was impossible to use it.
I have a c# winform application, when I run it from Code, from Visula studio, It works well. But when I built exe for the same and running the same Hangs after working well for some time even it shows 0% CPU utilization in Hang state.
Hoping for a little help for solving the same problem would be very much useful from PRO people here.
Even a pro would have a pretty hard time diagnosing the problem without even a single line of code posted.
But that's okay: we can help you help yourself. :)
Run the program without Visual Studio, wait for it to hang. Then start up Visual Studio and use the "Debug/Attach to process..." command to attach the debugger to the hung process, pause execution, and take a look at what it's doing (or not doing).
I am experiencing freeze issues with Visual Studio if I leave the debugger at a breakpoint overnight and then return the next day to continue (i.e. F10).
What happens is that not only Visual Studio freezes but the entire computer hangs as well forcing me to restart. This occurs on a quad core computer which means VS is basically occupying the CPU for all cores.
Is there something I can do with stupid bugs like this or do I really have to avoid leaving a debugging process stop at a breakpoint for an extended period of time? I actually do need to do something like this because there are times it'd take hours for a certain break point to hit.
Thanks.
Edit: I am debugging a local project that connects to a remote SQL server. I never have problem with it if I leave the breakpoint for an hour or so. The freeze only occurs when I leave it overnight.
Edit2: Problem also occurs if I kill the debugger instead of continuing with it after an overnight breakpoint.
Create a Test Project that is very simple that connect to a remote sql server and this will determine if its the project or the computer. My first guess would be you need to reinstall windows.
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.