Interface freezes in multithreaded C # application

Question

I have a multithreaded C # .NET application that freezes an interface. What is unusual about this is that the interface does not freeze if I do not let the system stand idle long enough for the splash screen to start (which requires me to re-enter the password to re-access the system). When the interface becomes visible again (after I have successfully entered my password), the interface is locked. Until I let the screensaver run, then the interface is not blocked.

I must indicate that I have two different executables that access the same DLL, and this problem occurs regardless of which application I use to access the DLL. This, apparently, means that the problem is with the DLL, because the two applications are completely different (C ++ / MFC) and (C # /. NET), in addition to how they relate to the DLL.

Both exes perform similar steps in how they interact with the DLL. They make calls to the dll to set up serial port communications, open a status window in the DLL, start the thread in the DLL to monitor the communication port, and then start the thread in the main application that controls the stack in the DLL.

When data is received from the communication port by the stream in the DLL, it is analyzed and its results are pushed onto the stack, and then sent to the status window through the delegate. When a stream in exe sees data on the stack, it displays the data in the main window, also using a delegate.

I found that if I add code to the stream inside the DLL so that it calls Application.DoEvents () every 30 seconds, the interface will freeze for 30 seconds and then resume activity as usual. I suppose something is blocking the main thread and making DoEvents () fire, it seems to block the lock, but I don't know what might cause this lock.

This problem occurs both on my development machine and on the test machine.

I tried to completely remove the data output to the status window inside the DLL, but it did not matter.

I have been doing multithreaded programming for many years and have never seen anything like it; so any advice would be highly appreciated.

Thanks.

Answer 1

This is a problem commonly caused by the SystemEvents class when you have a non-standard way to initialize your user interface. The use of threads in particular. Run your program, Debug + Break All, Debug + Windows + Threads. If you see a stream called ".NET SystemEvents", then you are almost guaranteed to get it.

Some prerequisites: The SystemEvent class supports both console applications and graphic applications. For the latter, it must run event handlers in the user interface thread. The first time one of its events is signed, it creates a small invisible auxiliary window for receiving system notifications. He can do this in two ways, by creating a window on the calling thread or by launching an auxiliary thread. It makes a decision based on the value of Thread.GetApartmentState (). If it is an STA, then it can create a window in the calling thread, and all event callbacks can be properly bound to this thread.

This is not the case if the first window created is not created in the user interface thread. For example, a screen saver. This window may contain controls that are interested in a system event, such as UserPreferenceChanged, so that they can be redrawn correctly. Now it uses an auxiliary thread, and any event will be fired from this auxiliary thread, not the user interface thread. Poison any window that runs in the user interface thread. A session disconnects from a locked workstation (including a screen saver) for some mysterious reason that could cause a dead end. You can also see a random setback in painting, a less unpleasant result of using windows from the wrong thread.

Without fixing the initialization order, a workaround is to put this in your Main () method before creating any windows:

Microsoft.Win32.SystemEvents.UserPreferenceChanged += delegate { }; 

Answer 2

The problem seems to be related to the ActiveX control, probably misused in the form. I switched to using the serial port library in .NET and could not reproduce my problem. Thanks to everyone, especially Hans for the help.

Answer 3

I have the same problem as my computer, it just freezes when the screen saver starts, or I lock my computer and the monitor goes to sleep. I am 95% sure that my multi-threaded application has deadlocks. Take a look and see if there are any deadlocks in your code.