MSVC 19.44 output-file contract for precreated NTFS object and XML-analysis files

Hi @esa mlore ,

I could not find a published, build-specific contract for these restrictions. The /Fo compiler option reference covers how the object file name or output directory is selected, including error D8036 when a file name is used with more than one source file and D8003 when a specified output directory does not exist. The /analyze code analysis reference documents /analyze:log as the log path and /analyze:log:format:xml as the XML format. It also notes that code generation runs before analysis unless /analyze:only is specified, so both writers are active in your invocation. With /Z7, the debug information format reference confirms that debug information is stored in the object file and that the compiler does not produce a PDB, which limits the outputs to the two files you listed. None of these pages describes access rights, sharing modes, creation dispositions, replacement behavior, helper files, or preservation of file identity and security. They also do not say whether any of this differs on error or cancellation paths.

Testing the matching compiler did, however, identify one specific incompatibility, and it involves the XML log directory rather than the object file.

I tested EWDK cl.exe FileVersion 19.44.35209.0, ProductVersion 14.44.35209.0, kit 10.0.26100.0, with your compiler options, x64 host and target tools, and a standard account on a Windows 11 Pro VM (build 26300). With permissive ACLs, a simple source and a source producing C6011 both compiled, dumpbin /headers accepted the objects, and the warning appeared in well-formed XML.

On /Fo, compilation still succeeded when your restrictions applied to the object file and its directory, with the XML log directed to a separate writable directory. The object was opened with Generic Write, Read Attributes, OverwriteIf and ShareMode: None. I observed no helper file in the object directory and no rename into the target in those completed runs.

The XML log behaved differently. With your full directory restrictions, the writer tried to create an esp*.tmp sibling in the XML output directory even though TMP pointed to a separate writable location. ProcMon recorded CreateFile with Disposition: Create returning ACCESS DENIED, and the compiler then reported C1258: Failed to save XML Log file and exited with code 2, leaving both precreated targets empty. The missing FILE_ADD_FILE right on that directory is what breaks this setup. In a separate run, the final XML file kept your exact permissions while its directory allowed the helper file to be created and cleaned up, still without FILE_DELETE_CHILD. That run succeeded and logged C6011. Several opens on the target requesting DELETE or WRITE_DAC were denied before a lower-access OverwriteIf open succeeded, so those target rights were not required on that path. The helper file was deleted on normal completion, and nothing was renamed into the final XML.

Before and after snapshots showed the same File IDs, SYSTEM ownership, DACLs and empty SACLs on both targets. A syntax error left both targets empty, although that path stops in the front end and does not exercise cleanup of a partially written object. In the baseline, Ctrl+C and forced termination left XML temporary files behind before either final target was written. Under your restrictions, the cancellation attempts had already failed with C1258 before I could intervene. Back-end failures, cancellation during the final writes, and other attribute or sharing combinations remain untested.

If your design can allow it, permitting helper file creation and cleanup in the XML log directory was enough in my test. This is a workaround based on observed behavior, not a supported configuration.

These observations do not establish a supported contract, and confirming one is beyond what I can do from this forum. For an authoritative answer, you can submit the ACL repro, the full cl /Bv output and the command line through C++ Developer Community, and ask explicitly which behavior is supported for this build.

I hope the test results and documentation above help explain the behavior and give you a clear way to troubleshoot the issue. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance so that others in the community facing a similar issue can find it more easily and help each other.

Thank you.