Windows · Windows Server  ·  medium  ·  Applications & Microsoft 365

An application will not start — 0xc0000142, 0xc000007b, 0xc0000005

Three different loader failures with nearly identical dialogs. The code says which one, and each has a different fix.

What you see

"The application was unable to start correctly (0xc0000142). Click OK to close the application." Nothing is logged in the application's own logs because it never ran.

What is actually wrong

0xc0000142 is a DLL failing to initialise — usually a runtime mismatch or a missing dependency. 0xc000007b is an architecture mismatch, a 32-bit process loading a 64-bit DLL or the reverse. 0xc0000005 is an access violation, frequently a security product injecting into the process. 0xc0000135 is a missing .NET runtime.

Codes and articles

0xc00001420xc000007b0xc00000050xc0000135The application was unable to start correctly

Fixes (3)

Install the runtimes the application actually needs
Elevated PowerShell30 minuteslow riskreversible

0xc0000142 or 0xc0000135 — a missing or damaged runtime.

  1. See which Visual C++ runtimes are present. Applications commonly need several different years, and having the newest does not cover the older ones.

    PowerShell
    Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*,HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |  Where-Object DisplayName -like '*Visual C++*' |  Sort-Object DisplayName | Format-Table DisplayName,DisplayVersion

  2. Install the Visual C++ Redistributable the application documents, in both x86 and x64 — a 64-bit machine needs both, because many applications ship 32-bit components.

    The x86 package on a 64-bit machine is not redundant. It is a separate set of DLLs in SysWOW64, and its absence is the single most common cause of 0xc0000142 on an otherwise healthy install.

  3. For 0xc0000135, check the .NET versions present.

    PowerShell
    Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse |  Get-ItemProperty -Name Version,Release -ErrorAction SilentlyContinue |  Select-Object PSChildName,Version | Format-Tabledotnet --list-runtimes

  4. Repair the application's own installation from Settings → Apps → Modify, which reinstalls its private copies of these libraries.

Confirm it workedThe application starts. If it still does not, the next step is Dependency Walker or a Process Monitor trace filtered on NAME NOT FOUND for the process.
If you need to undo itRuntimes can be uninstalled, though there is rarely a reason to.
Resolve the architecture mismatch
Elevated PowerShell30 minutesmedium riskreversible

0xc000007b specifically. This code means bitness, essentially always.

  1. Establish whether the executable is 32 or 64-bit.

    PowerShell
    $p='C:\Program Files\App\app.exe'$fs=[IO.File]::OpenRead($p);$br=New-Object IO.BinaryReader($fs)$fs.Seek(0x3C,'Begin')|Out-Null;$peOff=$br.ReadInt32()$fs.Seek($peOff+4,'Begin')|Out-Null'{0:X4}' -f $br.ReadUInt16()$br.Close()

    8664 is x64, 014C is x86, AA64 is ARM64. Knowing which you have decides which runtime to install and stops the guessing that makes this fault take an afternoon.

  2. Install the matching runtime — a 32-bit application needs the x86 redistributable regardless of the machine.

  3. Check for DLLs of the wrong architecture sitting in the application folder, usually copied there by a well-meaning fix from a forum. Remove them and let the application use the system copies.

  4. Reinstall the application cleanly if the folder has been tampered with.

Confirm it workedThe application launches and Process Explorer shows it loading DLLs from the expected directories.
If you need to undo itKeep a copy of any DLL removed from the application folder until it is proven unnecessary.
Rule out a security product injecting into the process
Elevated PowerShell30 minutesmedium riskreversible

0xc0000005, or an application that crashes immediately on a machine where it works elsewhere.

  1. Read the fault from the application log — it names the module that actually crashed.

    PowerShell
    Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000,1001} -MaxEvents 10 | Format-List TimeCreated,Message

  2. If the faulting module belongs to a security product, add an exclusion for the application rather than disabling protection.

  3. Check the exploit protection settings, which frequently break older applications.

    PowerShell
    Get-ProcessMitigation -Name app.exe

    Windows applies system-wide mitigations such as CFG and DEP that some older applications violate legitimately. This shows exactly which mitigations apply to that executable, so one can be relaxed rather than all of them.

  4. Relax a single mitigation for that executable only if it is genuinely required.

    PowerShell
    Set-ProcessMitigation -Name app.exe -Disable DEP
Confirm it workedThe application runs with the rest of the system's protections intact.
PowerShell
Get-ProcessMitigation -Name app.exe | Format-List
If you need to undo itSet-ProcessMitigation -Name app.exe -Remove restores the system defaults for that executable.

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.