Why would fopen fail to open a file that exists?

问题

I'm on Windows XP using Visual Studio 6 (yes I know it's old) building/maintaining a C++ DLL. I'm encountered a problem with fopen failing to open an existing file, it always returns NULL.

I've tried:

Checking errno and _doserrno by setting both to zero and then checking them again, both remain zero, and thus GetLastError() reports no errors. I know fopen isn't required to set errno when it encounters an error according to a C standard.
Hardcoding the file path, which are not relative.
Tried on another developers machine which the same result.

The really strange thing is CreateFile works and the file can be read with ReadFile. We believe this works in a release build, however we are also seeing some very odd behaviour in other areas of the application and we're not sure if this is related.

The code is below, I don't see anything odd it looks quite standard to me. The source file hasn't changed for just under half a year.

HRESULT CDataHandler::LoadFile( CStdString szFilePath )
{
    //Code
    FILE* pFile;
    if ( NULL == ( pFile = fopen( szFilePath.c_str(), "rb") ) )
    {
        return S_FALSE;
    }
    //More code
}

回答1:

The Answer:

I found the cause, too many open file handles cause by some recent updates to the application. These where not code changes though so this bug has been present for a while. I stepped into the fopen function down to a function called _getstream. This attempts to find a stream not in use, the function searches a table of 512 streams Sure enough all 512 where in use and other calls to fopen where failing. I used the handle tool from sysinternals to see the number of used handles.

回答2:

Your function has an HRESULT return type (where 0 is good) but you return a boolean (where 0 is bad). That can't be right...

回答3:

Assuming you have a reasonable version of VC6, then you have the source code to the CRT, and you can step into the fopen call, and all the way down to the CreateFile call that the CRT will make. (Be prepared for it to be quite a long way down!)

回答4:

put breakpoint on fopen line, trigger it in debugger, input "ERR, hr" in "Watch" window, execute the line and check in Watch what was the problem. Most probably it's access permissions.