0

I am profiling a colleague's C# application. The VS2015 analysis tool shows that 33% of exclusive samples occur in System.Windows.Forms.Application.Run. Nearly all of the computation occurs inside a click event, and the form is unresponsive as you would expect. I searched through the code to make sure no threads were being created explicitly.

I was trying to figure out where that 33% was being used. When I stop the application randomly, it's always in windowThreadProc (file SystemEvents.cs) waiting on messages. I can step through the loop even as the main computation is running; so, it's clearly on a separate thread.

The function EnsureSystemEvents is run before Main. I can step through it and see it's spinning up a thread for windowThreadProc. I can see the [STAThread] attribute above Main.

Shouldn't there be only one thread? Please explain.

Todd
  • 475
  • 4
  • 15
  • I don't have much of a grasp of the apartment model. Partly, I was looking at the code in EnsureSystemEvents, which checks the apartment state. If the apartment is STA, it runs the message pump on the current thread. – Todd Aug 10 '17 at 14:35
  • 2
    It should be spending 99% of its time there. But sure, when you have a Click event handler that turns the UI catatonic then it will be less. You must profile only the Release build with the Visual Studio Hosting process option disabled. – Hans Passant Aug 10 '17 at 14:41
  • It didn't make much of a difference in the profiling results. The threading of the message pump was the same. – Todd Aug 10 '17 at 15:07

0 Answers0