KMDF 1.5 Vista RTM 6000 XPx64 IRQ Level Boost @ 100 CPU utilizatio

With XP the dispatch of DeviceIoControl from default device queue WDFQUEUE
functions correctly. With XPx64 when a user mode thread is at realtime
thread priority, and is issuing IOCTL's to the KMDF framework there is a
delay associated with the user mode thread recieving the frames from a video
capture pci device operating at a meager ~16 m.s. rate. I do not understand
why the design functions correctly under XP and not XPx64. Basically the
default deviceiocontrol callback inserts the request in a manual queue via
WdfRequestForwardToIoQueue and then makes and attemp to start a dma operation
by dequeue from manual, spinlock some hardware registers, and then execute
the dma transaction via KMDF dma methodologies. The Request is completed
later when the dma is completed. However if I define a WDM preprocess
callback an raise the IRQ level the design works the same as it does under
XP. WHY??

This is the magic which makes the XPx64 build of the exact same source which
works fine under XP.

NTSTATUS
SeWdmDeviceCntrlPreprocessCallback(
IN WDFDEVICE Device,
IN PIRP Irp
)
{
NTSTATUS status = STATUS_SUCCESS;

IoSkipCurrentIrpStackLocation(Irp);

KIRQL OldIrql = KeRaiseIrqlToDpcLevel();

status = WdfDeviceWdmDispatchPreprocessedIrp(Device, Irp);

KeLowerIrql( OldIrql );
return status;
}

The problem occurs when the CPU load is at 100%. The thread issueing the
IOCTL's is elivated to realtime.

 

did you set a sync scope or execution level?

 

Yes, I have tried every possible combination of the execution level and
synchronization scope. Why would there be any difference from XP? I worked
around this problem in the last project by altering the design for our DMA
based device. Now I am working on a new driver for XPx64 and wanted to see
if anyone had any ideas because this device will "require" IOCTL and
Read/Write based usage. Thus until I can resolve this issue I guess the WDM
will be required. I really wanted to develop this new driver with the KMDF
framework. I wanted to build the previous driver with the WDK 6001 RTM
Server 2008 product and see if this issue simply disapeared? but they need
this new drive in a month, and I do not believe I can wait until the Server
2008 WDK appears once again. First they said mid March, then Mid April and
still it is not avaiable.