Supported way to verify a child process's actual working directory before build work starts?

The cited public Windows contracts do not expose a supported API for independently querying another process’s current directory; set the initial directory with CreateProcessW, then avoid making build correctness depend on externally reading it back.

Documented contract

• CreateProcessW.lpCurrentDirectory specifies the new process’s initial current directory; when it is NULL, the child receives the caller’s current drive and directory.^1^
• GetCurrentDirectory retrieves the current directory of the calling process. The current directory is process-global and can be changed by any thread, so Microsoft advises multithreaded applications and libraries to avoid relative paths.^2^
• CREATE_SUSPENDED prevents the primary thread from executing until ResumeThread; it does not add a process-information query for CWD.^3^
• CREATE_PROCESS_DEBUG_EVENT occurs before the new process executes in user mode and supplies process, image, and initial-thread handles, but no CWD field.^4^

Consequently, these contracts establish the directory requested at creation, not an independent observation of the child’s directory. They also establish no CWD-specific access right, architecture combination, version matrix, ETW provider, or compatibility guarantee for external readback. Reading an undocumented PEB layout would not create such a contract.

Practical application design

If independent external attestation is mandatory, the available documentation is insufficient; obtain a definitive platform-contract statement through a Microsoft developer support request. Otherwise, when the wrapper controls trusted child code, implement a cooperative application protocol—not an OS CWD-attestation guarantee:

1. Open the intended directory and retain that handle.
2. Create a one-way child-to-parent pipe and a one-way parent-to-child authorization channel.
3. Launch a small trusted bootstrap with:
   • an absolute lpApplicationName;
   • an absolute lpCurrentDirectory;
   • only the required handles inherited through STARTUPINFOEX and PROC_THREAD_ATTRIBUTE_HANDLE_LIST. Microsoft recommends explicit handle lists when inheritance is required.^5^
4. In the bootstrap, before build code or additional threads:
   • call GetCurrentDirectoryW using its size-query/retry contract;
   • open "." with CreateFileW(..., FILE_FLAG_BACKUP_SEMANTICS, ...);
   • report the path and, where supported, handle-derived directory identity;
   • wait for parent authorization.
5. The parent waits on both the report channel and the process handle returned by this exact CreateProcessW call. Reject timeout, malformed data, child exit, identity mismatch, or any failed query.
6. After authorization, use absolute paths or already-opened handles for build inputs and outputs.

A minimal bootstrap path query should resize rather than assume a fixed maximum:

std::wstring ReadOwnCwd()
{
    for (;;) {
        DWORD needed = GetCurrentDirectoryW(0, nullptr);
        if (!needed) throw std::system_error(GetLastError(),
                                             std::system_category());

        std::wstring path(needed, L'\0');
        DWORD written = GetCurrentDirectoryW(needed, path.data());
        if (!written) throw std::system_error(GetLastError(),
                                              std::system_category());
        if (written < needed) {
            path.resize(written);
            return path;
        }
    }
}

This validates what trusted bootstrap code observed. It is not independent evidence against a compromised child, and executable/DLL loader activity can occur before the executable entry point. The documented debugger initial breakpoint occurs after the main image and statically linked DLLs are loaded but before DLL initialization routines; stopping at main or WinMain is later still.^6^

If the bootstrap starts a separate build process, its report proves only the bootstrap’s CWD. Pass absolute paths or directory/file handles to the build process rather than assuming that process has retained the same CWD.

Identity and race handling

• Process instance: Retain and use the returned process handle, not a later OpenProcess(pid) lookup. Process handles remain bound to their process object until closed, whereas a PID is valid only for the process lifetime and can later be reused.^7^
• Directory object versus path: Path equality is insufficient because aliases and reparse points may resolve differently. A directory can be opened with CreateFile and FILE_FLAG_BACKUP_SEMANTICS.^8^
• Optional file identity: FILE_ID_INFO combines volume serial number and a 128-bit file ID for comparing open handles.^9^ However, that page lists no supported client and Windows Server 2012 as its minimum supported server. Filesystem support also varies. Treat an unavailable, zero, or failed identity query as unsupported and fail closed if object identity is required.
• Changes after observation: CWD is shared by every thread and can be changed later.^10^ No one-time observation guarantees future relative-path resolution. Absolute paths or retained handles remove that dependency.
• Exit or uncertainty: Wait on the report channel and exact process handle with a bounded timeout. A process handle is waitable; signaling indicates process termination.^11^ On exit, timeout, access denial, unsupported identity, or ambiguous results, perform no build work and report failure.

The application must separately establish bootstrap trust, IPC ACLs and endpoint binding, message framing, handle-list correctness, authorization semantics, and protection against later CWD changes. The public APIs cited here do not combine those properties into a Microsoft-supported CWD-attestation protocol.

References

1. CreateProcessW function (processthreadsapi.h)
2. GetCurrentDirectory function (winbase.h)
3. Suspending Thread Execution
4. Debugging Events
5. Create processes
6. Initial Breakpoint
7. Process Handles and Identifiers
8. Directory Handles
9. FILE_ID_INFO structure (winbase.h)
10. SetCurrentDirectory function (winbase.h)
11. WaitForSingleObject function (synchapi.h)