Current version

v1.10.4 (stable)


Main page
Archived news
Plugin SDK
Knowledge base
Contact info
Other projects


Blog Archive

Interesting bug in Windows XP 64-bit Edition

For those of us who run the AMD64 (x64) version of Windows XP 64-Bit Edition, the current build, build 1218, is a bit tricky to install. It's required to run Visual Studio .NET 2005, since the previous build 1184 was too old, but it has a tendency to blue-screen on startup until you trawl the newsgroups and find the hint to change the power management setting to Minimal Power Management. After that it mostly works, as long as you don't try to use Windows Media Player.

Anyway, I was doing some checks on the AMD64 build of VirtualDub 1.6.2, only to discover an annoying problem: the capture module wasn't capturing properly. In fact, the timing module was dropping an alarming amount of frames and was seeing the system clock run at half speed. I launched the 32-bit version to cross-check and sure enough, it too was seeing the clock run at half-rate. Doh! What the heck was going on...?

I tracked the culprit to QueryPerformanceCounter() returning goofy timings. This function is supposed to return a value that corresponds to a stable clock, whose frequency is given by QueryPerformanceFrequency() and whose rate is independent of CPU frequency changes. When I tried to test it at first in a console app QPC() was returning normal values, but then I noticed that:

I then realized what was going on. The capture test I was doing wasn't using more than 10% of the CPU, so the CPU was throttling to a lower speed -- and since QPC() was using CPU ticks, the tick counts returned were rising slower than they should have been according to QPF(). My test app took 100% of the CPU, so it forced the CPU clock back to full rate and eliminated the discrepancy. The obvious solution was thus to make VirtualDub's capture module always take 100% of the CPU.


VirtualDub only uses the high-performance timer in the capture module for the DirectShow and emulation drivers, so you're not likely to hit this given that there are no capture drivers that I know of for 64-bit Windows. However, I can imagine that this might cause other programs to act erratically, so if you think programs are running too slowly for this reason, changing the power management setting to Always On seems to fix it. This disables CPU throttling. Remember that if you pick a power mode that causes your system to blue-screen, you can reboot to safe mode to change it back.


This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.