Application.Quit - application not starting when debugging - c#

When I add Application.Quit(), or Form.Close(), and try running the program with Debugging, the debugging starts, but the Application doesn't. I asked this question yesterday. Visual studio debugging starts but application doesn't. And it is a continuation of that question. The process starts in the Task Manager. Its not being caught by my Antivirus.
I can save my project in a state where it is working, add Application.Quit(), start Debugging, and the program wont start. If I comment //Application.Quit, so it was the exact same project when it was saved, it still won't start. The only way to fix it, is to exclude the form that has Application.Quit() from the project. Then it starts working again. If I add the form back, the problem comes back.
I looked at how to use it properly https://msdn.microsoft.com/en-us/library/ms157894(v=vs.110).aspx. I have the FormClosing Event with e.Cancel. I have also tried closing the form Mainform.Close(); and Environment.Close(). All with the same results. I don't believe that I'm coding it wrong. There are no errors. But I'm at a loss as to why. It might be my computer. Or I might have to give up on having a warning box before closing. Although ultimately, I would like to have that.

In FormClosing Event if you set e.Cancel = true the application will not be closed anyway.
You should use some conditions for e.Cancel = true.
Declare a flag parameter and set it before Application.Quit() and in FormClosing Event check if the flag is true, then do not set e.Cancel = true

Related

Cannot edit after using 'Break All', although break points work fine

This seems to be a WPF-specific issue.
If I set a breakpoint in the code, the program will pause when it reaches that line, and I can edit/add/remove code, and then continue - it runs the newly edited code (ie, it behaves as expected).
However, if I hit 'Break All', I get moved to window that says "Your App has entered a Break State...". If I try to edit my code, nothing happens. I try to type but nothing happens - no text appears, and there's no errors that pop up or anything.
I don't have this problem in WinForms applications - just WPF. If I create a basic WPF project from the template, I still have the issue.
It's a very frustrating issue! My ugly hacked solution is to add a button to my program's UI called 'Break', which executes a single line of code that has a breakpoint on it, basically recreating the behaviour that 'Break All' should have.
Weirdly, it's not an issue if I'm on a WPF project which uses multiple threads. Hitting 'Break All' in this case acts as if there's a breakpoint on the line of code where the background thread is set up.
I am not sure..but you can give a try.
To enable/disable Edit and Continue. In the Options dialog box, expand the Debugging node, and select Edit and Continue. In the Options dialog box Edit and Continue page, select or clear the Enable Edit and Continue check box. The setting takes effect when you restart the debugging session
source:https://msdn.microsoft.com/en-us/library/ms164926.aspx

ReactiveUI.pdb not loaded

I'm using ReactiveUI in my WPF program, the WPF Window can be initialized and show normally, and I'm under Debug Mode,
but sometimes When I run some command code binding with button, it shows error below, and there're not more information, so I have no idea what's the reason to the Exception:
ReaciveUI.pdb contains the debug information required(...)
and after Continue, a window shows then the program was stopped:
An unhhandled Exception of type 'System.Exception' occured in ReactiveUI.dll
How to deal with this problem?
I found the keypoint of the problem later, the bug happens at
BtmCheckCmd = ReactiveCommand.CreateAsyncTask(
canBtmCheckCmd, //CanExecute
async _ =>//Execute
{
ProgressWinDow.RunCheckAndBarHandle();
MessageBox.Show("SomeThing");
}
I find a new way to check whrere the problem I former don't know so later I could found the solution.
In my case when the exception before happens, sometimes the messagebox show (sometimes not), then if the messagebox show, somtimes after click OK and the Exception Window Show, and if doing like this I can't find which part of my code does the problem haapen,
but if I click pause when the messagebox show(not click OK, but click pause under debug mode when msgbox show), then it go to the part of code it execute,
and by doing this I find the "Messagebox show" is in the code block of
async
in the part of code, and there're two method in async, so it should be the reason to this problem, maybe something wrong when async two method at the same time.
And In my case, the Messagebox is originally just used to test, so I delete the MessageBox and the problem solved.
Another way to find the problem in multi-thread is under debug mode,
and set the break points, then execute that part of code, when going into a break point, then go to the top ToolBar select :
Debug>>Windows>>Threads
then in the threads window can see what are the threads doing
In my case Visual Studio (2022) had locked a file.
To locate the locked file I did (in a console at the root of my project):
git clean -xfd
This gave me a message about several files which VS was locking.
But ultimately, the solution was to kill Visual Studio, perform a git clean, and then rebuild. You may also need to log out if on Windows to release the locked file(s) before rebuilding.

Debug not stopping after form closing in Visual Studio

Visual Studio Debug does not stop when i close the form that i write in C#. How can i stop debug process when i close form. I added Application.Exit() method in the form closing event but it didn't work.
Thank you.
Try this from here
If (System.Windows.Forms.Application.MessageLoop)
{
// Use this since we are a WinForms app
System.Windows.Forms.Application.Exit()
}
Else
{
// Use this since we are a console app
System.Environment.Exit(1)
}
EDIT:
If there are running infinite threads then do
Thread myThread = new Thread(...);
myThread.IsBackground = true; //set your running thread to background
myThread.Start(...);
And you can see how to? from here
Well this will be four years too late, however, I thought I'd post this for anyone else who runs into this issue (like I just did), sorry in advance if this is pretty basic, I'm fairly new to C# so this threw me for a bit.
I had the same issue as OP where, in my FormClosing event, neither Application.Exit() or Environment.Exit(0) would end the debugger.
The thing I found was looking at the reference count above my FormClosing event, it was showing '0 references'. I had just copied and pasted the closing event from another forum so there was no event handler to actually handle the event I had created/copied.
One easy way to resolve this (besides not copy and pasting code) was to create the event handler:
First go to the 'Form1.cs [Design]' tab
Navigate to the 'Properties' box
Click on 'Events'
Find 'FormClosing' and double click that
If you had the same issue you should now be able to see that there is at least 1 reference to the event. Now when you close the form it should also stop the debugger.
I landed on this question because VS was not stopping when a debugged application was shut down.
One way to see what might be causing the ide to hang is to click on pause and on the 'Debug Location' toolbar view any threads that are still running. For me I noticed that there was still a RabbitMq context that was not disposed of. So this was the clue i needed.
After I made the code change, VS now stops it debugging session once the application exits.
I know this is not a solution that you might be expecting but finding out why applications are not exiting properly or still keeping background processes alive is a very tricky subject. The active threads drop down is the best place to look imho.
Another possibility is, that your process runs in an exception which isn´t handled correctly. I used to show exception messages in self-build dialogs, but forgot to show the created window in one case. So the program ran into the exception, created the window but just didn´t show any sign of it... so the process kept running even when I closed the application.

Visual Studio 2010 Pro, not ending debug mode on application close

When I run my code within VS, when I enter certain methods, upon ending the application (closing the form) been debugged, VS does not end the debug session automatically forcing me to end it manually.
This doesn't always happen, the results are consistent with certain windows / classes loaded when the application is run within VS.
I want to know why this may be, I'm assuming its an indication of a file not been closed in my managed code or 'something' like that.
Why might this occur and how can I trace and fix it?
This would happen if your code keeps running after closing the window.
Pause the debugger after closing the window to find out what it's doing, then modify the code so that it stops running when you close the window.
On Debug menu, click "Detach All".
Hope that helps!
EDIT
Follow, SLak's advice, as that will go after the problem. My solution may only fix the symptom. I will leave the answer here just in case it is helpful to you though.
Good luck!

DispatcherTimer with Window.Close causing crash

I am writing a C# app that has a main window and a separate login window. I set a DispatcherTimer to open a new login window if the user is idle for a certain period of time.
My app is crashing when i call .Close() on the login window. However, if I remove the DispatcherTimer code it works fine. Is System.Timers.Timer a better choice for this or is there something else I maybe doing wrong?
The strange part is the app doesn't crash and works fine when I run it in Visual Studio, but crashes when i Install it then run it.
Thanks,
Matt
Edit: I just tried installing it on my machine it works fine, but will break when installed on a client machine. Not sure why this would happen.. Maybe a missing dependency in the setup project? Thanks for your posts guys.
Breaking on all thrown exceptions may allow you to get a call stack for the problem. Go to "Exceptions..." in the Debug menu, and check all of the checkboxes in the "thrown" column.
You will probably want to undo this after you are done testing because it will break even on exceptions handled correctly by the application.

Categories