What 0xc0000142 means
Most Windows programs rely on DLLs (dynamic link libraries) — shared code files that many programs load. When a program starts, Windows loads each DLL it needs and lets that DLL set itself up.
Microsoft names code 0xC0000142 STATUS_DLL_INIT_FAILED. A DLL was found and loaded, but its setup step reported failure. When that happens while a program is starting, Windows ends the program, and you see the box.
The code does not name the DLL, and neither does the message. Finding the cause takes testing, not a lookup. It is also not a missing file: a DLL that isn't there gives a different code, 0xc0000135.
First, find out how far it reaches
Three questions narrow it down. Only the second changes the PC, because it adds a user account.
- Do other, unrelated programs open? Try Notepad, Settings, and one app you installed yourself.
- Does the failing program open in a different Windows account? If you have no second account, open Settings → Accounts, go to the other-users page, and select Add account (Microsoft's steps). Windows may ask for an administrator password. Sign in to it and try the program there.
- Do Command Prompt and PowerShell open? If they fail with the same code, skip to the last section.
Then see whether Windows logged it. In PowerShell, this lists entries from the last day that contain the code:
% Get-WinEvent -FilterHashtable @{LogName='Application','System'; StartTime=(Get-Date).AddDays(-1)} | Where-Object { $_.Message -like '*0xc0000142*' } | Format-List TimeCreated, LogName, ProviderName, Id, MessageRun in PowerShell; no administrator rights needed. Look for the failing program's name in each message. No entries does not prove nothing failed, because not every failure is written to these logs. If PowerShell itself won't open, press Win+R, type eventvwr.msc, and look under Windows Logs.
NoahNoah searches the Application and System logs for entries that mention the program, and reads the Windows version and build. The search covers the most recent 2,000 events in the time window, so an empty result does not prove nothing failed. Noah cannot tell which DLL failed from the code, because the code does not carry that. It has no built-in way to trace which DLLs a program loads.
Only one program fails
Other programs open normally. This one shows 0xc0000142 every time, in every Windows account.
The fault is in something only this program uses. That is its own files, or a Visual C++ Redistributable — a Microsoft package of shared code that programs built with Microsoft's C++ tools need installed.
Fixrepair the program first. Search for Control Panel, open Programs → Programs and Features, right-click the program, and choose Repair, or Change if Repair isn't offered. If nothing is offered, uninstall it, restart, and reinstall it from the maker's site.
Apps from the Microsoft Store repair in Settings instead. On Windows 11, open Apps → Installed apps, click ⋯ next to the app, and choose Advanced options → Repair. On Windows 10, open Apps → Apps & features, select the app, and choose Advanced options → Repair.
If repair doesn't help, look at the Visual C++ package. Microsoft's advice for fixing an app this way is to contact the app's maker for instructions, because the right package depends on how the app was built.
Microsoft's latest v14 package covers programs built with Visual Studio 2015 or later. Programs built with 2013 or earlier need their own older package. The package must also match the program's architecture, so a 32-bit program needs the x86 package, even on 64-bit Windows.
Fixask the program's maker, or check its support page, which Visual C++ version it needs. To see what is installed, search for Visual C++ in Programs and Features. For a program built with 2015 or later, install the latest v14 packages for x64 and x86 from Microsoft's download page. Don't uninstall the existing ones first; other programs may rely on them.
NoahNoah lists the software installed on the PC, including each Visual C++ Redistributable listed in Programs and Features, with its version. That list does not show which package a program was built against. The program's maker can tell you.
It works in another Windows account
The program opens when you sign in as a different user, but not in your usual account.
Both accounts use the same copy of the program and of Windows' shared files, so those are fine. What differs is your user profile — the folder and settings Windows keeps for each account — and the apps that start when you sign in.
A 2026 Microsoft Q&A case followed this pattern. The app failed with 0xc0000142 in the user's administrator account, then installed and ran in a new standard account. The suggested next step was a clean boot.
A clean boot means starting Windows with only Microsoft's own services and no startup apps. If the program opens after one, something you switched off is the cause.
Fixsign in as an administrator, search for msconfig, and open System Configuration. On Services, tick Hide all Microsoft services, then click Disable all and Apply. On Startup, click Open Task Manager and disable each startup app. Restart and try the program.
If it opens, turn items back on a few at a time until it fails again. To undo everything, open System Configuration, choose Normal startup on the General tab, click Enable all on Services, and re-enable your startup apps.
If it still fails after a clean boot, the cause is something a clean boot doesn't switch off, such as a setting inside the account itself. Using the other account for that program is a safe workaround meanwhile.
NoahNoah lists the programs set to start with Windows, which are switched on, and whether each runs for your account or for every account. It flags entries whose program no longer exists. It can switch off an entry that runs for your account, with your approval; entries for every account need Noah running as administrator. Noah has no built-in way to create a second Windows account, and it cannot sign in to one to test the program.
Many unrelated programs fail
Programs from different makers all show 0xc0000142, often starting around the same day.
When unrelated programs fail the same way, they share something that broke. Usually that is a damaged Windows system file, or software that loads its own DLL into every program.
Repair Windows' own files first. DISM supplies good copies of system files, and SFC (System File Checker) uses them to replace damaged ones. Microsoft says to run DISM before SFC.
Fixtype cmd in the Search box, right-click Command Prompt, and choose Run as administrator. Then run these one at a time:
% DISM.exe /Online /Cleanup-image /RestorehealthRun in the administrator Command Prompt. Microsoft notes it can take several minutes. Wait until it reports the operation completed successfully.
% sfc /scannowRun after DISM finishes. Don't close the window until verification reaches 100%. Then restart and try the programs again.
The other shared cause is software that loads into every program. Windows has an old setting for this called AppInit_DLLs, a list of DLLs loaded into every interactive program. Microsoft recommends against it, and Windows ignores it when Secure Boot is on.
Fixpress Win+R, type msinfo32, and read Secure Boot State. If it says On, skip this setting. If it says Off or Unsupported, read the setting without changing it. 64-bit Windows keeps a second copy for 32-bit programs, so read both, in PowerShell:
% Get-ItemProperty -ErrorAction SilentlyContinue 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows', 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Windows' | Format-List PSPath, LoadAppInit_DLLs, AppInit_DLLsRead-only. The first result applies to 64-bit programs; the one with WOW6432Node in its path applies to 32-bit programs. Nothing loads this way only when every result shows LoadAppInit_DLLs as 0 or an empty AppInit_DLLs. If a file is listed, update or uninstall the program that installed it rather than editing the value.
If SFC finds nothing and both AppInit_DLLs values are empty, run the clean boot test from the section above. It also switches off services that other software makers install.
NoahNoah can search the Application and System logs for one program name at a time, so checking several programs means one search each. Noah has no built-in DISM or SFC repair, and no built-in check of AppInit_DLLs or Secure Boot state.
Command Prompt and PowerShell fail too
Command Prompt, PowerShell, and tools that run inside them, such as SFC and DISM, all show 0xc0000142.
The repair tools above run in a console window, so they fail the same way. In a Microsoft Q&A case with this pattern, the accepted answer attributed it to a damaged conhost.exe — the Windows program that hosts every console window.
The repair then has to start from the Windows Recovery Environment — a separate repair mode Windows can start into — rather than from inside Windows.
Fixhold Shift while you choose Restart from the Start menu's power button, then pick Troubleshoot → Advanced options. If working from there is unfamiliar, get hands-on help rather than guessing. Don't copy system files from download sites.
NoahNoah has no built-in repair for this case.
What to avoid
- Downloading a DLL from a DLL download site. The code doesn't say which DLL failed, and those copies come from unknown sources.
- Re-registering every DLL with regsvr32. Registering is for a different job: telling Windows where certain components live. It is not a repair for a DLL whose setup fails.
- Editing the registry — Windows' database of system and program settings — before a test points there. That includes AppInit_DLLs.
- Uninstalling every Visual C++ Redistributable at once. Other programs may depend on the versions you remove.