Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 6564751
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 25, 20262026-05-25T14:00:25+00:00 2026-05-25T14:00:25+00:00

I got a somewhat strange error when trying to resolve the CommonDocuments directory. It

  • 0

I got a somewhat strange error when trying to resolve the CommonDocuments directory.
It keeps resolving to the wrong directory, after the CommonDocuments directory has been redirected / moved to a new location using Windows Explorer (Properties->Path from the context menu).

a minimal working piece of code would be:

namespace CommonDocumentsTest
{
    class Program
    {
        private static readonly Guid CommonDocumentsGuid = new Guid("ED4824AF-DCE4-45A8-81E2-FC7965083634");

        [Flags]
        public enum KnownFolderFlag : uint
        {
            None = 0x0,
            CREATE = 0x8000,
            DONT_VERFIY = 0x4000,
            DONT_UNEXPAND= 0x2000,
            NO_ALIAS = 0x1000,
            INIT = 0x800,
            DEFAULT_PATH = 0x400,
            NOT_PARENT_RELATIVE = 0x200,
            SIMPLE_IDLIST = 0x100,
            ALIAS_ONLY = 0x80000000
        }

        [DllImport("shell32.dll")]
        static extern int SHGetKnownFolderPath([MarshalAs(UnmanagedType.LPStruct)] Guid rfid, uint dwFlags, IntPtr hToken, out IntPtr pszPath);

        static void Main(string[] args)
        {
            KnownFolderFlag[] flags = new KnownFolderFlag[] {
                KnownFolderFlag.None,
                KnownFolderFlag.ALIAS_ONLY | KnownFolderFlag.DONT_VERFIY,
                KnownFolderFlag.DEFAULT_PATH | KnownFolderFlag.NOT_PARENT_RELATIVE,
            };


            foreach (var flag in flags)
            {
                Console.WriteLine(string.Format("{0}; P/Invoke==>{1}", flag, pinvokePath(flag)));
            }
            Console.ReadLine();
        }

        private static string pinvokePath(KnownFolderFlag flags)
        {
            IntPtr pPath;
            SHGetKnownFolderPath(CommonDocumentsGuid, (uint)flags, IntPtr.Zero, out pPath); // public documents

            string path = System.Runtime.InteropServices.Marshal.PtrToStringUni(pPath);
            System.Runtime.InteropServices.Marshal.FreeCoTaskMem(pPath);
            return path;
        }
    }
}

Expected behaviour:
Output is D:\TestDocuments

Actual behaviour:
Output is C:\Users\Public\Documents

None; P/Invoke==>C:\Users\Public\Documents
DONT_VERFIY, ALIAS_ONLY; P/Invoke==>
NOT_PARENT_RELATIVE, DEFAULT_PATH; P/Invoke==>C:\Users\Public\Documents

The correct value is stored in the Windows Registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Documents), but it is not returned by SHGetKnownFolderPath (or Environment.GetFolderPath)

OS: Windows 7 Professional x64
.NET Framework v4.0.30319
Application is compiled for x86 CPU

What I tried so far:

  • restarting my application
  • restarting the computer
  • calling Environment.GetFolderPath(Environment.SpecialFolder.CommonDocuments);
  • direct calls to Win32-API SHGetKnownFolderPath

EDIT 2
Steps to reproduce:

  1. deactivate UAC on your computer [and restart!]
  2. go to C:\Users\Public\
  3. right click on “Public Documents” folder and select
    Properties
  4. select the ‘Path’ tab
  5. click ‘Move…’ and select a (new) folder on drive D: called TestDocuments
  6. click ‘Apply’
  7. accept to move all files to the new location start the minimal
    application above
  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-25T14:00:25+00:00Added an answer on May 25, 2026 at 2:00 pm

    tl;dr: Behaviour is by design and only appears when you’re running an assembly that was compiled for x86 CPUs on a x64 OS


    Longer version:
    Environment.GetFolderPath(Environment.SpecialFolder.CommonDocuments) accesses the 32-bit hive of the Windows Registry.
    The actual path to the folder is stored in the 64-bit hive.
    The issue has been forwarded to the Windows team and may be fixed in a future version of Windows.

    For a bit more information see the Microsoft connect report


    Workaround
    create a console application with the following code and compile it for ANY CPU

    static void Main(string[] args)
    {
            Console.WriteLine("{0}", Environment.GetFolderPath(System.Environment.SpecialFolder.CommonDocuments));
    }
    

    then call it from your main application:

    Process proc = new Process();
    ProcessStartInfo info = new ProcessStartInfo("myConsoleApp.exe");
    
    // allow output to be read
    info.RedirectStandardOutput = true;
    info.RedirectStandardError = true;
    info.UseShellExecute = false;
    proc.StartInfo = info;
    
    proc.Start(); 
    proc.WaitForExit();
    string path = proc.StandardOutput.ReadToEnd();
    

    this will launch the ANY CPU executable, which only prints out the desired path to the standard output. The output then is read in the main application and you get the real path.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I've got a somewhat primitive framework I've been using for most of my projects,
I just got into somewhat complex databases (complex for me) and I have been
I've just got an error message that was somewhat unexpected: Error Message: Could not
I've got a somewhat dated Java EE application running on Sun Application Server 8.1
I've got some somewhat hefty string size calculations happening in my app (each one
I've got a class somewhat like this: public class Test { private final List<ISomeType>
Got a bluescreen in windows while cloning a mercurial repository. After reboot, I now
In order to keep my Qt project somewhat organized (using Qt Creator), I've got
I seem to handle special cases like this somewhat frequently. There's got to be
so I know there are somewhat similar questions on here, but I haven't been

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.