LP on .NET

April 8, 2010

Deferred Procedure Calls and CPU Usage

Filed under: Software,Windows — Larry Parker @ 11:13 pm

I recently started using an old Dell Dimension desktop (circa 2005) on a regular basis and for the past couple of months have noticed that the CPU would periodically increase to around 20% for no apparent reason.  This had been causing mouse slowdowns (giving it a rubber band effect as it moved across the screen) as well as audio pops and clicks as I listened to music.

At first I thought it was some service performing housekeeping and I just dealt with it.  The “CPU storm” would typically last for ten minutes or so and then calm back down.

But this week I just couldn’t take it anymore and decided to get to the bottom of it.  After some Google searches and various troubleshooting (see below) I encountered a common recommendation:  update the video drivers.

It turns out that my old NVIDIA geForce 6800 was running a very old driver, and updating it to the latest version fixed the problem!!  Beautiful!  🙂

Technical Details

What I found strange while troubleshooting was that Task Manager showed the CPU at 20% but did not indicate any process taking up much CPU time on the Processes tab.

After digging around a bit more, I came across something called deferred procedure calls.  According to Wikipedia’s entry on this, a deferred procedure call is a Windows operating system mechanism that allows high-priority tasks to defer lower-priority tasks for execution at a later time.

By a stroke of luck, I recently installed Microsoft’s Process Explorer utility to find out which process had grabbed hold of a particular file, and just happened to see an entry for DPC’s:

ProcessExplorer

When the CPU storm was in progress, I indeed confirmed that the DPC’s were taking up a fair amount of CPU time, and this coincided with the slow mouse and audio pops.

Since updating my video drivers, I have not seen the DPC’s jump up very high for more than a second or two.  And my mouse and audio have been behaving great.

The storm has subsided and it’s been smooth sailing ever since!!

Hope this helps.

Advertisements

April 5, 2010

File Timestamp Problem under Windows Embedded

Filed under: .NET,C#,Windows — Larry Parker @ 9:35 pm

I ran into quite the interesting problem today.  The QA team was testing a module of mine that syncs up files via a WCF service.  The lab had a server and two workstations.  Things were working great on one of the workstations, but the other would not sync up some files.  Every time the workstation sent its file snapshot to the server it identified files that were out of sync and dispatched a sync package that then got applied at the workstation.  This cycle kept up throughout the morning.

After much debugging and viewing of various WCF trace files (using Microsoft’s invaluable  Service Trace Viewer tool), it turned out that some of the files getting synched up at the workstation were being touched (using .NET’s File class and the SetLastWriteTimeUtc method) with a timestamp that was a second ahead of what should have been written.

For example, if I set the file’s last write time to 8:50:37 AM, the file would then show 8:50:38 AM when I looked at its properties in Windows Explorer (the Modified field).  But some other files did get the exact timestamp I wrote out.  And, everything worked fine on the other workstation.

What gives??

It dawned on me that the difference between the two workstations was the operating system.  The machine running Windows XP worked fine.  The machine having the problems was running Windows Embedded POSReady 2009.  Hmmm…

I then wrote a simple program to reproduce and isolate the problem.  Here’s the code:

static void Main(string[] args)
{
    DateTime ts = DateTime.Parse("2010-04-05T12:50:00");
    for (int i = 0; i <= 59; i++)
    {
        Console.Write("Testing {0}: ", ts.ToLongTimeString());
        TestTimestamp(ts);
        ts = ts.AddSeconds(1);
    }

    Console.WriteLine("\nPress Enter to exit...");
    Console.ReadLine();
}

private static void TestTimestamp(DateTime ts)
{
    String file = "TimestampTest.txt";
    using (File.Create(file)) ;
    File.SetLastWriteTimeUtc(file, ts);
    DateTime ts2 = File.GetLastWriteTimeUtc(file);
    File.Delete(file);

    if (ts.Second != ts2.Second)
    {
        Console.Write("Error!  Expected seconds={0}, actual seconds={1}",
            ts.Second, ts2.Second);
    }
    else
        Console.Write("Passed!");

    Console.WriteLine();
}

Here’s how it ran on the Windows XP machine:

TimestampBug1

And here’s how it ran on the Windows Embedded machine:

TimestampBug2

Strange — timestamps with even seconds work, but those with odd seconds don’t!  They get “rounded” up to the next even second.

My workaround was easy enough.  Instead of comparing file timestamps down to the second, I added some tolerance for a couple of seconds.  Works for me (and for QA as well).

But I’m curious as to what’s going on under the covers with the SetLastWriteTimeUtc on Windows Embedded (all machines were running .NET 3.5 SP1).

I’ll have to post this on the Microsoft forum and will update this blog post if I find anything out.  If any readers have encountered this problem, please let me know!

Create a free website or blog at WordPress.com.