FindNextFile fails on 64-bit Windows?

Question

Hello,

using C++Builder 2007, the FindFirstFile and FindNextFile functions doesn't seem to be able to find some files on 64-bit versions of Vista and XP. My test application is 32-bit.

If I use them to iterate through the folder C:\Windows\System32\Drivers they only find a handful of files although there are 185 when I issue a dir command in a command prompt. Using the same example code lists all files fine on a 32-bit version of XP.

Here is a small example program:

int main(int argc, char* argv[])
{
  HANDLE hFind;
  WIN32_FIND_DATA FindData;
  int ErrorCode;
  bool cont = true;

  cout << "FindFirst/Next demo." << endl << endl;

  hFind = FindFirstFile("*.*", &FindData);
  if(hFind == INVALID_HANDLE_VALUE)
  {
    ErrorCode = GetLastError();
    if (ErrorCode == ERROR_FILE_NOT_FOUND)
    {
      cout << "There are no files matching that path/mask\n" << endl;
    }
    else
    {
      cout << "FindFirstFile() returned error code " << ErrorCode << endl;
    }
    cont = false;
  }
  else
  {
    cout << FindData.cFileName << endl;
  }

  if (cont)
  {
    while (FindNextFile(hFind, &FindData))
    {
      cout << FindData.cFileName << endl;
    }

    ErrorCode = GetLastError();
    if (ErrorCode == ERROR_NO_MORE_FILES)
    {
      cout << endl << "All files logged." << endl;
    }
    else
    {
      cout << "FindNextFile() returned error code " << ErrorCode << endl;
    }

    if (!FindClose(hFind))
    {
      ErrorCode = GetLastError();
      cout << "FindClose() returned error code " << ErrorCode << endl;
    }
  }
  return 0;
}

Running it in the C:\Windows\System32\Drivers folder on 64-bit XP returns this:

C:\WINDOWS\system32\drivers>t:\Project1.exe
FindFirst/Next demo.

.
..
AsIO.sys
ASUSHWIO.SYS
hfile.txt
raspti.zip
stcp2v30.sys
truecrypt.sys

All files logged.

A dir command on the same system returns this:

C:\WINDOWS\system32\drivers>dir/p
 Volume in drive C has no label.
 Volume Serial Number is E8E1-0F1E

 Directory of C:\WINDOWS\system32\drivers

16-09-2008  23:12    <DIR>          .
16-09-2008  23:12    <DIR>          ..
17-02-2007  00:02            80.384 1394bus.sys
16-09-2008  23:12             9.453 a.txt
17-02-2007  00:02           322.560 acpi.sys
29-03-2006  14:00            18.432 acpiec.sys
24-03-2005  17:11           188.928 aec.sys
21-06-2008  15:07           291.840 afd.sys
29-03-2006  14:00            51.712 amdk8.sys
17-02-2007  00:03           111.104 arp1394.sys
08-05-2006  20:19             8.192 ASACPI.sys
29-03-2006  14:00            25.088 asyncmac.sys
17-02-2007  00:03           150.016 atapi.sys
17-02-2007  00:03           106.496 atmarpc.sys
29-03-2006  14:00            57.344 atmepvc.sys
17-02-2007  00:03            91.648 atmlane.sys
17-02-2007  00:03           569.856 atmuni.sys
24-03-2005  19:12             5.632 audstub.sys
29-03-2006  14:00             6.144 beep.sys
Press any key to continue . . .
etc.

I'm puzzled. What is the reason for this?

Brian

Answer 1

Are you sure it is looking in the same directory as the dir command? They don't seem to have any files in common.

Also, this isn't the issue, but the correct wild card for "all files" is *

*.* means "all files with at least one . in the name"

Answer 2

Is there redirection going on? See the remarks on Wow64DisableWow64FsRedirection http://msdn.microsoft.com/en-gb/library/aa365743.aspx

Answer 3

I am 100% sure it is the same directory, I didn't include all 185 files in the last listing, hence the "etc." after the last files.

Answer 4

Ludvig, as stated in the first paragraph, the test application is 32-bit.

Answer 5

Are there any warnings when you compile?

Have you turned ALL warnings on for this particular test (since it is not working)?

Make sure first to solve the warnings.

Answer 6

There are no problems with the example code. I have another application that fails too, written in Delphi. I think I found the answer based on Kris' answer about redirection: http://msdn.microsoft.com/en-gb/library/aa364418(VS.85).aspx

Answer 7

I found this on MSDN:

If you are writing a 32-bit application to list all the files in a directory and the application may be run on a 64-bit computer, you should call the Wow64DisableWow64FsRedirectionfunction before calling FindFirstFile and call Wow64RevertWow64FsRedirection after the last call to FindNextFile. For more information, see File System Redirector.

Here's the link

I'll have to update my code because of this :-)

Answer 8

Got it:

http://msdn.microsoft.com/en-gb/library/aa384187(VS.85).aspx

When a 32-bit application reads from one of these folders on a 64-bit OS:

%windir%\system32\catroot
%windir%\system32\catroot2
%windir%\system32\drivers\etc
%windir%\system32\logfiles
%windir%\system32\spool

Windows actually lists the content of:

%windir%\SysWOW64\catroot
%windir%\SysWOW64\catroot2
%windir%\SysWOW64\drivers\etc
%windir%\SysWOW64\logfiles
%windir%\SysWOW64\spool

Thanks for your input Kris, that helped me find out what is going on.

EDIT: Thank you Ludvig too :-)