0

I've got an application running as a Windows service that wants to read a file specified by a relative path. Since the service is running under C:\Windows\system32 (on Server 2003 and Windows 7), I figure it should be reading the file from there. However, the file read always fails.

I put together some simple test code to try to open a file for reading, using an absolute path. While the service succeeds for files such as C:\Temp\foo.txt, it always fails for files like C:\Windows\foo.txt and C:\Windows\system32\foo.txt . GetLastError() returns 2.

Am I running into an access issue? I couldn't find authoritative documentation on this. Is there any workaround?

Update:

The file test code is generic and straightforward:

std::ofstream out;
//...

std::string fileName("C:\\Windows\\system32\\Foo.txt");

hFile = CreateFile(fileName.c_str(), GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

if (hFile == INVALID_HANDLE_VALUE) {
  out << "Could not create file handle! (" << GetLastError() << ")" << std::endl;
}
else {
  out << "Successfully opened file!" << std::endl;
  CloseHandle(hFile);
}
Community
  • 1
  • 1
Haw-Bin
  • 416
  • 3
  • 8
  • @Haw-Bin: paste relevant parts of the failing code. 2 means that something with the path is wrong (`ERROR_FILE_NOT_FOUND`: file not found). – 0xC0000022L Mar 10 '11 at 16:55
  • Wow! Just stumbled upon Microsoft's article on "File System Redirection", which may explain this for Windows 7 at least! http://msdn.microsoft.com/en-us/library/aa384187(v=VS.85).aspx – Haw-Bin Mar 10 '11 at 16:57
  • @Haw-Bin: no it doesn't. A service process would not be subject to FS virtualization under normal circumstances. – 0xC0000022L Mar 10 '11 at 17:00
  • @STATUS_ACCESS_DENIED: The article mentions running a 32-bit application on 64-bit Windows, which is the case for my Windows 7 experience. Just now, I copied the file under *C:\Windows\SysWOW64*, and the file was found! This does not explain the situation for Server 2003, however, which is 32-bit. – Haw-Bin Mar 10 '11 at 17:06
  • 1
    @Haw-Bin: the virtualization feature and WOW64 file system redirection are still two different things. And you didn't mention anything about 64bit either ;) ... check out `Wow64DisableWow64FsRedirection` then – 0xC0000022L Mar 10 '11 at 17:52
  • http://support.microsoft.com/kb/942589 – Tayyab Mar 10 '11 at 18:00
  • @STATUS_ACCESS_DENIED: Thanks, I didn't mention it because I didn't realize at the time that it was a factor. :) – Haw-Bin Mar 10 '11 at 19:54

2 Answers2

0

Error code 2 is ERROR_FILE_NOT_FOUND so it's likelier that the path you give simply does not exist or the file does not exist in that path. Without the relevant flags from CreateFile it's hard to give you a better answer.

But generally - under default conditions - a service would be allowed to read in that folder.

One more thing came to mind. How do you obtain the path (C:\Windows in your case)? The proper means are to use the API (e.g. GetWindowsDirectory) for this and not hardcode it.

0xC0000022L
  • 20,597
  • 9
  • 86
  • 152
  • Thanks - I'm hard-coding it for my test only, because I checked the value of `%WINDIR%` on the machine. – Haw-Bin Mar 10 '11 at 17:18
0

Try running the windows service from Local System account. By default the service may be running from "Network Service" account. To change the settings, Open Windows Service Manager (Run-> services.msc) and double-click your service. On property window select 2nd Tab "Log On" and change it to run with Local System account.

Tayyab
  • 9,951
  • 1
  • 16
  • 19
  • It is running under "Local System account" in both environments, with "Allow service to interact with desktop" unchecked. – Haw-Bin Mar 10 '11 at 17:09