COM Control Call From .Net Frequently Blocking For 15ms?

I have an ActiveX/COM control written in C++/MFC which processes video (ie. 30 frames per second => about 33ms per frame processing budget) Various rendering aspects of the control can be modified using Set calls on the control, which clients can issue at any time.It turns out that someone (Windows scheduler, .Net interop wrappers, MFC call dispatcher, memory allocator, garbage disposal ?) is quite frequently eating an incredibly long 15.625ms to make or return from the call into the control. Thats half my per-frame budget eaten by some gremlins in the runtime !

The control itself is - for historical reasons - written in C++/MFC. The problem happens when the control is called from C# as well as VB.Net. It happens on very different hardware (an HP Pavilion 2.8Ghz Pentium D, a Macbook Pro with 2.5 Ghz Intel Core 2 Duo running Parallels VM). Just how often this mystery hiccup of 15.625ms occurs differs between machines, but when it does, it is always 15.625ms exactly. Strange.

I have made a rather minimal test case that strips out all the video processing etc.First, I created an MFC/COM Control project in the Project Wizard of Visual Studio 2003 and left things at their default settings (Apartment threading etc.). Then I added a single user defined call TestCall() to the control which does nothing (manually since there is no more classwizard)

Then I created a VB Client program which instantiates the control. It endlessly calls the TestTiming() sub which times how long a single call into the control takes and prints out that time.The TestTiming call basically just does this:

Code: startTime = DateTime.Now Dim h = AxTestControl1.TestCall() endTime = DateTime.Now Dim ms As integer = endTime.Subtract(startTime).TotalMilliseconds

I print out calls that take 0 ms (well something less than 1ms anyway) as "." and for calls > 0ms I print out the actual ms. The output looks something like this:.15.625 ms.........15.625 ms.........15.625 ms.........15.625 ms..........15.625 ms..........15.625 ms...........15.625 ms..........15.625 ms..........15.625 ms

So some variable nr of calls that execute quickly, as desired, and then a "hiccup" call that always takes the exact same amount of time (15.625ms), then some more quick calls.If instead of the user defined control function .TestCall() inside the timing I use a standard control property, like

Code:Dim h = AxTestControl1.Heightor a built in control method like
Code:Dim h = AxTestControl1.ToString()Then I never, ever get a hiccup call.

On different machines you will get a different average number of "." before a hiccup but even then the hiccup is 15.625ms I should mention that the sample code spins off a background thread and calls the TimingTest from its ThreadTask(). This is the way the bug was originally reported to me. However, I can put the

Code:Do TimingTest()Loop

right in the main UI thread - as the first thing in Form1_Load() for example. And it will exhibit the same behaviour, except there will be substantially more good=0ms="." calls on average between the inevitable hiccups.

[code]....