views:

306

answers:

3

I've been experiencing a high degree of flicker and UI lag in a small application I've developed to test a component that I've written for one of our applications. Because the flicker and lag was taking place during idle time (when there should--seriously--be nothing going on), I decided to do some investigating. I noticed a few threads in the Threads window that I wasn't aware of (not entirely unexpected), but what caught my eye was one of the threads was set to Highest priority. This thread exists at the time Main() is called, even before any of my code executes. I've discovered that this thread appears to be present in every .NET application I write, even console applications.

Being the daring soul that I am, I decided to freeze the thread and see what happened. The flickering did indeed stop, but I experienced some oddness when it came to doing database interaction (I'm using SQL CE 3.5 SP1). My thought was that this might be the thread that the database is actually running on, but considering it's started at the time the application loads (before any references to the DB) and is present in other, non-database applications, I'm inclined to believe this isn't the case.

Because this thread (like a few others) shows up with no data in the Location column and no Call Stack listed if I switch to it in the debugger while paused, I tried matching the StartAddress property through GetCurrentProcess().Threads for the corresponding thread, but it falls outside all of the currently loaded modules address ranges.

Does anyone have any idea what this thread is, or how I might find out?

Edit

After doing some digging, it looks like the StartAddress is in kernel32.dll (based upon nearby memory contents). This leads me to think that this is just the standard system function used to start the thread, according to this page, which basically puts me back at square one as far as determining where this thread actually comes from. This is further confirmed by the fact that ALL of the threads in this list have the same value for StartAddress, leading me to ask exactly what the purpose is...?

Edit 2

Process Explorer let me to an actually meaningful start address. It looks like it's mscorwks.dll!CreateApplicationContext+0xbbef. This dll is in %WINDOWS%\Microsoft.NET\Framework\v2.0.50, so it looks like it's clearly a runtime assembly. I'm still not sure why

  • it's Highest priority
  • it appears to be causing hiccups in my application
+1  A: 

I'm not sure what this is, but if you turn on unmanaged debugging, and set up Visual Studio with the Windows symbol server, you might get some more clues.

Tim Robinson
The GC was something I had thought of, but I couldn't really think of why it would be set to Highest (not eve AboveNormal, but HIGHEST).
Adam Robinson
I thought the GC ran on a low-priority thread. Where did you see it run on a high-priority thread?
Erich Mirabal
Oops, you're right. I'll remove that.
Tim Robinson
Maybe I'm not... I just can't find any good definitive reference on that.
Erich Mirabal
I don't know about references, but the first page of Google results agrees with you.
Tim Robinson
I posted a question (http://stackoverflow.com/questions/830822/) to help answer this. I found one article (http://blogs.msdn.com/cbrumme/archive/2003/04/15/51319.aspx) that made it seem like it does run on a high priority thread.
Erich Mirabal
I've looked this up in Richter and posted under your new question.
Tim Robinson
+5  A: 

You could try using Sysinternals. Process Explorer let's you dig in pretty deep. Right click on the Process to access Properties. Then "Threads" tab. In there, you can see the thread's stack and module.

EDIT:

After asking around some, it seems that your "Highest" priority thread is the Finalizer thread that runs due to a garbage collection. I still don't have a good reason as to why it would constantly keep running. Maybe you have some funky object lifetime behavior going on in your process?

Erich Mirabal
A: 

Might be the Garbage Collector thread. I noticed it too when I was once investigating a finalizer-related bug. Perhaps your system memory is low and the GC is trying to collect all the time? This was the case in the previously mentioned bug too. I couldn't reproduce it on my machine, but a co-worker of mine had a machine with less RAM where it would reappear like clockwork.

Vilx-