CloseCom() causing general protection fault?

[dbentley]

If you try to close a com port that still has data in the output (or input) buffer will it cause a general protection fault?  From what I'm seeing in my debug steps that appears to be the case.

I'm calling functions from a DLL that use a com port.  At the end of the program I call my UnInitLibrary function that closes the port.  I realized that I wasn't giving enough time between the last time I called ComWrt() and CloseCom() to let all of the data in the queue be sent before closing the port.  If I add a delay between the last ComWrt() and CloseCom() that is sufficiently long for the output queue to all be sent I don't seem to ever get a general protection fault; but if there is no delay I usually do get one - but not always.  This has led me to believe that calling CloseCom() while there is still data in the output queue will cause a general protection fault but I'd like to hear confirmation of that before I consider the issue closed.  I searched through the LabWindows Help some but didn't find anything that talked about this.

Thanks,
Devin

[Mert_A.]

I believe you are describing a known bug that was introduced in version 8.1.0 which also exists in version 8.1.1.  It was only discovered after 8.1.1 was released, so there is no documentation of the issue other than a few other forum posts.

The nature of the issue is this: if your port uses CVI's intermediary output queue (i.e. port was opened with OpenCom, or OpenComConfig was passed a non-negative output queue size), flushing the output queue while there is still data actively being written can cause a GPF.  I believe closing the port is also internally flushing the queue and producing the same result.

As you discovered, adding a delay to ensure the internal output queue is empty before closing the port will avoid the problem.  Also, opening your port with OpenComConfig and passing -1 as the output queue length will also avoid the GPF.

Sorry for your trouble. The bug is fixed in the next release of CVI.

Mert A.
National Instruments

[dbentley]

Thank you!