A Steam build that runs on every studio PC and fails on a player’s is usually missing a Microsoft runtime that Visual Studio put on the dev machines. Steamworks covers this with a checkbox list of common redistributables. Valve’s build review checks that the game starts. The table below maps 7 launch errors to the runtime behind each, and a clean Windows image shows them before you submit.
What are Steam redistributables, and who installs them?
Redistributables are shared runtimes a game needs before its executable can start. Valve’s Common Redistributables page (read 3 November 2026) names Microsoft Visual C++, .NET, DirectX 9, OpenAL, XNA and PhysX, and says the full list lives on the Redistributables tab, under Installation in the Steamworks App Admin panel. You tick what the game needs and publish. Steam then installs each one “only if necessary”, from install scripts that Valve “creates and maintains” and updates when patches ship.
Microsoft states the requirement from its side. If an app was built with the MSVC tools, a Visual C++ Redistributable “at least as recent as the build tools used to build your app must be installed on the target system”, and its architecture must match the app’s. Every machine with Visual Studio already has those files. So do most gaming PCs that have run other Steam games. Our reading is that this is why the gap shows up on fresh Windows installs, new laptops and review machines first, and rarely on the team’s own hardware.
The launch section of our free Next Fest demo QA checklist covers the same moment for a demo, inside 52 checks you can tick off in the browser before the demo goes to review.
What happened to the Red Flag demo before June Next Fest?
Red Flag, a social deduction game from a first-time team, uploaded its demo on the last day it could still make Steam Next Fest in June 2026. PC Gamer reported the team’s account on 10 July 2026, from a post on r/IndieDev. After an urgent review request the build was approved within hours, with a note. In the team’s words, “the reviewer couldn’t launch the game. We’d messed up the C++ redistributable setup (forgot to use the Steam common redist system, shipped local DLLs instead).”
Steam Support “edited our configuration, sorted the dependencies, and approved the build”, the team wrote, and its wishlists “nearly doubled” after the first fest day. Automaton West noted that other developers replied with similar stories. Two details are worth keeping. Launching is part of the check: Valve’s review process page says a product “must successfully launch in all supported operating systems listed on the store page”. And nothing in Valve’s docs promises the fix Red Flag got from Steam Support. Plan for the 7 business days Valve asks for, and assume a build that does not start comes back to you.
A demo is a separate App ID. Valve’s demos page says it “will need to be configured with depots, and builds must be created just like a full app”. The Redistributables tab sits in each app’s own Installation settings, so a base game with the right boxes ticked does not cover its demo or Playtest. Our Playtest, demo and beta branch comparison explains how the three apps relate.
A Smoke Test starts at this exact point. One tester installs the build from Steam on hardware your team does not own and spends 8 hours on it, beginning with first launch, so a missing runtime is logged with the full dialog text before Valve’s reviewer ever sees it.
Which launch errors point to which missing redistributable?
Most runtime failures announce themselves in the first second. The table maps what a player or reviewer sees to the likely cause and to a check you can run first. Status codes come from Microsoft’s NTSTATUS list; the cause column is our editorial mapping, and one code can have other causes.
| What the player sees | Likely cause | Fix | How to catch it before review |
|---|---|---|---|
| “VCRUNTIME140.dll was not found”, also MSVCP140.dll or VCRUNTIME140_1.dll (status 0xC0000135, STATUS_DLL_NOT_FOUND) | Visual C++ v14 runtime (Visual Studio 2015 to 2026) missing for the exe’s architecture | Tick Visual C++ on the Redistributables tab, x64 for a 64-bit exe | dumpbin /DEPENDENTS on the exe lists the DLL; a clean sandbox shows the dialog |
| “VCRUNTIME140D.dll”, “MSVCP140D.dll” or “ucrtbased.dll” was not found | A Debug build was uploaded | Upload a Release or Shipping build; Microsoft does not allow redistributing debug DLLs | dumpbin /DEPENDENTS shows a name ending in “d” |
| MSVCR120.dll, MSVCP110.dll or MSVCR100.dll was not found | A plugin or middleware built with Visual Studio 2010 to 2013, which have their own runtimes | Tick that older Visual C++ version as well | Run dumpbin /DEPENDENTS on every DLL you ship, not only the exe |
| Error 0xc000007b (STATUS_INVALID_IMAGE_FORMAT, “Bad Image”) | Often a 32-bit DLL loaded by a 64-bit exe, or the reverse | Ship one architecture per build folder; match redistributable architecture to the exe | Check each binary’s machine type with dumpbin /HEADERS |
| d3dx9_43.dll, XINPUT1_3.dll or xaudio2_7.dll was not found | Legacy DirectX SDK components, which Windows does not include | Tick DirectX on the Redistributables tab | A clean sandbox does not have these files, so the dialog shows on first launch |
| Window flashes and closes, no dialog | Many causes; one is a Visual C++ DLL in the game folder older than the toolset that built the game | Remove app-local runtime copies and use the checkbox | Process Monitor shows which copy of msvcp140.dll the game loaded |
| A runtime installer appears on every launch | Custom install script whose installer exits with a non-zero code | Add silent flags or a HasRunKey, or switch to the checkbox | Launch twice in the sandbox; the second launch should go straight to the game |
The DirectX row surprises teams on modern engines. Microsoft’s June 2010 End-User Runtime, republished as version 9.29.1974.1 on 15 July 2024, installs D3DX, XAudio 2.7 and XInput 1.3 for older games and “does not modify the DirectX Runtime installed on your Windows OS”. A current Windows can run DirectX 12 and still lack d3dx9_43.dll.
Checkbox, install script or DLLs next to the exe: which one to use?
There are three ways to get a runtime onto a player’s PC through Steam. They differ in who keeps the runtime up to date.
| Common redistributable checkbox | Custom install script | DLLs in the game folder | |
|---|---|---|---|
| Who updates it | Valve maintains the scripts and updates them when patches ship | You | You, in every build |
| When it runs | Installed only if missing; 64-bit and 32-bit versions on 64-bit Windows where applicable | When a player starts the game, Steam scans mounted depots for flagged scripts and runs them | Loaded at start from the folder next to the exe |
| Platforms | Windows | Mainly Windows; macOS limited to file permissions and symlinks; no Linux or SteamOS support | Any |
| Official stance | Valve’s default route for listed runtimes | For “uncommon or custom” redistributables | Microsoft: not recommended “for servicing reasons” |
| Typical failure | Box ticked on the base game, missing on the demo app | Non-zero exit code, installer reruns each launch | Missing, debug or outdated DLL |
Microsoft’s deployment guide prefers central installation because Windows Update can then service the runtime, and an app’s uninstall cannot break other apps. App-local copies also have a blind spot. On Windows 10 and 11, the Universal CRT in the system folder “is always used, even if an application includes an application-local copy”, even a newer one. Shipping ucrtbase.dll next to the exe changes nothing there.
Install scripts are for what the checkbox list lacks. The file must sit inside a depot, is marked with the InstallScript directive in the depot build script, and is signed during the upload. Valve’s page adds one rule for uninstall: “Please do not uninstall common redists such as DirectX, msvc run time, etc”, since other games use them. If a runtime you need is widely used but not listed, Valve asks you to raise it in the Steamworks Development Group.
One version note belongs in the same review. Microsoft says the latest Visual C++ v14 Redistributable shipped with Visual Studio 2026 supports Windows 10 and 11 only, so a store page that lists Windows 7 or 8 as minimum promises an OS the current runtime no longer covers.
How do you test a Steam build on a clean PC?
Valve calls “a clean OS image on a machine or VM” the ideal method. The procedure below covers install and first launch only. It takes under an hour once the image exists, by our editorial estimate.
- List what the binaries import. Run
dumpbin /DEPENDENTSfrom a Visual Studio developer prompt on the exe and every DLL in the depot. Microsoft’s /DEPENDENTS page describes it as a way to “find the name of a missing dependency”. Compare the list with your ticked boxes. - Start a clean Windows. Windows Sandbox ships with Windows Pro, Enterprise and Education (not Home), and each launch “is as clean as a brand-new installation of Windows”. A VM from a fresh image or a reset spare PC also works.
- Install Steam and log in with a test account. A developer account owns the app automatically. A separate account with a key and the branch password installs the build the way a player does. Valve’s demos page says testing a demo on a new account needs demo keys.
- Install from Steam and launch from the library. Write down the build ID, every installer window Steam shows, and the exact text and code of any error.
- If nothing appears, trace it. Run Process Monitor, filter on the game’s process name and look for .dll paths with the result NAME NOT FOUND. The last one before the process exits is a good first suspect.
- Launch a second time. A runtime installer that appears again points to the exit code problem in the last row of the table.
- Repeat for the demo and Playtest apps, which have their own configuration. Then test partial states on an ordinary PC by deleting subkeys under
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Valve\Steam\Apps\CommonRedist, which Valve documents as a way to make Steam reinstall them.
Windows Sandbox gives the game a virtual GPU at best, so treat it as a launch test, not a performance pass. Once the game reaches its main menu there, move to real hardware and play on through the first 2 hours that Steam’s refund rule covers, from the same clean install. The demo week calendar in our Next Fest February 2027 QA plan puts this clean-machine install at T-7, two weeks before the demo is submitted.
What changes when a patch adds a new DLL?
A runtime problem can appear after launch too. A new audio plugin, an anti-cheat client or an analytics SDK can bring an import that the release build did not have. Keep the dumpbin /DEPENDENTS output from step 1 with each build and diff it against the previous upload. Any new name either belongs to Windows, sits on the Redistributables tab, or needs an install script.
Configuration changes in Steamworks only take effect once published, and the same applies to a newly ticked runtime. The patch day QA checklist lists 34 checks for a build before it goes to the default branch; the clean-machine launch from step 4 fits in front of them. If a patch does break first launch, the Early Access launch checklist covers branch rollback for launch week.