How best to deal with mscomm32.ocx "8020" issue?

NTDEV
1

So, I’m now facing the issue in mscomm32.ocx as described in:

http://support.microsoft.com/default.aspx?scid=kb;en-us;318784

…where the control doesn’t expect ERROR_IO_PENDING when there are bytes to read synchronously from my driver – KMDF has already pended the request by the time it gets to my read queue.

As I understand it, these are my options (or non-options):

  1. Use WdfDeviceInitAssignWdmIrpPreprocessCallback() and potentially have to convert my entire read handler to WDM, or at least part of it.

  2. I can’t use WdfDeviceInitSetIoInCallerContextCallback() because the IRP has already been pended by this point.

  3. Is there a way to just get a newer or bug-free version of mscomm32.ocx? The version affected seems to be from VB6 – does anyone know if the one in .NET 2003 or 2005 still has this issue?

2

I wrote:

  1. Use WdfDeviceInitAssignWdmIrpPreprocessCallback() and
    potentially have to convert my entire read handler to WDM, or
    at least part of it.

Let me ask one question specifically: the help page on WdfDeviceInitAssignWdmIrpPreprocessCallback() says that I can only use this function two ways:

  1. To handle WDM IRPs that are not handled by the framework at all.

  2. To touch WDM IRPs before handing them off to KMDF.

It doesn’t specifically say that I can take an IRP that’s normally handled by KMDF (IRP_MJ_READ) and then complete it without passing it to KMDF. This is similar to case #2, but not exactly.

So is it okay if I call IoCompleteIrp() on an IRP_MJ_READ in EvtDeviceWdmIrpPreprocess() and return STATUS_SUCCESS, even though I never dispatched the IRP to KMDF?

3

> So is it okay if I call IoCompleteIrp() on an IRP_MJ_READ

in EvtDeviceWdmIrpPreprocess() and return STATUS_SUCCESS,
even though I never dispatched the IRP to KMDF?

(Apparently yes.)