Which time zone should I set for my server?

This was the question I was faced with last week. I was configuring a VPC image in Sydney, that I was later going to load on to a physical box in San Diego, then use it from anywhere in the world. So which time zone to use?

I decided upon UTC, and now, the more that I think about it, I don’t know why all servers aren’t configured that way.

Advantages to using UTC:

  • No weird shifts/jumps around daylight savings
  • Accidental usage of DateTime.Now in server-side code returns that same value as DateTime.UtcNow anyway
  • Migrating applications and their data, or entire VMs across physical locations becomes easy

Disadvantages to using UTC:

  • Everything is stored in UTC, and thus hard for most humans to deal with mentally. The solution: tools like the Windows Event Viewer and SQL Management Studio should allow you to apply a time zone offset to visible results.

My recommendation: Run all your servers in UTC (that’s “GMT – Greenwich Mean Time” with “Automatically adjust clock for DST” turned OFF).

Maybe Adam can add this to his standards? 😉

Strange server behavior – huge I/O other count for csrss.exe (SOLVED!)

I can’t say this feels right to me:


Notice the 603 terabyte value in the “I/O Other Bytes” column for csrss.exe. Oh yeah, and the box has only been up for 24 hours. The number seems to climb by 50 or 60 GB a second when I’m connected via RDC. If I logoff then back on, the count starts again.

I’ve tried Googling it, but found no solutions.

Anybody got any ideas? It doesn’t actually seem to be causing a problem, it’s just out of the ordinary.

The box is a 1.8GHz Core2 Duo running Windows Server 2003 R2 Standard x64 Edition.

Update – I (think) I found the solution!

Following some suggestions in this post’s comments and on Google that this might be a virus, Edward suggested I fire up a copy of SysInternals Process Explorer on the server. I’ve used the SysInternals tools in the past, but not being a server guy by trade meant that I’d forgotten about them.

After finding the process, I was quickly comforted that this wasn’t a virus. The signature was verified, it was executing from the correct path (system32) and it was running under NT AUTHORITY\SYSTEM where I expected it to.


If we recall the original symptoms, the count was reset if I logged off RDC and back on again. This didn’t really prove much other than the fact that the process restarted at login. Swapping to the “Performance Graph” tab is Process Explorer did however show some interesting results.


Whenever I minimized my RDC window, it stopped requesting data and the I/O bytes graph was stagnant. As soon as I brought the RDC window back up and started interacting with it, the values skyrocketed. My screenshot doesn’t show it, but that graph was peaking to 80GB!

The end result would seem to be: “that’s just how much stuff is going on to support RDP”.

To me that’s an incredible amount on information being shuffled around and process, but I guess this is why the actual data on the wire is so efficient. Unless anything else comes up, I’m happy to file this in the “amazing but normal” pile.