Does or DID Win32 CopyFile(W) ever raise a (SEH) exception?

The Windows API CopyFile function is rather straightforward:

BOOL CopyFileW(
  [in] LPCWSTR lpExistingFileName,
  [in] LPCWSTR lpNewFileName,
  [in] BOOL    bFailIfExists
);

...

If the function fails, the return value is zero. To get extended error information, call GetLastError.

However, I found this gem in our C++ source code, dating back to Oct / 2006:

try {       //Exception, if the file already exists and is write protected
    bCopyOK = CopyFile(csSourceFile, csDestinationFile, bFailIfExists);
} catch (...) { 
    bCopyOK = FALSE;
}

I even found the old ticket title (of course without details): "function 'CopyFile' throws Exception if Destination is write protected, catch Exception" :-)

Even today we still compile with /EHa, so this would have caught any SEH exceptions raised.

Now, at this point in time we would've been using Visual Studio 6 on Windows XP, and that one had all kinds of quirks, but still: I have a hard time imagining this function ever raising an exception (apart from invalid/null parameters and such).

// Self answer, with historical perspective.

It is not documented to throw exceptions, as is apparent from the current docs linked above.

Both the other answer and also, e.g. Do DeleteFile() Or CopyFile() throw exceptions? quite definitely assert that there should be no exception being raised.

However, as is mentioned in comments:

Very few API calls are documented to raise SEH exceptions, but that doesn't mean that they won't, or prevent SEH exceptions raised in foreign code from passing through.

and in the linked question:

comment: ... Some odds that getting rid of the installed anti-malware product can rescue it, ymmv. ...

A: It was ... corporate info safety system, anti-malware like product.

It is very well possible that the original developer could actually reproduce this behavior on his machine, and swallowing the error "fixed" it well enough back then.

Things have improved since then. Given that no reproduction is possible in current code, and given that this only works with /EHa anyways, the try-catch is a candidate for cleanup.