I'm trying to figure out why the application process lingers in Task Manager after the application is closed and the window disappears.
When I get VS to attach to the zombie process and break all, the threads window shows that the main thread is still alive, and a number of worker threads as well.
Some questions:
Are worker threads necessarily background threads? If not, how do I identify the background threads as I didn't see such a column in the window?
Do I simply double-click on each thread in the thread window, and watch the Thread.IsBackgroundThread value?
When I click on the main thread, the debugger doesn't show a call stack. How
do I identify where the main thread is stuck?
I would strongly sugest you tu use WinDbg. It is not a visual debugger though it is much more powerful.
Surely I will figure you out.
To list all threads in a process use: ~.
To switch to a certain thread ~thread_ids.
To see stak of curent thread !clr_stack.
Brief tutorial.
http://www.codeproject.com/KB/debug/windbg_part1.aspx
Also try in google "Debuging Asp.net with windbg"
Related
I have some difficulty debugging a multithread app. So I set up a breakpoint in a worker thread and application hits it, but when I try to resume it just doesn't continue execution. It should end worker thread and then comeback to main form, but worker thread popup (it spawns a small form) just stays there forever. In addition, when I tried to break execution after that "continue" Visual Studio stops at Application.Run(...). My goal is to debug few lines in worker and see effects in main form. Anyone experienced that issue? Or maybe it is not an issue at all?
Spawning UI on worker threads is not a good idea. If your thread is not a primary UI thread, then do not create or update UI Elements on it.
If you are in WPF, you would need to use something like Application.Current.Dispatcher.Invoketo create or update UI on the proper thread.
I'm developing a Windows application to run in the background (for a long running process).
Application shows process status by a NotifyIcon tool tip.
I added a ContextMenu control to the NotifyIcon tool tip control. Whenever the application is idle (not doing any work), the context menu works fine, but during the running of a process the context menu hangs.
All processes are running in different threads. Can anyone tell me how I can make a smooth context menu for a long running background process?
The exact same rules apply to a program that has a NotifyIcon as a program that uses Window or Form to show a user interface. NotifyIcon sends notifications to the main thread of the process, the one on which you called Application.Run(). And if that main thread is busy with other tasks, like "running of a process" then the NotifyIcon goes catatonic. It is trying to send the notification but your main thread isn't listening since it is busy executing that "process".
And you'll have to solve this the exact same way as in a regular gui program, you have to run the processing code on a worker thread. Use the standard .NET solutions, like BackgroundWorker, Task or the async/await keywords. Or spin your own with Thread or ThreadPool.
If you are already doing this, it isn't clear from the question, then watch out for, say, a BackgroundWorker that calls ReportProgress too often and still gets the main thread bogged down.
For the purpose of testing, I need to manually kill a named thread (in a debugging session) from Visual Studio - or any other tool that allows me to do that?
But the Threads Debug Window in Visual Studio 2010 only has a Freeze option in the thread's context menu, and Sysinternal's ProcessExplorer only lists processes, not threads.
Is there a way to manually kill a specific (running) thread?
It's not easy to just kill a thread because the designers of the language want to avoid the following problem: your thread takes a lock, and then you kill it before it can release it... now anyone who needs that lock will get stuck.
What you have to do is use some global variable to tell the thread to stop. You have to manually, in your thread code, check that global variable and return if you see it indicates you should stop.
I am trying to figure out what changed within a project that now causes the application to not exit the debugger when I close the application I am debugging. I have also noticed that unhandled exceptions no longer invoke the unhandled exception handler, I am not sure if it's related.
This is probably due to other threads, which are not set as background threads, keeping the application alive. Background threads will terminate when the application does, whereas foreground threads will keep the rest of the application alive until they complete.
One way to check for the thread(s) that are responsible is in the debugger, as follows:
Run your app in the debugger
"Exit" your app.
Wait until the app should have exited but hasn't
Break into the app using the "pause" button
Open the "Threads" debugging window
Look for any threads in this window. Chances are there will be one, or a few threads showing. See if you can identify what they are by the info in the window.
It may also help to open the "Stack" debugging window and then double-click on each thread in the "Threads" window in turn and look at the contents of the "Stack" window. You may be able to see what any stuck threads are trying to do.
The debugger exits when all the threads exit. You've probably created an extra thread and done nothing to terminate it.
And this would explain unhandled exceptions being uncaught: if they happen on a different thread you won't see them on the main thread.
Most certainly the application has not actually terminated. Do you have any other threads running? An application will not shut down until all foreground threads have terminated.
We have an application written in .net, c#, winforms. We noticed that sometimes when closing the application, the process remains.
I'm not sure how I can reproduce that behavior, so I'm looking for some clues as to why the application wouldn't exit.
The application uses a bit of background threads. Thread pools. Wondering if that could be the cause. Anything else could have this effect?
If you have thread's that have IsBackground property set to false that are alive after application is closed, they will remain
The application uses a bit of
background threads. Thread pools.
Wondering if that could be the cause.
Anything else could have this effect?
It most definitely could be the cause though I cannot be certain that it actually is. One way to test this hypothesis to make sure all threads that have been explicitly created are designated as background threads. This can be done by setting Thread.IsBackground = true which will allow the application to terminate if the main thread ends. If there is at least one thread for which IsBackground = false then the CLR keeps the host process running.
Its likely to be a thread left running. If you have a look at the process in task manager you can see when a thread starts, and how many are left running when it exits by adding the 'Threads' column from the view menu.
I would start by making sure you start and end on the same thread count.
Get Process Explorer and possibly Process Monitor and see what thread is left suspended or running.
If you are able to run in debug and you close the form, VS should not return to the normal code edit mode (it will still have the pause and stop buttons from debug active). You can then press Pause and check the Threads window to see where the call stacks are stuck for threads that are still active.