CreateProcess with extended length path fails ERROR_INSUFFICIENT_BUFFER RRS feed

  • Question

  • This is a copy of my question that was originally submitted to the Windows 7 forum.

    I have some processes that I can't start because their fully qualified path is longer than MAX_PATH. I am specifying the extended path properly using \\?\.

    For example I have one that is 559 characters. CreateProcess returns ERROR_INSUFFICIENT_BUFFER (122). I can see when I debug that CreateProcessW is calling NtCreateUserProcess which is returning STATUS_BUFFER_TOO_SMALL. I have looked through all the parameters and I can't figure out why.

    I thought maybe if I changed the current directory to my extended path I could create the process without specifying its path. Unfortunately SetCurrentDirectory only accepts a max length of MAX_PATH - 1. RtlSetCurrentDirectory_U doesn't seem to be any better because it returns STATUS_NAME_TOO_LONG. This is even if I break apart the extended path's components (which are each less than MAX_PATH) and try to do a bunch of relative directory changes.

    I found two similar problems on Q&A site stackoverflow:
    How to get CreateProcess/CreateProcessW to execute a process in a path > MAX_PATH characters
    LoadLibraryW fails with 122 ERROR_INSUFFICIENT_BUFFER

    So is this a known issue? Is there any way to execute processes with an extended path length > MAX_PATH, other than the GetShortPathNameW() workaround which may or may not work? Thanks

    Friday, January 9, 2015 6:34 PM

All replies

  • I do not think CreateProcessW supports extended paths. Unlike the CreateFile function.


    Friday, January 9, 2015 8:32 PM
  • from http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath

    The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

    Visual C++ MVP

    Friday, January 9, 2015 8:51 PM
  • Sheng the same thing was said in the other thread, and my reply:

    That doesn't answer the question though. As I said I'm using the Unicode version (CreateProcessW) and properly specifying the extended length path.


    Friday, January 9, 2015 9:23 PM
  • Hi.

    Since I am extending some of my company's products to support long paths, your question left me intrigued and I had to test this myself. Unfortunately I have to confirm your findings. Not even Windows 10 Technical Preview will run such executable. And that short path workaround doesn't work for me :(

    Saturday, January 10, 2015 11:08 AM
  • The current directory is stored in the process environment block (PEB) in the process parameters section. It is a struct named CURDIR which contains a handle to the directory and a UNICODE_STRING with the path, which technically can store a max of 65535 bytes (32767 WCHARs). If you open the extended path with createfile then put the handle and the path in CURDIR it's probably possible to at least switch to an extended path. There's also another section that may have to be modified, CurrentDirectories, used since each drive has a current directory. Interesting but not worthwhile if the Windows API doesn't support it.
    Saturday, January 10, 2015 5:56 PM
  • Current directories are fine.
    I can run some executables (placed on normal path) from depths of a directory tree (e.g. using Total Commander) with local file as an argument. Some of my testing apps work well, but not even Notepad (Windows 7) will.

    Monday, January 12, 2015 12:05 PM