.Net Application hangs if I lock my system

[ashish81sharma]

Hi,
I have a weired problem. I developed a multithreaded WinForm application using VB.Net, and SQL Server 2008. The application works perfectly fine if I am using Visual Studio IDE to run the same. But, if I run the exe file created by VS the application hangs in case I lock my system and again relogin.
The memory usage is same as it was before locking the system. CPU usage is also 0% or by max 2%. All threads are also exited after finishing there designated tasks.
The application also uses threading but all threads are exited after there designated tasks. I confirmed this using various tools.
I am using the following configuration:

Windows XP SP2
Visual Studio 2008 SP1
SQL Server 2008
Infragistics 2008 Volume 1 (v8.1)
Janus Time Line Control

I tried to get the process information with the following tools:

SYSInternals Process Monitor
SYSInternals Process Explorer
Microsoft WinDbg 6.11

Everything seems to be fine with all the tools.

Thanks in advance for your valuable support.

Regards,
Ashish Sharma

[sknake]

Can you duplicate this behavior in a sample project and upload it? You can upload files by hitting "Go Advanced" then "Manage Attachments"

I have seen executables behave differently when run inside of the IDE versus outside but its pretty rare. If you disable the visual studio hosting process it tends to solve a lot of those issues for me.

Unfortunately without seeing your code its hard to say whats going on. Applications tend to run a little bit slower when executed from the IDE since they have a debugger attached to the process. Normally this isn't a big deal but with threads it can be -- because you may have concurrency issues in your threading logic where inside of the IDE they run as expected but when run outside of the IDE they run a little faster -- and lock eachother up. Either way I can't imagine a program locking up the workstation to the point you have to log off. That sounds like a pretty bad problem :P

[ashish81sharma]

Can you duplicate this behavior in a sample project and upload it? You can upload files by hitting "Go Advanced" then "Manage Attachments"

I have seen executables behave differently when run inside of the IDE versus outside but its pretty rare. If you disable the visual studio hosting process it tends to solve a lot of those issues for me.

Unfortunately without seeing your code its hard to say whats going on. Applications tend to run a little bit slower when executed from the IDE since they have a debugger attached to the process. Normally this isn't a big deal but with threads it can be -- because you may have concurrency issues in your threading logic where inside of the IDE they run as expected but when run outside of the IDE they run a little faster -- and lock eachother up. Either way I can't imagine a program locking up the workstation to the point you have to log off. That sounds like a pretty bad problem :P

Hi Sknake,
Thanks for your reply.
As per your suggestions, I tried to replicate the behavior in sample application but was not able to reproduce the problem.
I myself also feels that this could be the problem of threading. But the strange thing is that the application locks up only in case I leave it idle for more than 10-15 minutes. If I keep working on the application then everything seems fine.
As I stated this earlier that I already checked that all threads are exited after completing there assigned task but still I feel that this could be the problem from threading side.
Do you know tool I can use to identify the same?

Thanks and regards,
Ashish Sharma

[sknake]

Oh a misread your thread. I was thinking the application locked your entire system up, but this morning it seems you meant that the app freezes if you lock your system and relogin?

Have you tried launching your application outside of Visual Studio then waiting until it locks up and attaching a debugger to it? You can debug running processes with VS (although I haven't tried it on a frozen app). Can you upload the entire application that is giving you issues? You could also have it write diagnostics output and attach a debug listener to it to see where the last calls are made before everything grinds to a halt. Take a look at System.Diagnostics.Debug.Write for diagnostic output.

[WorkerThread]

This is because you should be really careful when creating UI controls in another than the main UI thread.

For example, if you use a background worker:
http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.dowork.aspx

MSDN says: "You must be careful not to manipulate any user-interface objects in your DoWork event handler. Instead, communicate to the user interface through the BackgroundWorker events."

In my case I have found what seems to be a workaround (a bit weird and dont know how but seems to work...).
It consits of create blank invisible form in a separated thread when your application starts.

In the constructor of your main form put this lines:

unhangThread = new System.Threading.Thread(new System.Threading.ThreadStart(this.callForm));
            unhangThread.Start();

where unhangThread is a private variable of type System.Threading.Thread
and the method callForm is defined as:

private void callForm()
        {
            //Create a Form that will be running in the unfreezing thread.
            //Show it as invisible in a point outside the screen.
            Form aForm = new Form();
            aForm.Height = 10;
            aForm.Width = 10;
            aForm.Location = new Point(2000, 2000);
            aForm.Visible = false;
            aForm.Show();
        }

Hope this helps!

[kvprajapati]

Welcome WorkerThread.

I appreciate your help. Have you ever noticed that the current thread is one years old? Please do not resurrect old threads and have a look at forum rules.

Please read before posting - http://www.daniweb.com/forums/thread78223.html