I'd like to thank all of you who submitted entries--even the person who felt it necessary to email me a large picture that had, at best, a tangential relationship to the posited question and probably should not have approached within 100 nautical miles of my work computer.  You know who you are, and I do appreciate the thought.  'Nuff said.

On to the results:

• The winner of the software (Project Gotham Racing 3 for Xbox 360) is Blake Handler.
• The "most amusing" entry goes to Geoff Appleby, for his totally unrelated and entirely improbable (subject to rounding error) decision that my blog title was somehow related to the length of his foot.  Geoff will receive a handsome Windows Vista tumbler.

Congrats!

Sometimes being obtuse is it's own reward, but this time there's something in it for you if you know what "16.7ms" is referring to.  I'm curious enough to see that I'm willing to shell out my own hard-earned cash to the first non-Microsoft employee that figures it out.  Post your guesses to my Comments section, please.

Your choice of:

• Perfect Dark Zero (Xbox 360)
• Kameo (Xbox 360)
• Project Gotham Racing 3 (Xbox 360)
• Age of Empires III Collector's Edition (PC)
• Dungeon Siege 2 (PC)
• Fable The Lost Chapters (PC)

For the person who comes up with the most amusing, albeit incorrect, translation, I'll award a Windows Vista stainless steel tumbler!

...and just like that, we have a silly contest!

Update: We have a winner for the "real" definition (16.7ms == 1/60 second, the time for 1 field of interlaced NTSC/ATSC video), but I'll keep the silly side of it open until tomorrorow (1/6/2006) at 5 PM PST.

Update 2: Entries are now closed, thanks!  I will be considering each and every one based on their merits, feed it through my ultra-advanced HumorSensor 5000, double-check the results with the IOC, and the UN Human Rights Commission, and present the results as soon as is humanly possible.  Or I may just look 'em over and choose the one that makes me laugh.  Either way, I'll let you know...

One of the issues I am investigating for a fix relates to the auto-suspend feature in Windows.  The way it's supposed to work is you set a time in the Power control panel (Control Panel --> Performance and Maintenance --> Power Options) that controls how long the computer waits until it goes into "standby" or "suspend".  Whether that is S2 or S3 depends on your BIOS settings.  What's going on with the bug I'm looking at is sometimes Windows will not suspend when it should, or indeed, ever, unless you close Media Center or manually select Standby.

This is pretty annoying, especially since my Media Center consumes about 200W while fully active (250-275W if engaged in HDTV playback), and only about 15W in S3 suspend.  With electricity around $0.084 / kWh, that works out to $0.40 each day left unchecked.  If I let it go all month, that's another $12, just because of this stupid bug (well, and because I'm lazy and forget to manually suspend... but I should not have to).  Lame, lame, lame.  Extrapolating to all of the customers affected by this issue, I can see it adding up to a big problem.  Say only 250,000 users hit this (a low figure, I bet), that's $3,000,000 per month in wasted energy costs, based on the rates I pay.  Yikes!

While I can fix this problem, I cannot fix all of the things that prevent computers from going into standby automatically, because they should really not be fixed, or because Windows software is not causing the problem in the first place.  Several things can cause a computer to fail to go into standby, and figuring out exactly what is causing the problem can be very difficult.

So, what are the most common causes of Windows insomnia?  In rough order of likelihood, here is my SWAG:

1. There is user activity.  This usually means keyboard or mouse activity, but can be "simulated" by applications via SendKeys(), etc.
2. Windows is not configured to go into Standby automatically.  Since it's not the default for most computers, this makes the list.  Easy to fix.
3. An application tells Windows not to go into Standby automatically.  Different from user activity simulation because this is what applications are supposed to do to prevent Standby. [ SetThreadExecutionState(state) ]
4. An application generates enough system activity (e.g. disk access, network access, CPU usage) that Windows does not consider the machine to be "idle" enough.
5. A hardware device driver prevents it.

Case 1 is very unlikely, since really the only applications that do this sort of thing are hacks/trainers/evil programs (and testing programs, if you want a legitimate example).  Unless your computer is infected by malware, this is probably not the cause.  Run a quality scanner to tell.  For case 2, just set Control Panel setting.

For cases 3 and 4, troubleshooting gets trickier.  For the average end-user who does not know how to use a Kernel Debugger like WinDbg or SoftICE, and does not have easy access to kernel symbols, figuring out who is keeping the computer up all night takes a little wanton process termination. Before you open up taskmgr and start gunning processes, though, there are a couple of things you can check:

• Are you sharing any folders on the network?  If a remote computer is connected to your machine and refreshes the connection (i.e. sends a command), the Server service will call KeInhibitSystemShutdown(), which does exactly what it sounds like it does: resets the system's idle timer.  How do you tell if this is happening? An easy way is to pull up a command window (Start --> Run --> cmd) and type:
  
  nbtstat -s
  
  If you see any "IN" connections, they can keep you awake.  Most well-behaved Windows applications will not needlessly refresh connections over the network, but others don't play that nicely.  A ubiquitous example would be WMP or iTunes--both will scan network folders for changes if you add the path to your "watched folders" list.  The best way to solve this problem is to fix the client side (the other computer), but if that's not possible, you can just deny access to that computer/user.  In the worst case, you can stop the Server service (net stop server), but that prevents sharing altogether.
• Check your Application and System event logs for errors or warnings.  Often, exceptional situations will be reported there and can provide a clue to why Windows is not going into Standby.
• Hardware (or more appropriately, drivers for hardware) can prevent Windows from entering standby, too.  If you used to be able to go into standby, but cannot now, have you added or replaced hardware, or updated drivers?  This can be tricky, too, since most people set their Standby timers for longer than is convenient to sit around and wait on, so failure to go into Standby can be missed for days or weeks.
• To eliminate any remote networking cause, isolate your computer from the network (unplug the network cable!).  Low-tech, but effective.

If you have eliminated network shares, suspicious event log entries, and hardware from causing the problem, the next thing to do is start killing processes and see which one (or if you're unlucky, which ones) are doing it.  You need to first exclude those processes that are part of Windows itself, since terminating them is not very wise.  An easy way to get a fairly complete list of the Windows processes is to boot into Safe Mode, press Start --> Run, and type:

tasklist >"%SystemDrive%\SysProcesses.txt"

A new file will be created on your system drive (usually C:) that contains the list of processes you shouldn't touch.  Reboot back into normal Windows mode, log in, and:

1. Open the SysProcesses.txt file
2. Start taskmgr (right click on the taskbar and select Task Manager) and click the Processes tab.
3. Set your Standby timer to 1 minute (in the Power Options control panel)
4. Let 1 minute elapse.  If the computer does not suspend, proceed to the next step.
5. Select a process not listed in the SysProcesses.txt file in taskmgr and kill it.
6. Go to step 4.

If you run out of processes to kill and the computer still won't go into Standby, it's time to start shutting down services in the Services console (Start --> Run --> services.msc).  If you have stopped all of the services you possibly can, it's either a piece of hardware or one of the core Windows processes, and things are a bit tougher.  To troubleshoot those, you need the help of a kernel-mode debugger.

Happy New Year!

It was a nice month, but the break is over and I've returned back to work.  Christmas at the Rosser house was a low-key affair, mostly spend decompressing from hectic work schedules and enjoying family and friends' company.  My daughter's 2nd Christmas, this year was the year she figured out the whole "presents are fun" thing, and we had a great time.  We scheduled holiday-themed shows on our Media Center, and while they enjoyed the shows I (quietly, to myself) nitpicked the video quality and encoding bugs from my Comcast box.  If you haven't seen them, our current pick-of-the-month show to watch is Creature Comforts on BBC America  I'm told that it's been out quite a long time, but it's new to me.  In case you haven't seen it, it's a Wallace & Grommit -style show where they take real(?) audio interviews of people and animate claymation animals to the soundtrack.  The results are often hilarious, especially if you enjoy British humour.

It will probably be a couple of days before I catch up completely with the backlog of email and so forth, but I'm back on the job.  We've got several DVB Radio and EPG issues under investigation presently, along with a couple of Standby/Resume bugs.  The mood around the halls is pleasant, unlike the frantic activity from deadline pressure in November and December.  A few new faces, a few old faces moved on to other teams, it's business as usual here in eHome.  It's back to work, and back to fixing bugs.

As time permits, I've been working on the next version of MceRepair, but with the real world taking up so much of my extracurricular time it's been a slow row to hoe.

Here's what's in it so far:

• Detects and reports your installation status, including baseline (e.g. Media Center 2005) and installed updates (e.g. KB908250)
• SHA-1 hashes for every MCE 2005+ binary.  This will allow me to zero in on exactly the versions of the binaries that are present on the machine, whether they are corrupted or original, and which KB package they belong to.
• Targeted unregistration and re-registration, which should improve results and execution time.
• DRM subsystem analysis to detect "corrupt" state and suggest resolutions (simple tests to determine whether you can playback certain content).
• Complete rewrite in C++ to remove the .NET dependency.  This is necessary because one of the problems most prevalent with MCE installs seems to be a corrupt .NET installation, so I need a reliable way to detect that and suggest repair options.
• Creates a System Restore Point, if the feature is enabled on the machine

Here are planned features that I have not yet completed:

• Detection of improperly installed MCE Update packages
• Registry filter driver to intercept DllRegisterServer attempts to write to the registry.  This will allow MceRepair to compare the existing registry with what the DLL "wants" it to be without actually making changes, and compare that with a database of "known good" registry entries.
• GAC scrubbing
• EPG data analysis (for corrupt EPG)
• Recorded TV file scrubbing to delete corrupt recordings

I spent a lot of time compiling the baseline data for the application to have something to compare machine configurations against.  Since I cannot trust that the binary wasn't tampered with, I decided to include a strong hash as part of the binary's identity--this required digging up every single QFE shipped by the team and recalculating hashes against them.

As soon as I have the registry filter driver portion complete, I'll be able to use it to calculate the baseline registry information for the binaries, too.  I don't fully trust the update.inf's registry section, since it may assume that the underlying system has a working configuration set (i.e. it may be missing some entries).

Precious...

(sorry for the quality, it's from my camera phone)

UPDATE: "a while" == 1.5 hours (YMMV)

You know I'm a geek when something like that gives me even a little bit of a thrill.  November 7th... not just an election day or my birthday, but also the VS2005 public ship day. ^_^.  I'm installing it now on my primary and backup dev boxes at work now... sometimes the perks of working here are pretty nice. Mmm... generics.

One of my coworkers suggested I take another look at Managed C++ (during our conversation I expressed my "dismay" at the prior version's foibles), so I'll take a peek at that as soon as I have a spare cycle or two.  It's pretty hard to get any free time with the painting at home and the heavy influx of QFE issues we always get post release, but I'm sure I'll manage.

There has been some recent effort to pry open the 1394 interface in various STBs (set-top boxes), most notably that of timmmoore's STB package that goes to extraordinary lengths to hook into Media Center's experience.  The state of the world today, at least with Media Center, is that the "outside looking in" hooks of Tim's package are the only way to get that HD content off of digital cable and into Media Center.

Here's how his package works, in a nutshell.  You install a couple of drivers that provide a software interface to the various commands you might expect to be available from an STB: channel changing, power toggle, etc.  An application then runs in the notification area, or tray, and acts as an intermediary between Media Center and the STB drivers.  When Media Center says "Change channel to 54", MyTray (Tim's tray application) listens in via a "hook" into Media Center and sends the channel-change command to the STB.  When Media Center starts a recording, another hook lets MyTray know that's happened and MyTray sends a "start streaming video over 1394" command to the STB.  When Media Center stops the recording, a similar event happens.

Physically, you connect your computer with the STB by plugging in a IEEE.1394 (Firewire) cable into each.  If you have two STBs, you can daisy-chain them together.  The traditional "IR" blaster for each STB is removed from the receiver so that it does not interfere with the commands sent over the 1394 connection.

There are a couple of significant downsides to doing it this way:

• It's a lot harder to hook in from outside Media Center and try to figure out when channels are changing, recordings are starting or stopping, and in multi-tuner scenarios, which tuner/STB to use than it would be if Media Center could just treat the STB as a virtual tuner.
• You still need an analog tuner for each STB you need to control.  This may seem odd, but it's part of the reason this works.  From Media Center's point of reference, it is still managing all of the recording and channel changing.  The fact that the actual channel change is triggered by another application is unknown and unknowable within Media Center.
• Since Media Center is still recording over the analog tuners, you end up with two copies of the same program.  MyTray can be set to clean up the Media Center version once it knows its recording completed successfully (e.g. no 5C protection from the STB prevented the recording), but you still churn the disk more (2x more for non-HD shows).
• Premium content like HBO is likely protected by the STB by the 5C standard, which MyTray does not support.  Nor can it without obtaining a 5C certificate, which are pretty hard to get.  The sticky parts for most interested parties are the unlimited liability clause you have to sign, and the certification process itself, which I hear is stringent.
• MyTray is the product of a single developer, and one person alone cannot bring to bear the necessary development, testing, and packaging resources that bring a high polish to a product.  A common saying that applies here is "90% of the work is in the last 10% of the project".  Tim did a great job and some impressive detective work getting the app where it is, but getting that "shipping product" quality is a hard job to do all by yourself, working in your spare time.

I am personally using this at home right now, despite the downsides.  The fact that I am willing to do this probably means I'm not alone, and in the few informal hallway conversations I've had about it there's a lot of interest in getting this sort of thing done natively in Media Center.  There's not matching excitement about funding the cost of doing it, but there seldom is, when it comes down to it.

As Media Center becomes the default SKU for OEMs shipping Windows and our user base grows, there is a tremendous downward pressure on the unit cost of the machines.  The first target for downsizing seems to be the tuners, since a fair number of those new Media Centers are being sold as "Tuner Ready" instead of "Tuners Inside".   In my humble opinion, implementing a 1394 recording solution is the single best way to get broad market appeal while keeping hardware costs low.  Everybody wins: we sell our Windows licenses, OEMs move more units, customers get reliable, scalable SD & HD recording, and the cable companies get their $10 a month from renting their STBs.

Consumers are used to paying the fee, and I think they would continue to do so.  There's been a market for leasing otherwise expensive equipment for many years, and there's no reason to think that will change soon.  When faced with a decision between $10 a month (or $20 for two STBs), or buying a $250 tuner (or two), a lot of people go for the monthly fee.  After all, it takes over 2 years to amortize that, and with technology that seems like a good bet to me.  Being on the bleeding edge is more comfortable if you can stay there on a lease. ^_^

Which brings me to the true point of my post: I want to hear how much this feature is wanted in the user community.  Is it only wanted by the technically savvy, or do "average" users want it?  I really want it, and I don't want this relegated to the "power user" or "enthusiast" bin, because that will result in, at most, a power toy implementation.  If we can bring a full feature team to bear on this, I bet we could really make our users happy.

Just think, you could have everything Media Center gives you, plus VOD support (including Pay-Per-View, integrated into Media Center), and HDTV over digital cable.  If I'm not mistaken, this could easily expand into satellite STBs, too, if they don't already support streaming over 1394.

I'm going to get back to tinkering with the Network Provider and 1394 tuner classdriver code some more... I'm all worked up with excitement now. ^_^

Symptoms

Aaron Stebner blogged this a few days ago, but some folks are still running into it, so I'll speak to it a bit.  If you get an error dialog with the message "The procedure entry point GetRequestedRuntimeVersion could not be located in the dynamic link library mscoree.dll" during Media Center updates or while running MceRepair, you have (most likely) gotten a corrupt .NET Framework 1.1 installation. 

Solution

The fix is to reinstall the Framework from: http://www.microsoft.com/downloads/details.aspx?FamilyId=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en

Root Cause

The most likely cause for this issue is a "clean" reinstall of Windows into the same directory without formatting the disk first.  Since the .NET Framework 1.0 is included with Windows XP Media Center Edition, the 1.0 version of mscoree.dll is saved into the Windows directory, overwriting any version (e.g. the 1.1 version) already there.  Since the Windows registry is stored in a file that is not completely overwritten during the install, most of the v1.1 entries are left behind, making the .NET Framework v1.1 almost work.  Compounding the problem, there are reports that v1.1 is not offered on Windows Update, because the update logic looks for the registry entries that tell it whether it's installed already, and gets fooled.

I've posted an update to MceRepair at http://www.pegasi.com/MceRepair_0.2.zip, which adds additional error logging in case of problems.  If you tried 0.1 and it failed, 0.2 may work for you.  If not, at least you will have more complete information with which I can debug it. [;)] 

To clarify the somewhat vague statement I made about "business rules" for DRM changing in Emerald (Rollup 2), the changes were to include the new COPP (Certified Output Protection Protocol) support in the release and to support the new version of the DRM engine.  The actual behavioral changes in Media Center are not that great: we included the new "CopyNoMore" setting (previously "Reserved" in the CGMS-A standard) in our matrix of when to apply COPP, and were the "ship vehicle" for the new version of DRM from the DRM team. 

Whether we even engage DRM at all is governed by those "business rules" I was talking about; it's a matrix that defines which protection level we apply to the recorded content based on multiple input vectors.  The entire response matrix is quite large, and defines things like whether you can create a recording¹, whether DRM encryption is applied², whether we permit recording the content to portable media, and whether to allow presenting the video over an given output³.  In a nutshell, DRM protection/encryption is only triggered in existing analog scenarios when the input content is protected by a) CGMS-A, b) PAL's Copy Protection Flag, or c) Macrovision.  Realistically, you're only going to see Macrovision if you are doing pass-through from a VCR or DVD player, or you live in Korea and get your TV from a certain satellite service. 

I've only personally seen CGMS-A broadcast on HBO & Cinemax, Showtime, and other "premium" channels.  VOD channels are usually marked CopyNever, while scheduled premium channels generally have CopyOnce tags.  I hear via forum postings that some people are seeing Fox News' "The O'Reilly Factor" getting marked as Copy Protected in Media Center, but I haven't witnessed it myself.  There's certainly nothing stopping broadcasters from setting the 2-bit attribute in their VBI data.

¹ - true for everything but CopyNever content
² - true for everything but CopyFree (or no CGMS-A at all) and no Macrovision
³ - governed by COPP

After all that about QWORDs in the registry from managed code, I went ahead and just finished a small application that allows you to edit the time that MCE goes out to download guide updates.

You can get from http://www.pegasi.com/MceDlTimeEditor_0.1.zip

From time to time you need to use really, really big numbers, like when describing, say, the time of day you need to download a certain set of data from remote servers.  Well, you probably don't need that much granularity in the time, but that's what MCE uses to schedule EPG downloads. <g>

So, we store this thing off in the registry at in a value named dlRegTime.  I can see why the dev did this: it's easy to convert a DateTime to an Int64 by way of DateTime.ToFileTime(), which makes for a clean, unambiguous value to write.  I'd almost bet that he was patting himself on the back... until he had to actually write the value to the registry.

The problem comes when you need that value from C# (or, I guess, VB.NET).  The 1.1 Framework designers apparently did not think that anyone could ever possibly need a 64-bit value from the registry, and if they did, they could P/Invoke.  That's exactly what you have to do.  Here's an example where I convert the FILETIME stored as a QWORD into a DateTime:

[DllImport("Advapi32.dll")]
static extern uint RegOpenKeyEx(UIntPtr hKey,
    string lpSubKey,
    uint ulOptions,
    int samDesired,
    out IntPtr phkResult);

[DllImport("Advapi32.dll", EntryPoint="RegQueryValueEx")]
static extern uint RegQueryValueEx_QWORD(
    IntPtr hKey,
    string lpValueName,
    uint lpReserved,
    ref uint lpType,
    ref long lpData,
    ref int lpcbData
    );

[DllImport("Advapi32.dll")]
static extern uint RegCloseKey(IntPtr hKey);

const int KEY_QUERY_VALUE = 0x1;
const string EPG_REGKEY = 
    @"SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Service\EPG";
const string DLTIME_REGVALUE = "dlRegTime";

DateTime GetNextDownloadTime()
{
    UIntPtr HKEY_LOCAL_MACHINE = (UIntPtr)0x80000002;
    IntPtr hkey = IntPtr.Zero;
    DateTime date = DateTime.MinValue;

    try
    {
        uint lResult = RegOpenKeyEx(
            HKEY_LOCAL_MACHINE, 
            EPG_REGKEY,
            0, KEY_QUERY_VALUE, out hkey);

        if (0 == lResult)
        {
            long qword = 0;
            uint uType = 0;
            int cbData = 8;
            
            lResult = RegQueryValueEx_QWORD(hkey, 
                                            "dlRegTime", 
                                            0, 
                                            ref uType, 
                                            ref qword, 
                                            ref cbData);

            date = DateTime.FromFileTime(qword);
        }
        else
        {
            throw new ApplicationException("The registry key " + 
                EPG_REGKEY + 
                " could not be opened for reading.  The error code was 0x" + 
                lResult.ToString("x"));
        }
    }
    finally
    {
        if (IntPtr.Zero != hkey)
        {
            RegCloseKey(hkey);
        }
    }

    return date;
}

I was posting to TheGreenButton.com and thought I'd save myself typing the same thing again, since it's good info, even if I am restating/repackaging existing opinion.  The following is a response to people who thought for some reason that Rollup 2 was applying DRM to things that it did not before:

Rollup 2 did not substansively change the way that we determine whether something should be copy protected or not; what it did was change some of the infrastructure of the underlying protection scheme.  Basically we revved the DRM version and refined some of the business rules that determine what level of DRM a piece of content gets.

Whether something is protected by DRM depends on whether the broadcaster sends us CGMS/A (Copy Generation Management System / Analog) flags on Line21 of the analog signal.  This is *not* the (in)famous "broadcast flag".  If you want to know more about how CGMS/A works, there is plenty of material on the net.  Another factor is Macrovision (software and/or hardware), or in Europe, the CP flag.

CGMS/A can set 4 different modes: CopyFreely (i.e. no protection), CopyOnce, CopyNoMore (i.e. it used to be CopyOnce, but you made a copy... so you don't get to copy it again), and CopyNever (no copies at all).  Since our whole business is built around timeshifting content, we don't count the one stored version as a copy at all, though in CopyNever circumstances the license is generally good for only a limited time.

<soapbox>

I'm not a big fan of DRM, but I do see the business need for it.  Microsoft makes a big, inviting target for lawsuits if we even appear to be soft on protecting copy protected content.  That doesn't make me happy, since it attempts to restrict what I can do with "my" content, and no matter how much I am told (and cerebrally understand) that it's not mine at all, but I'm just licensed to view it, I still persist in thinking of it as "mine".  After all, I paid for it!  As a consumer, I want complete freedom in what I do with my content.  As a stockholder in Microsoft, I want to both protect from lawsuits and grow the consumer market, which seem to be opposing goals.

So what we have is a compromise: DRM.  We have encryption technology strong enough to make it not worth cracking (by the time you have cracked it, you've spent more than it would have cost to just go out and buy another copy of the content... probably many hundred/thousand/million times).  With the technology also comes the ability for us to open up windows to use the content in limited ways... hopefully the ways that consumers really want to use it.  Of course, you can't just send copies around to everyone.  But you CAN (or should, if it's working right) put the content on a portable device.  Or make a DVD backup.

There's more to this than most people realize, though.  Not only do companies like Microsoft and Apple have to guard against lawsuits, etc., but they have to make the studios and other content producers happy enough with the DRM solutions that they will go *farther* and give us more content in more flexible ways.  Do you think that Comcast, DirecTV or EchoStar would agree to attach a digital tuner to a PC that can decode their signal without an ironclad guarantee that the content would not just end up on the net?  They are terrified of that prospect... and with (arguably) good reason.  DRM is what we need to open up PC-based solutions for all of our content.  I don't want to pirate my Comcast Digital Cable feed... but I *do* want to watch it!  In high-definition and on my Media Center.  If the DRM gets out of my way, and lets me burn a DVD for my collection (hard drives are finite, after all), then I'm game.  I don't care if I can't just post a video of some HBO movie on the internet.  I don't really have the inclination anyhow.

I know there are a lot of folks out there who vociferously oppose DRM on principal.  The "information should be free" crowd argues on the principal that you cannot own information, and content is just information.  That isn't reality, though, and the courts and laws agree that people who create content can sell it.  I won't pontificate further on that, but leave with a parting piece of information relating to the prior paragraph: if the "no DRM" crowd wins, we won't have lots of content with no DRM suddenly... what we'll have is broadcasters and content creators that won't have any reason to share their content.  Hollywood will release it's next generation of DVD replacements, this time with something less laughable than CSS protection, and that'll be it.  No PC viewing of digital content, just analog.  Depressing to me...

</soapbox>

This is just my opinion... I'm not a policy setter, and not on any DRM or Copy Protection team.  Fill in all the other disclaimers about my opinion not being my employer's, and all that. ;)