We Keep Coding

Is there a way to force the application to run as single threaded?

We have an old project that we are supporting and there is an issue that occurs most probably due to multi-threading.
The original implementer 'fixed' it by doing a Thread.sleep before executing the problematic section.
The workaround works but as the section is inside a loop the thread.sleep adds multiple minutes to the time it takes for the section to finish.
In the last month we have been we have been experimenting with lower values for the sleep but we wish to find the root cause. During our investigations we were doing lock on private objects wherever we felt like that would help.
We looked for anything that might be spawning additional threads - found none.
No Thread.start and no ThreadPool usage.
What is confusing us is that during debugging we find our main thread in the middle of about 8 other threads that we don't know who spawned them.
These are background threads so first thought I had was the threadpool but as I mentioned no mention of it in the code.
It is .net 2.0 so no Asyncs.
This is just a part of the bigger application so it is a windows service but we run it as CMD to be able to debug it easily The main application itself is a windows forms desktop app.
It also uses COM+ components if that is any help.
I've tried [STA] instead of [MTA].
Also Locking as aforementioned.
MemoryBarriers as well.
We still get the issue.
The issue is basically corrupted datasets and nulls in objects where they shouldn't be.
It happens in about once every 25-100 iterations so reproduction is not straight forward but we have devised a test specifically for this issue to try to reproduce it.
All that is pointing us into the direction of thread issues.
Back to the original question -
Who could possibly by spawning those additional threads and how do we prevent these threads for being created?
Please note the threads marked with red - those are background threads and as far as we can see no mention of them in the code.
The suspected thread in the screenshot is actively modifying the cols in the dataset. Problem is - the methods calling the SetColValueOnRow function that the thread is executing are typical and don't use any kind of threading.
The CPU affinity for this application is set to 1 Core [part of the original work-around]
Thanks
Edit: The database is oracle 12c but the issues we face happen before writing to the database.
They usually happen in DataSets where a whole record or a few of its columns can be wiped once every few testing iterations

I think you need to investigate why Thread.sleep works. It does not sound like the code is by itself spawning additional threads, but you would have to go through the entire code base to find that out - including the COM+ components.
So the first thing I would do is to start up the program in debug and just press the F10 key to step into the program. Then open up the threads debug window and see if you see about the same number of threads as given in your question. If you do, then those are simply threads from the thread pool and your issue is probably unrelated to the multiple threads.
If you don't see the same number of threads, then try setting a breakpoint at various stages of the program and see if you can find where those threads are getting created. When you find where they are getting created, you can try adding some locking at that point. But, your issue still might not be caused by multiple threads corrupting memory. You should investigate until you are convinced that the issue is due to multiple threads or something else.
I suspect that the issue might be related to one or more of the COM+ components or maybe the code is calling some long running database stored procedure. In any case, I suspect the reason why Thread.sleep works is because it is giving the suspect component enough time to complete its operation before starting on the next operation.
If this theory is true, then it suggests that there is some interaction between operations and when Thread.Sleep is given a sufficiently large value to allow the operation to complete - there are no interaction issues. This also suggests that perhaps one of the COM+ components is doing some things asynchronously. The solution might be to use locks or critical sections inside the COM+ components code. Another idea is to redesign the section of code that is causing the problem to allow multiple operations simultaneously.
So, the problem you are experiencing may not be due to multiple threads in the C# code you are looking at - but might be due to a long-running operation that will sometimes fail if not given sufficient time to complete before starting the next operation. This may or may not be due to multiple threads in the C# code.

Yet another C# Deadlock Debugging Question

I have a multi-threaded application build in C# using VS2010 Professional. It's quite a large application and we've experienced the classing GUI cross-threading and deadlock issues before, but in the past month we've noticed the appears to lock up when left idle for around 20-30 minutes.
The application is irresponsive and although it will repaint itself when other windows are dragged in front of the application and over it, the GUI still appears to be locked... interstingly (unlike if the GUI thread is being used for a considerable amount of time) the Close, Maximise and minimise buttons are also irresponsive and when clicked the little (Not Responding...) text is not displayed in the title of the application i.e. Windows still seems to think it's running fine.
If I break/pause the application using the debugger, and view the threads that are running. There are 3 threads of our managed code that are running, and a few other worker threads whom the source code cannot be displayed for.
The 3 threads that run are:
The main/GUI thread
A thread that loops indefinitely
A thread that loops indefinitely
If I step into threads 2 and 3, they appear to be looping correctly. They do not share locks (even with the main GUI thread) and they are not using the GUI thread at all. When stepping into the main/GUI thread however, it's broken on Application.Run...
This problem screams deadlock to me, but what I don't understand is if it's deadlock, why can't I see the line of code the main/GUI thread is hanging on?
Any help will be greatly appreciated! Let me know if you need more information...
Cheers,
Roo
-----------------------------------------------------SOLUTION--------------------------------------------------
Okay, so the problem is now solved. Thanks to everyone for their suggestions! Much appreciated! I've marked the answer that solved my initial problem of determining where on the main/UI thread the application hangs (I handn't turned off the "Enable Just My Code" option).
The overall issue I was experiencing was indeed Deadlock, however. After obtaining the call-stack and popping the top half of it into Google I came across this which explains exactly what I was experiencing...
http://timl.net/
This references a lovely guide to debugging the issue...
http://www.aaronlerch.com/blog/2008/12/15/debugging-ui/
This identified a control I was constructing off the GUI thread. I did know this, however, and was marshalling calls correctly, but what I didn't realise was that behind the scenes this Control was subscribing to an event or set of events that are triggered when e.g. a Windows session is unlocked or the screensaver exits. These calls are always made on the main/UI thread and were blocking when it saw the call was made on the incorrect thread. Kim explains in more detail here...
http://krgreenlee.blogspot.com/2007/09/onuserpreferencechanged-hang.html
In the end I found an alternative solution which did not require this Control off the main/UI thread.
That appears to have solved the problem and the application no longer hangs. I hope this helps anyone who's confronted by a similar problem.
Thanks again to everyone on here who helped! (and indirectly, the delightful bloggers I've referenced above!)
Roo
-----------------------------------------------------SOLUTION II--------------------------------------------------
Aren't threading issues delightful...you think you've solved it, and a month down the line it pops back up again. I still believe the solution above resolved an issue that would cause simillar behaviour, but we encountered the problem again.
As we spent a while debugging this, I thought I'd update this question with our (hopefully) final solution:
The problem appears to have been a bug in the Infragistics components in the WinForms 2010.1 release (no hot fixes). We had been running from around the time the freeze issue appeared (but had also added a bunch of other stuff too). After upgrading to WinForms 2010.3, we've yet to reproduce the issue (deja vu). See my question here for a bit more information: '.NET 4.0 and the dreaded OnUserPreferenceChanged Hang'. Hans has given a nice summary of the general issue.
I hope this adds a little to the suggestions/information surrounding the nutorious OnUserPreferenceChanged Hang (or whatever you'd like to call it).
Cheers,
Roo

I would check to make sure there is no modal dialog that is being launched behind the main form. This can happen if the dialog is launched and some event causes the main form to steal back focus. You can avoid this by making sure the modal dialog has the main form as its Owner when you create it.

Check where it's hanging in Application.Run; disable Just My Code in Debugger Options, then look at the call stack.
I've fixed an application that deadlocked in Application.Run because it was trying to remove an event handler from an object that a different thread was locked on. (Until the C# 4.0 compiler, event handler accessors implicitly lock(this))
However, if you're using VS2010, that isn't the exact issue.

c# isBackground Thread is NOT terminating properly

I have one background thread I use for processing separately from the GUI, and everything works fine between the threads. However when I close the application, the program "closes" but does not kill the process. The background thread is keeping the program alive it seems.
I have set "myThreadInstance.IsBackground = true;", and I thought this would require C# to kill it when it is killed.
I am testing this all in Visual Studio (2010, using .NET 4.0), and after the first build, the rest all fail because the exe is still in use so it cannot overwrite it. Looking in task manager, it is there. Killing Visual Studio releases the vbhost process which releases my exe. Killing my exe's process, makes vbhost respawn it in a second or two.

Actually, based on your description and other things you've tried (and their results), I believe the most likely cause is this:
You have another foreground thread in your application, other than the one you're examining.

Try using Application.Exit(0); in the form_closing/form_closed event.
Bug: I think this might be a bug. Look at the comments at the bottom of this MSDN page: http://msdn.microsoft.com/en-us/library/system.threading.thread.isbackground.aspx
Also, try using the BackgroundWorker. Here's a good description in the VisualStudio Magazine: http://visualstudiomagazine.com/articles/2007/09/01/simplify-background-threads.aspx

This type of problem usually requires code to figure out. Take your app and trim it down to the bare minimum necessary to show the issue.
However, most likely you are either not signaling the thread to terminate or the thread is such a long running beast that it doesn't ever see the signal.

How could I get to know the resources occupied by a .NET thread?

I am developing a multi-thread application and one of my threads is somehow blocked by something and thus it will occupy some resource such as a file forever. Is there a way to find out which thread is being blocked and more important what resouce is being held by that thread?
At last and as usual, thanks for your patience and reply. :)
---------new progress----------
Since all the resouces on the windows platform are accessed via "handles". I am thinking if there is a way to list all the handles a .NET thread is holding?

When you Create the Threads, you can Set a Name for each thread just before you start it. You can then use these in the Debugger to identify the Thread in question.
Then when your program doesn't close, you jump up to the debugger and Hit Pause, you can then via the active threads. Debug->Windows->Threads (CTRL-ALT+H)
If your threads are not critical, and you just want the system to Close upon Completion you can set .IsBackground on the thread and you don't need to perform any special operations to get your thread to close, often though this may lead to other conditions you were not expecting.
I personally also use System.Threading.AutoResetEvent(duration) instead of Sleep(duration) because if I wish to exit, I set mIsRunning=false then set the event which will cause the Stopping of the Event to Wake up, but Exit Immediately. A Sleep has to finish before it resumes.

The new Concurrency Profiler in Visual Studio 2010 was built to answer and solve this type of question.
Resource Contention Concurrency Profiling in Visual Studio 2010 – Performance Investigation Flows
I recommend downloading the trial version if you don't already have Visual Studio 2010. You won't be disappointed. :)

If you are familiar with dump analysis using WinDbg, you can also capture a hang dump when this issue happens, and then manually analyze the dump to see which thread hangs and why.
http://blogs.msdn.com/tess/archive/tags/Performance+issues+and+hangs/default.aspx

To Thread or not to Thread when starting an external application in C#

I'm creating a win service that monitors ftp logs, when a file has been uploaded I want to start an external application, like a powershell script, to do stuff with the file. my Question is do i want to spin this off into another thread when i do it or should I just wait until it finishes before moving on.
This process is already going to be in a thread (the service is going to be monitoring multiple servers) and the idea of threads starting threads worries me. Is this something to be worried about or is this a case of too much tinfoil in my hat.

Well, code it in a modular fashion and don't worry about threads. If, down the road, you find that your application will benefit from a multi-threaded approach then address it then. If you have build your components orthogonally then the threading part will fit more naturally.
Addressing threading concerns at the very beginning of an application always feel like premature optimization to me. Build the components first and worry about how to thread them later.
[Edit] I am in no way advising you to not think about threading at all. Every component needs to be build with the potential for use by multiple threads - this is a defensive and intelligent practice in all applications. What I meant was don't worry so much about how the application will handle threads and how to set up the thread management of the application first.

I think the more important question is what do you get out of spawning another thread? If you don't need to have the code execute in parallel, then don't do it. If you do, there should be no problem. If you are concerned with the child thread creating its own thread, then delegate the thread creation to the ThreadPool.

The primary question: do you need to know the outcome of that process? If you can fire and forget, then do that - it's easier. If you need the outcome, then wait for it.
Also, have you considered using the FileSystemWatcher? It works remotely.

Although somewhat off-topic, since you mentioned that you'll be launching a powershell script, I wanted to point out the option to run the script in-process via a powershell "runspace". Here's a minimal example:
using System.Management.Automation;
static class PoshExec
{
static void Exec(string scriptFilePath)
{
(new RunspaceInvoke()).Invoke("& " + scriptFilePath);
}
}
add a reference to
c:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0\System.Management.Automation.dll