Different asynchronous WriteFile behavior between MATLAB 2012a and MATLAB 2014b

I am doing asynchronous Serial I/O using a MEX function created using Microsoft Windows SDK 7.1 (C++) on 64bit Windows 7 machine, a .cpp function with the following lines:

 Success = WriteFile(hCom, cbuf, BytesToWrite, NULL, &oW);  // Overlapped

    if(!Successful) {

        DWORD Error = GetLastError();
                    if( Error == ERROR_IO_PENDING ){

I ran this code on MATLAB 2012, 2014 and 2015.

When I try to write, WriteFile (Success) always returns 0. But then, DWORD Error when running in MATLAB2012 returns:

ERROR_IO_PENDING
997 (0x3E5)
Overlapped I/O operation is in progress.

Which means the operation is a success.

But DWORD Error in MATLAB 2014 or 2015 returns fail as well.

I can't get WriteFile to work on MATLAB 2014 or 2015 (I tried both). Reading from the serial port is no problem ,just problem with WriteFile.

I am thinking it is some sort of issue with the Microsoft Windows SDK 7.1 (C++), and probably older versions of Matlab (2012 or earlier) might work.

[Guillaume]

WriteFile is part of the Windows API. It has nothing to do with matlab.

You don't say what the error is in your second case, but whatever it is it's not because of the version of matlab. Possibly, you're not passing the same inputs to WriteFile.

[JMP Phillips]

In Matlab 2012, the return of GetLastError() is ERROR_IO_PENDING 997 (0x3E5) (which is a success, not really an error) , in Matlab 2014 the return of GetLastError() is not ERROR_IO_PENDING (which is a fail). I'm creating a mex file of the same .cpp code with same inputs for both versions of Matlab and both versions give different (unexplainable) behavior.

[Guillaume]

It'll be more useful if you'd tell us what the error is rather than what it is not. That probably would go a long way to understanding what is different about the two setups.

[JMP Phillips]

In Matlab 2012, the return of GetLastError() is ERROR_IO_PENDING 997 (0x3E5)

In Matlab 2014 the return of GetLastError() is ERROR_SUCCESS 0 (0x0) The operation completed successfully.

If I call GetLastError() immediately after WriteFile, same result. I guess I need to know how Matlab 2014 interacts with the WIN API differently to Matlab 2012.

The synchronous I/O works fine, just this issue with asynchronous I/O in Matlab 2014.

[Guillaume]

To me, its sounds that in the second case, the call completed successfully but synchronously.

There's an MSDN knowledge base article kb 156932 that explains potential reasons for why asynchronous calls can be completed synchronously.

Once again, I don't think it has anything to do with matlab, since matlab is not involved in WriteFile.

[JMP Phillips]

Both versions of MATLAB are calling the same WriteFile function (from the same mex file). This being the case, I would think the difference in behavior is likely due to MATLAB, not WriteFile.

Also, I doubt that it is completing synchronously because I observe no flashing lights on the modem I am using when I run the code, that indicates when data is being transmitted over the modem.

Anyway thanks for trying to help, it gave me some things to think about, I will look for another solution.

[Guillaume]

No, matlab is not calling WriteFile, your mex file is. At this point, matlab is not involved anymore. So if there is a difference in behaviour, it's because the inputs are different, or the environment is different (OS, filesystem state), or the mex files are compiled differently.

[JMP Phillips]

That's not strictly true. MEX-files use MATLAB runtime libraries (see http://au.mathworks.com/help/matlab/matlab_external/version-compatibility.html).

In my case the only point of difference is the MATLAB version which is calling the mex file, everything else is identical including the mex file which I compiled on one version only. And it is not an issue of which MATLAB version I compiled it on, as I have already tested compiling and running on the same and different MATLAB versions. I believe it could be a MATLAB runtime library issue.

[Walter Roberson]

Given the API, it is an error for your code to require that the operation not happen synchronously. It may be unexpected, but it is permitted for the operating system to return synchronously for any reason it feels like, including the possibility that every 47th bit in the executable happens to match the sound file representation of "Anchors Away!".