Applications that crash, hang, or will not install at all

Why this matters

Application faults are the highest-volume software ticket there is, and they have a reputation for being unsolvable — the application misbehaves, the vendor blames Windows, Windows blames the application, and the fix becomes "reinstall it and hope".

In fact most of them fall into four categories with specific tests: a compatibility problem, a permissions problem, a damaged installation, or a problem with the user's profile rather than the machine. Each has a test that takes two minutes, and running the four tests in order resolves the great majority without reinstalling anything.

The lesson

Compatibility: architecture, framework versions, and the runtime that is missing

Compatibility failures are the ones that look mysterious and are not.

Architecture. A 64-bit application will not run on a 32-bit system. A 16-bit installer will not run on a 64-bit system at all, which catches very old software whose application would have been fine. The symptom is a refusal at launch or an installer that closes instantly.

Framework and runtime versions. A great deal of software depends on a runtime — .NET, a Visual C++ redistributable, Java, a specific runtime library. When one is missing or the wrong version, the symptoms are: an error naming a .dll, a crash immediately at launch, or an installer that fails near the end. The fix is installing the runtime the vendor names, and the trap is that several versions coexist and are not interchangeable.

Operating system version. Software may require or refuse a version. Compatibility mode — the application's properties, Compatibility tab — makes it report an older version and can resolve genuine refusals. "Run as administrator" is on the same tab and solves a related class.

The test: does it run on a different machine of the same build? If yes, the machine is at fault; if no, the software and this Windows version are at odds and the answer may be a virtual machine running the older version, which is a legitimate and frequently correct answer.

Permissions and installation failures, including the folder nobody may write to

Permissions cause installation and runtime failures that look like corruption.

Installation failures:

• No administrative rights. Most installers write outside the user's profile. The prompt appearing and being declined, or an installer run by a standard user with no prompt at all, produces a partial or refused installation.
• A folder nobody may write to. Installing to a location with restrictive permissions fails part-way, leaving a broken installation that is not obviously broken.
• Security software blocking the installer or quarantining a component mid-installation, which produces a "successful" installation missing a file.

Runtime failures:

• An application writing to its own folder in Program Files — common in older software — fails silently or is redirected. The redirection is the trap: the write succeeds into a per-user copy, the application is content, and nobody can find the file. A setting that "does not save" for one user is frequently this.
• An application needing access to a folder, a share, or a device the user cannot reach.

The tests, in order: run it elevated once and see if the behaviour changes; check whether the installation folder's permissions are unusual; and check the security software's quarantine and block history for the application's files. That third one is worth reaching for early, because it produces symptoms that look exactly like a damaged installation.

Repairing, reinstalling and removing properly, and the leftovers that matter

Three operations exist and they are not the same, which matters because the cheapest one is frequently sufficient.

Repair. Offered by many installers, from Programs and Features or from the installer itself. It verifies and replaces the installed files without touching settings or data. This is the correct first move for an application that launched yesterday and does not today, and it takes a fraction of the time of a reinstall.

Reinstall. Uninstall, then install. It replaces the program and — depending on the software — may leave settings behind, which is either helpful or exactly the problem.

Remove properly. The part that matters when a reinstall does not help. Uninstallers routinely leave behind:

• Configuration in the user's profile — AppData on Windows, the Library folder on macOS. A corrupt configuration file survives a reinstall, which is the single most common reason "I already reinstalled it" did not work.
• Registry entries.
• Services and scheduled tasks.
• Drivers.

So the sequence for a stubborn application is: repair; reinstall; reinstall after renaming its profile configuration folder. That last step is safe if you rename rather than delete — the application creates a fresh one, and the old settings are recoverable if the fault turns out to be elsewhere.

Vendor-supplied cleanup tools exist for large applications and are worth using when the ordinary uninstall leaves something behind that blocks a fresh installation.

A profile-specific fault, and testing with a second account to prove it

This is the two-minute test that decides whether you are fixing the machine or the user's profile, and it should be run early because it eliminates half the search space.

The test: create a local account, sign in to it, run the application.

• Works in the new profile → the fault is in the original user's profile: a corrupt configuration file, a per-user registry setting, a per-user startup item, or profile corruption.
• Fails in both → the fault is machine-wide: the installation, a system component, a driver, or policy.

That single result changes everything that follows, and it takes less time than reading a forum.

When the profile is at fault, in increasing order of cost:

1. Rename the application's configuration folder in AppData and let it rebuild.
2. Check per-user startup items and scheduled tasks.
3. Reset the application's per-user settings through its own interface.
4. Create a new profile and migrate the user's data into it, which is a real job and should be a considered decision rather than a first move.

Two notes. Rename, never delete, so the original settings can be restored if this was not the cause. And a profile fault that recurs after a rebuild suggests something external — a roaming profile, a policy, or a synchronisation client — rather than bad luck.

Reading an installer log far enough to find the actual line

Installer logs contain the actual reason and are usually ignored because they are long. Reading one properly is a genuinely useful skill and takes about two minutes.

Where they are: Windows Installer packages log to the temp folder, and can be made to log verbosely with msiexec /i package.msi /l*v install.log. Many vendors write their own log next to the installer or in the temp folder. Windows setup writes to C:\$WINDOWS.~BT\Sources\Panther.

How to read one:

• Go to the end first. Installers roll back on failure, so the last few hundred lines contain the failure and the rollback.
• Search for Return value 3 in a Windows Installer log. That is the conventional marker of the action that failed, and the lines immediately above it name what it was doing.
• Search for error, failed and cannot, then read the surrounding ten lines rather than the matched line alone.
• Look for a path or a file name near the failure. The reason is very often a specific file it could not write, a service it could not stop, or a registry key it could not open — all of which point straight at permissions or at something holding the file.

The common findings: a file in use, which means closing something or restarting; a permissions denial on a folder; a prerequisite missing; and insufficient disk space. All four are quick fixes once named, and all four are invisible from the installer's own error dialog, which says only that the installation failed.