Take the 2-minute tour ×

The Problem

I am hunting down a bug in a web application related to multi-uploads using a Flash movie/applet. Sometimes, the progress bar that is used in the Flash applet to indicate file upload progress will read over 100% for a progress and causes the entire upload system to halt.

Aside from the logic errors associated with the rest of that code, attempting to reproduce this bug to trace execution and debug is a feat in itself. It's a Heisenbug, and I have seen it just once in about two days of trying. Other developers' machines can reproduce it with more regularity.

The only time I reproduced it was rebooting after changing my registry key for SystemResponsiveness, as my machine uses Windows Server 2008 R2. That registry key controls CPU priority for multimedia applications. Windows Server 2008 R2 sets this key to 100 (giving multimedia applications very low priority), whereas I set mine to 20 as it is what a desktop Windows 7 install sets it to. All other developer machines that can reproduce this issue have SystemResponsiveness set to a default 100.

When I set my SystemResponsiveness back to 100, I immediately saw this issue. However, reproducing the issue is still spotty.

My Theory

So I am going on the assumption that this bug, as it involves Flash, is related to the SystemResponsiveness registry key as described in Microsoft's documentation for Multimedia Class Scheduler Service, which is the multimedia subsystem of Windows 7 and Windows 2008 R2.

By setting the responsiveness to 100, multimedia like Flash 'movies' (which this uploader is) may encounter problems, and this becomes a timing/interruption issue for the uploader, which then causes other bugs to manifest themselves.

How to test?

Now I'm trying to come up with a way to test this theory. I think I need to have a background process peg the CPU usage at 100% (across 4 cores), and then attempt to use the uploader. The background/non-multimedia services should cause stuff like Flash to perform worse and I should run into problems.


I decided to run a CPU stress test to peg my system's CPU utilization at 100% - other than make my machine slow to a crawl, the bug did not manifest itself. This Heisenbug is really eluding reproduction.

My Inquiry

However, I'm not sure if that is the correct approach to test my theory, so I'm wondering if anyone has any insight into tracking down MMCSS-related issues?

share|improve this question

1 Answer 1

This definitely sounds like a race condition, and those are really hard to force to happen consistently. It may be very difficult to find a scenario that consistently reproduces the issue, because there are some many variables involved.

Maxing out the CPU was a good first shot. The next thing I would try would be to put some load on the disk. Since this is a file uploader, it may be an I/O issue instead of a pure CPU issue.

If that doesn't work, then I'd become really good friends with someone that can make this happen often, if not consistently. Measure the probability that it'll happen on that person's system before making any changes. Then see if your changes have any affect on the probability.

Might be best to take the time to write a script to walk through this for you. You're likely going to be repeating those steps a lot.

share|improve this answer
It sounds like a racecondition to me too. How I traced down a few of those bugs is to literally add a lot of logging to the application, like on every line. The make a smart parser that finds out loglines that are "out of order". –  Pieter B Jul 12 '13 at 11:20

Your Answer


