Supported invocation-local zero-child and temporary-file behavior for MSVC14.50.35717 Hostx64/x64 cl.exe

Hi @Artush Vardanyan ,

Thank you for the detailed description of your requirements and constraints.

Based on the Microsoft documentation I have reviewed, there's not an officially supported, invocation-local switch or environment contract for the unchanged MSVC 14.50.35717 Hostx64/x64 cl.exe that preserves normal compile-only behavior with the pinned SDK and dependencies while also guaranteeing all of the following:

• No VCTIP or other helper-process creation attempts, including attempts that would subsequently be blocked by a one-process Job.
• No undeclared temporary artifacts, including the observed Microsoft/VSApplicationInsights/tmp directories.
• No registry, policy, or machine-wide configuration changes.
• No modification, replacement, removal, renaming, or patching of Visual Studio components.

The published documentation reviewed for MSVC compiler options, command-line usage, and Visual Studio diagnostic-data settings does not describe a mechanism that provides this complete set of guarantees.

Some controls address individual aspects of the scenario, but none appears to provide the full guarantee you described:

• /c (compile without linking) The /c option prevents the linking phase and is the documented method for compile-only operation. However, the documentation does not describe /c as preventing VCTIP/helper-process creation attempts or preventing temporary-directory creation.
• Avoiding /MP The /MP option is a documented mechanism that creates additional compiler processes. Avoiding /MP removes that specific source of child-process creation, but it does not constitute a documented guarantee that no other helper process will be launched or attempted.
• Setting TMP and TEMP for the invocation Invocation-local TMP and TEMP settings can influence where software writes files when it uses the standard Windows temporary-path APIs. However, this redirects potential artifacts rather than guaranteeing their absence, and I have not found documentation stating that all compiler-related components exclusively honor those variables. Therefore, this does not establish a no-artifact guarantee.
• Visual Studio diagnostic-data settings Microsoft documents diagnostic-data and experience-improvement settings, but I have not found documentation describing them as an invocation-local cl.exe contract that prevents helper-process creation attempts or eliminates all temporary artifacts. In addition, global or user-level policy changes fall outside the constraints you outlined.
• One-process Job Object limits A Job Object can enforce a process limit and therefore detect or block child-process creation. However, as you noted, an attempted child-process creation that is later blocked still violates your acceptance criteria. Consequently, the Job serves as a validation mechanism rather than a documented means of satisfying the requirement that no creation attempt occur.

Given the exact compiler version, pinned dependency set, and the requirement for zero helper-process creation attempts and zero undeclared temporary artifacts, I am not aware of any public Microsoft documentation that establishes such a runtime contract for MSVC 14.50.35717. A definitive answer regarding whether that behavior is intended, guaranteed, or unsupported for this exact toolset would require confirmation from the MSVC product team.

Given the requirement for an exact compiler version, pinned dependencies, zero helper-process creation attempts, and zero undeclared temporary artifacts, the publicly available documentation reviewed does not establish such a runtime contract for MSVC 14.50.35717.

I hope this clarifies the current understanding based on the available documentation. Please feel free to reach out if you have any additional questions.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation. Thank you.