Start with Event Viewer, then use Process Monitor, then confirm with Dependencies. That is the cleanest order for most Microsoft Visual C++ runtime errors. The Visual C++ Redistributable installs runtime files that many Windows apps need, such as MSVCP140.dll and VCRUNTIME140.dll [source: Microsoft].
TLDR: If an app crashes with a Visual C++ runtime error, use Event Viewer first to see the crash name. Then use Process Monitor to catch missing files or blocked registry keys. Use Dependencies when you suspect a missing DLL, like VCRUNTIME140.dll. A simple 15-minute check could be 3 minutes in Event Viewer, 7 in Process Monitor, and 5 in Dependencies.
Why these tools beat blind guessing
Visual C++ runtime errors are annoying. One minute your app opens. The next, Windows throws a box that says something vague and grumpy. It drives me crazy that the message often says “runtime error” but not what broke.
So people reinstall the app. Then they reinstall the redistributable. Then they reboot. Then they stare at the same error. Fun times.
These three tools help you stop guessing:
- Event Viewer shows crash logs.
- Process Monitor shows file, registry, and process activity.
- Dependencies shows DLL links and missing runtime files.
1. Event Viewer: the quick crash diary
Best for: First checks. Crash names. Error codes.
Event Viewer is built into Windows. You do not need to install anything. That is nice. Open it, check Windows Logs, then Application. Look for red error icons near the crash time.
You may see details like:
- Faulting application name: the app that crashed.
- Faulting module name: sometimes a runtime DLL.
- Exception code: a clue for deeper checks.
This is great when the error is obvious. For example, if the faulting module is VCRUNTIME140.dll, you have a strong clue. You may need to repair the Visual C++ Redistributable or check which version the app expects.
The annoying bit? Event Viewer can be noisy. It logs tons of stuff. Some of it looks scary but has nothing to do with your app. Expect to waste a few minutes clicking the wrong red icons.
2. Process Monitor: the detective with a flashlight
Best for: Missing files. Access denied errors. Weird install paths.
Process Monitor, or ProcMon, is part of Microsoft Sysinternals. It records what programs do in real time. Files. Registry calls. Process starts. DLL searches. All of it.
This tool is gold when an app says a runtime file is missing, but the file is clearly sitting on your PC. Why? The app may be searching the wrong folder. Or Windows may block access. Or an old copy may load first.
Use this simple flow:
- Open Process Monitor.
- Add a filter for your app name.
- Start capture.
- Launch the broken app.
- Stop capture after the crash.
- Search for NAME NOT FOUND or ACCESS DENIED.
Process Monitor can show that an app looked for msvcp140.dll in five folders before failing. That is the kind of clue you can actually use. Microsoft hosts Process Monitor as part of Sysinternals [source: Microsoft Learn].
The catch is simple. ProcMon captures a huge amount of data. Leave it running for 30 seconds too long and you may have thousands of extra lines. Filter early. Your eyes will thank you.
3. Dependencies: the DLL family tree
Best for: Missing DLLs. Wrong CPU type. Broken app packaging.
Dependencies is a modern replacement for the old Dependency Walker. It scans an EXE or DLL and shows what it needs to load. Think of it as a family tree for app files.
This is useful for Visual C++ runtime problems because many apps depend on specific DLLs. Some need 32-bit files. Some need 64-bit files. Some ship with private DLLs in their own folder. Some do not ship enough.
Open the app’s EXE in Dependencies. Look for red or missing entries. Also check if the app is x86 or x64. That matters. A 32-bit app needs 32-bit runtime files, even on 64-bit Windows.
Dependencies is clean and visual. It can quickly answer questions like:
- Is a DLL missing?
- Is the wrong bit version being used?
- Is the app loading something from a strange folder?
- Does the app need a runtime package you do not have?
Quick comparison
| Tool | Best Use | Main Weakness |
|---|---|---|
| Event Viewer | Fast crash clues | Logs can be vague |
| Process Monitor | Finding missing files and access issues | Too much data if not filtered |
| Dependencies | Checking DLL requirements | May not show every runtime issue |
Which one should you use?
If you are helping a normal user, start with Event Viewer. It is already on the machine. It gives a quick clue.
If the app still fails and the clue is weak, use Process Monitor. It shows what Windows tried to do right before things went sideways.
If the error mentions DLL files, or the app is portable, use Dependencies. It is the best pick for missing runtime pieces and bitness mix-ups.
Here is the simple rule:
- Crash with no detail? Event Viewer.
- File not found? Process Monitor.
- DLL problem? Dependencies.
Final pick
Use all three if the problem is stubborn. They each show a different part of the mess. Event Viewer tells you what crashed. Process Monitor shows what the app tried. Dependencies shows what the app needs.
That combo beats random reinstalling. It is faster. It is cleaner. And it saves you from the classic “try rebooting again” loop.