Home/ Questions/Q 900131
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T15:19:59+00:00

I have an odd bug where my code returns a file not found exception

  • 0

I have an odd bug where my code returns a file not found exception but the file seems to be exactly where it should be. My project has some code to run a system cmdlet and look for the results of the cmdlet in an XML output file. We tell the cmdlet to put this output XML in a custom subdir of the system TEMP dir, e.g., C:\WINDOWS\TEMP\SomeFolder\output.xml. We then use the .NET XmlDocument class to open and parse the XML file.

On WinXP, this works. On my dev box, this works. On a clean Win7 test machine, it does not.

My first thought was that I’m running into Vista/Win7 File Virtualization, but our application manifest specifies that our app run as Admin — and from what I’ve read, that should bypass file virtualization.

The other wrinkle is that our code likes to use UNC file paths, even if the file is local to the machine. (We have a requirement that the code in question may need to run the cmdlet on a remote machine, and therefore the output XML could be on a remote machine too.) So we try to open the XML file via \MATT-WIN7\C$\WINDOWS\TEMP\SomeFolder.xml rather than C:\WINDOWS\TEMP\SomeFolder\output.xml.

But I removed the UNC path code temporarily and a simple call to File.Exists() still says the XML file is not there, when Windows Explorer shows the file sitting exactly where I think it should be.

Is there some nuance of file virtualization that I have not read about yet?

My workaround is to move the output xml file somewhere else, but that will potentially break the “portability” of our code when it needs to run on a remote machine, because using the %TEMP% location is a location that can be resolved for remote computers pretty easily (via remote registry call to find the system environment variable).

I would prefer to leave the file where it is, and fix our code so it actually finds the file!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There is a user-specific override for the %TEMP% environment variable that points to %USERPROFILE%\AppData\Local\Temp, not to %SYSTEMROOT%\Temp. Make sure your code is looking in the temp folder you expect it to look at.

    Update: Based on your comments, it seems that the problem is that your app is not actually being elevated on the test machine, but is elevated on your dev machine. I suspect the following:

    • you either have UAC disabled on your dev machine or you are running VS as administrator. Big no-no on both. 🙂
    • your binary is not code-signed and is not in one of the two trusted locations – %SystemRoot%\system32 or %ProgramFiles%. For security reasons UAC does not even prompt the user for elevation for apps that have elevation manifest, but are not code-signed or in a trusted location.

    You can create a self-signed certificate to code-sign your binary and add that certificate to the test machines, to get the UAC prompt. Once you’ve confirmed that your app is properly being elevated, your code to access the system %TEMP% folder should work correctly.

    • 0