Software · Troubleshooting guide
Software — Installs, Crashes and Programs That Suddenly Misbehave
46 focused fixes in 8 groups · Windows 10/11, macOS and Linux · about 35 minutes to work through
A program that suddenly won't install, crashes the moment you open it, or quietly stops doing what it used to rarely announces why. Most of the time the cause sits in one of a handful of places: a missing supporting component, a permission the app can't get, an update that changed something underneath it, a security tool that has decided the app is a threat, or a settings file that has gone bad. The good news is that these causes have predictable fingerprints, and once you can tell which fingerprint you are looking at, the fix is usually straightforward.
This guide collects forty-six focused fixes into eight groups, ordered the way software problems usually reveal themselves: first the installation, then the crash, then the update, the permissions, the missing pieces, the settings, the resources, and finally the deeper diagnostics. Work through the group that matches your symptom. Each section tells you what the problem looks like, what to check first, what a safe fix is, and where to stop if the fix is beyond a casual user — and nothing in it asks you to disable your security software permanently or to download mysterious repairs. Where an action carries risk, it says so before you take it.
Quick reference
Use this table to jump to the most likely section. If your symptom isn't listed, the diagnostic checklist below will point you in a direction.
| Symptom | Likely direction | First check | Topics |
|---|---|---|---|
| Installer fails or aborts | Permissions, dependency, or a corrupt download | Re-download; run the installer elevated | 01, 04 |
| App crashes right after opening | Missing runtime, damaged install, security block | Read the error; check the event log | 07, 24 |
| App crashes after a while | Memory growth, heat, or the GPU under load | Watch its resources while it runs | 08, 40 |
| "Not Responding" / frozen window | Waiting on disk or network, or a corrupt setting | Check disk usage; reset app settings | 09, 30 |
| Worked yesterday, fails today | An update or a security change | Find what changed, and when | 11, 18 |
| Error naming a missing file | A missing DLL or runtime | Read the file name; install the component properly | 24 |
| "Windows protected your PC" | SmartScreen reputation check | Confirm the publisher before running | 22 |
| Fails for one account only | That profile's settings or data | Test a fresh user account | 32 |
Start here
Eight steps that resolve most software problems in the order they should be done. Each one is cheap, and each rules out a layer of possible causes.
- Write down the exact error. The wording — and any file or code names — matters more than it looks. Vague errors hide specific ones.
- Pin down when it started. After an app update? A Windows update? A new program installed? The date is half the diagnosis (11).
- Update the app, the OS and the graphics driver if the app is graphical. Many "mysterious" failures are simply an outdated piece (40).
- Try the vendor's repair option if one exists — it fixes damaged files and keeps your settings (15).
- Test a fresh user account to rule out profile and settings problems (32).
- Check the logs for the exact failure — the event log names the component that actually failed (43).
- Do a clean reinstall from the official source if the repair didn't hold (05, 44).
- If it still fails, gather the details and go to the vendor with versions, steps and the log entry (46).
Diagnostic checklist
Tick the symptoms that match your situation. The suggestions below point at the topics most likely to contain your fix — a starting point, not a verdict.
Tick at least one symptom to see suggested topics.
The failure map: an application sits on top of six layers. Most software problems live in exactly one of them — this guide walks through all six.
Installing and removing software
Installation problems are the front door of software trouble. A failed install can disguise itself as a hundred different things later — a crash on first launch, a missing file, a program that "works but not right" — so getting the install right, or knowing exactly why it failed, saves hours downstream. These six topics cover the install itself: why it won't start, why it dies partway, what an error at the end actually means, and how to reinstall or remove software cleanly.
Software won't install at all
The most common version of this is an installer that starts, shows a progress bar for a moment, and then stops with a message that it cannot continue — or one that refuses to start at all. In most cases the installer is not broken; it has hit a condition it cannot get past on its own. The three most frequent blockers are a permission the installer does not have, a piece of security software blocking it, and a missing prerequisite the installer assumes is already present.
Start by running the installer as an administrator and watching for the first exact message — a vague "installation failed" hides a specific reason underneath. If it still will not start, add a temporary exclusion for the installer in your antivirus (topic 21 explains how to do that safely) and check the application's requirements page for anything you need to install first. If the installer is a file you downloaded, delete it and download it again from the official site: a corrupt download is a surprisingly common cause, and the re-download takes a minute. If none of that works, the next step is reading the installer's own log, or the system event log (43), which usually names the exact file or step that failed.
The installer closes or aborts unexpectedly
An installer that simply vanishes — no dialog, no error, the window just gone — is usually one of two things: a silent crash in the installer itself, or an installer waiting for something that never appears. Installers are small programs, and like any program they can crash, most often because of a missing component they depend on or because they were started from a location they do not like — a network share, a read-only folder, or a path with unusual characters.
First, copy the installer to a plain folder (for example C:\Install) and run it from there as an administrator. If you downloaded it, download it again — a truncated file is a classic cause of silent failure. Check the system event log for a crash entry at the moment it closed (43); if the installer itself is reporting a crash, that points at a missing runtime or a blocked component. As a last resort, some vendors offer an advanced or command-line install mode that shows more detail; the vendor's support page will say whether theirs does. And if the installer crashes on every machine you try it on, that is a vendor problem rather than a machine problem — worth reporting (46).
The installation gets stuck
A progress bar that sits at the same percentage for what feels like an hour is not always a hang. Some installers genuinely spend a long time on one step — downloading components, copying a large number of files, or waiting on a background service — and the progress indicator simply does not reflect that. Before assuming it is stuck, give it real time: for a large application on an older hard drive, ten to twenty minutes on a single step is not unusual.
While you wait, check what the installer is actually doing. Open the task manager and look at disk activity: if the disk is working, the install is probably progressing; if nothing is moving at all, it may be waiting on something invisible — a dialog hidden behind another window, a security prompt on another session, or a reboot it cannot schedule. Look for a small window or notification you may have missed, and make sure no other installer or operating-system update is running at the same time. If the disk is idle and there is no hidden prompt after a long wait, cancel cleanly (use the installer's cancel option rather than killing the process), remove what it left behind (06), and retry — often from a fresh download.
The installer fails with an error message
An error at the end of an install is the most useful kind of failure, because it is telling you something specific — you just have to read it. Windows installers typically report a code (a string of hex digits) plus a short description, and the description is the part to act on. "Access is denied" means a permission problem (19); "file in use" means something is holding the file open; a message naming a specific component means that component is missing or damaged.
Write the exact code and text down before you do anything else — it is the single most useful fact for both self-help and vendor support. Look the code up on the vendor's site first (vendor error pages are more accurate than generic search results for their own installer), and check the installer's log file if it writes one — many Windows MSI installers do, usually under the temp folder. The fixes that resolve the most install errors are unglamorous: install the missing prerequisite, close the program that is holding the file, run the installer elevated, or clear out a half-finished previous install before retrying. If the same error appears on a clean machine, the problem is with the installer package itself, and the answer is a new download or a call to the vendor.
Reinstalling software properly
A reinstall fixes a surprising number of software problems, but only when it is a real reinstall. The most common mistake is running the new installer over the old installation and calling it done — if the old install is damaged, the new one often inherits the damage. A proper reinstall removes the old application completely, clears what it left behind, and installs a fresh copy from a known-good source.
The sequence that works: uninstall through the normal remove-apps flow, let the machine restart if the uninstaller asks, then look for the application's leftover folders — its program folder, and its data folders in the user profile (topic 06 explains where to look and what is safe to delete). Download the installer from the official site rather than reusing the old file, and install it for a single user first before letting it start with Windows. If the application stores documents or license data, note where they live before you start, because a clean reinstall removes the app's data folders too. If the problem survives a genuinely clean reinstall, that is important information in itself: it means the cause is in the operating system, a driver, or a dependency — not in the app's files.
Completely removing a damaged installation
When an uninstall fails halfway, leaves a phantom entry in the program list, or the app is so broken it will not even open its own uninstaller, you need to remove it properly before anything else will install cleanly. The safe order is to remove as much as the system will remove, then deal with the residue deliberately — not to start deleting program folders by hand as a first move, because some applications register components that a manual delete will not clean up.
Start with the standard Remove apps / Programs and Features flow. If the entry is there but the uninstaller crashes, try the vendor's own repair or uninstall tool, which is often more robust than the built-in one. What usually remains after that is folders: the program folder, and the application's data and settings folders in the user profile — on Windows typically under %LOCALAPPDATA% and %APPDATA%, on macOS under the user's Library. Inspect each folder before deleting: if the app keeps documents, licenses or saved work in its data folder, move those somewhere safe first. A reboot after a messy uninstall picks up pending file operations, and a clean install afterwards (05) confirms the removal worked. If entries keep reappearing or files refuse to delete, that is a sign of something more entangled — the clean-reinstall procedure in topic 44, or vendor help in topic 46, is the better route.
Crashes and freezes
Crashes and freezes are the most common complaints this site handles, and the most worth diagnosing properly, because the timing of the failure tells you a great deal about its cause. A program that dies at launch is a different problem from one that dies after an hour, and the fixes barely overlap. Work through this group using when-it-happens as your map, and keep a note of any error text — crash dialogs are full of clues that are easy to dismiss.
The app crashes right after opening
A crash at launch is usually a missing or broken part, not a broken app. The most common causes are a missing runtime or system component the app expects to be present, an installation that is incomplete (a file that never copied), a security product that kills the process at start, or a graphics driver that chokes on the app's first drawing calls. The pattern to look for: it happens every time, immediately, and the same way — that consistency is the good news, because it means the cause is consistent too.
Read the crash dialog if one appears — the name of a missing file is a direct pointer (topic 24 if it names a .dll). Then check the two most likely quick fixes: make sure the app is fully and recently installed (a repair, topic 15), and check that your graphics driver is current if the app does any serious drawing (40). If the crash is silent — no dialog at all — the Windows event log records it with a faulting module name, which is the closest thing to a free diagnosis you will get (43). If a fresh, fully updated install in a clean user account (32) still crashes at launch in the same way, the cause is almost certainly a dependency or a driver, and the log entry will tell you which.
The app crashes after a few minutes
A program that runs fine and then dies — after ten minutes, after an hour, after a large task — is a different class of problem from one that dies at launch. The usual suspects here are resources and heat: an app that slowly leaks memory climbs until the system has to stop it, a laptop that throttles under sustained load can take applications down with it, and graphics drivers are well known for failing under sustained video or 3D work while remaining fine for everyday use.
The diagnostic is to watch it die. Open the task manager and watch the app's memory and CPU over the session: a memory figure that climbs steadily and never comes down points at a memory problem in the app (topic 37); a CPU pinned near the top while the machine gets warm points at load or thermal issues (36, and heat is covered in the slow-PC guide). Note what you were doing when it crashed — a specific action that always triggers it is a reproducible bug, and it is exactly what a vendor needs to know (46). If the crashes tie to video playback or games, test with the application's hardware acceleration turned off (40): if they stop, the graphics path is the cause, and a driver update is the first fix to try.
The program freezes or becomes unresponsive
A freeze — the window goes blank, the title bar says "Not Responding", clicks do nothing — is not always a crash waiting to happen. Some freezes are the app genuinely blocked: waiting on a disk that is maxed out, waiting on a network it cannot reach (cloud-based apps will sit patiently for a very long time), or deadlocked between two of its own components. Others are the app working so hard on one thing that it cannot process your clicks — a performance problem wearing a freeze's clothes.
First, rule out the waits. If the app is cloud-connected, try it offline or on a known-good connection. If the whole machine feels heavy at the same moment, look at disk and CPU: a disk stuck near 100% will freeze almost any program that reads from it (the storage topics in the slow-PC guide apply). Then try the app-level resets in order: restart the app, reset its settings (topic 30), and clear its cache (31) — a corrupt configuration file is a classic cause of freezes that start at a predictable point. If the freeze only happens with one specific file or project open, the file is your suspect, and opening that same file with another copy of the app — or on another machine — will confirm it.
The program opens and then disappears
An app that flashes open and vanishes, leaving nothing but a taskbar ghost or nothing at all, has usually crashed before it finished drawing its window — but there are two innocent explanations worth checking first, because they are trivial to fix. The first is that it is not gone at all: some programs start minimised to the system tray rather than to a window, and a second instance of an already-running program may do the same. The second is that it opened, did its job (an updater, a maintenance tool), and closed itself by design.
Check the tray and the full process list before assuming a crash: if a process for the app is sitting there, the "disappearance" is display or single-instance behaviour, and the vendor's settings usually have an option to show the main window. If there is no process, it crashed at start, and topic 07 is your map — the event log will have recorded the crash with a faulting module. Two causes deserve a special mention for this symptom: a security product terminating the process at launch (check its quarantine or block history), and a damaged installation where the app's main window file is missing (a repair or clean reinstall, topics 15 and 05). If it happens on one account but not another, jump to topic 32, because that pattern almost always means the problem lives in the profile, not the program.
A program that suddenly stopped working
The phrase "it worked yesterday" is a diagnosis in itself: something changed, and the change is findable. In the large majority of these cases the change is one of a handful of things — an operating-system update, an app update that arrived in the background, a driver update, a security-definition update that newly flags the program, or a setting that got reset. The application itself is often perfectly intact; it has simply lost a piece of the world it was depending on.
Work backwards from "yesterday". Check what updates landed when the problem started — the OS update history, the app's own update log, and your security software's activity log are the three places to look (topic 18 covers the Windows-update case in depth). If a security update is the trigger, the app's entry in the security product's history will show the block and give you a legitimate "allow" action (21). If an app update is the trigger, you may be able to roll it back or wait for a fix (14). And if nothing on your machine changed, consider what changed around it: a new program installed at the same time is a prime suspect for conflicts (41). Writing down the exact date the behaviour changed is the single most useful fact you can gather — for yourself, and for any vendor support (46).
An app that worked before but doesn't now
This is the quieter cousin of the sudden-stopped-working complaint: the app opens and does something, but not what it used to — a feature is gone, a file it used to open now misbehaves, a setting has reset. Because the app still runs, it is easy to write off as "just buggy", but the pattern is usually a specific, reversible change: an update that altered a feature, a configuration that got corrupted, a file association that got stolen by another app, or a dependency that quietly changed underneath it.
Start by pinning down what exactly changed in the behaviour — "it doesn't work" is not enough; "it used to open this file type and now asks me to choose a program" is actionable (that one is a file-association problem, topic 33). Then check the three reversible suspects in order: an app update (roll back if you can, 14), the app's own settings (a safe reset, 30), and any recent change on the machine that touches the same files or features (a new app, an OS update, a driver). If the behaviour change started at the same moment as a Windows or app update, treat it as that update's regression: check the vendor's notes for a known issue, and if it is a deal-breaker, the vendor is the right place to raise it, with the date and version details in hand (46).
Updates and compatibility
Updates are the most common cause of "it was fine and now it isn't", and compatibility is the most common cause of software that never quite fits. This group covers the moving parts: app updates and how to live with a bad one, the repair tools that vendors and the operating system provide, the 32-bit/64-bit question, compatibility mode, and the specific headache of a Windows update breaking an application.
An app update broke functionality
Application vendors ship updates constantly, and most are fine — but when one lands and a feature you rely on stops working, the first instinct is to blame the app, when the useful question is what the update changed. Updates break things in a few predictable ways: a feature is moved or renamed, a setting is reset, a file format changes, or a dependency is swapped for a newer one that behaves differently. Each of these has a different fix, so identifying which one you have is half the solution.
Start with the vendor's release notes for that version — they are the fastest way to learn whether a feature moved or a known bug shipped. If a setting disappeared, a settings reset or a restore from a backup of the app's data folder usually brings it back (topic 30). If the app now needs a component it did not before, the update's requirements page will name it (topic 25). And if the version simply does not work for your use case, the practical answer is often to hold the previous one: many vendors still offer older installers on their download page or on request, and pinning a known-good version is a legitimate long-term strategy (14). What you should not do is start uninstalling system components to "fix" an app update — the breakage is in the app's layer, and the fixes stay in the app's layer.
Rolling back a problematic update
Rolling back — returning to the previous version of an application — is the most direct answer to a bad update, but it is not always available, and it carries one important catch: if the newer version saved your data in a new format, the older version may not be able to read it. So the order of operations matters. First, check whether the vendor offers the previous version (their download page, an archive, or support). Second, find out whether your data was touched by the new version. Only then install the older one.
For many modern applications, the operating system makes this easier than it used to be: Windows can sometimes keep the previous version of a packaged app available, and some vendors' updaters have a "previous version" option built in. For classic desktop software, a rollback is usually just "uninstall, then install the older installer" — which is really a clean reinstall (topic 05) pointed at an old file. Two cautions: do not mix and match files from two versions (that is how you create a worse, half-and-half installation), and if you rolled back because of a crash, keep the crash details (topic 43) so you can report the new version's bug and get a fixed build (46). If the vendor has already published a fix for the broken update, of course that is the better destination — the rollback is the bridge, not the destination.
Repairing an installed application
Before reaching for a full reinstall, it is worth spending ten minutes on the repair options, because a repair fixes a large share of damaged installations and leaves your settings and data exactly where they are. Windows provides two: the built-in repair for many classic (MSI-based) programs, found on the program's entry in the Remove apps list, and a per-app "Advanced options → Repair / Reset" for Store-style applications. Many vendors also ship their own repair mode inside the installer.
Try the options in this order: the vendor's own repair first (it knows the app best), then the built-in Windows repair, then a reinstall. A repair works by re-copying the application's files over the existing installation while keeping your configuration — which is exactly what you want when the files are damaged but the settings are fine (the mirror image of topic 29, where the settings are the problem). If a repair is offered but does nothing, or the program entry has no repair option at all, that tells you the application was not installed in a way that supports it, and a clean reinstall (05) is the honest equivalent. If the problem comes straight back after a successful repair, the cause is not in the app's files — look at dependencies, permissions, or the profile instead.
32-bit and 64-bit compatibility
The 32-bit/64-bit question shows up as installs that refuse to run, apps that run but hit a wall, and installers that simply do not start. The rules are simpler than they look: a 64-bit version of Windows can run both 64-bit and 32-bit programs (the system quietly supplies the glue), while a 32-bit version of Windows can only run 32-bit programs. And a 32-bit program, even on a 64-bit system, can only address a limited amount of memory — which is why an old 32-bit app can feel cramped in a modern workload while a 64-bit build of the same app does not.
The first step is to know what you have, on both sides. Check the operating system's architecture (on Windows, Settings → System → About says "64-bit operating system"; the command below shows the same), and check the app: the vendor's download page usually offers both builds, and an installer that refuses to run on a modern 64-bit system is very often a very old installer that current Windows no longer supports. If you are choosing a build to install, take the 64-bit version when your system is 64-bit and the app offers one — it is the one that will use your memory properly. The one trap to avoid: a 32-bit application and a 64-bit version of a plugin or component will not fit together, and "the plugin works but the app cannot see it" is usually an architecture mismatch, not a bug.
wmic os get osarchitectureUsing Windows compatibility mode
Compatibility mode is Windows' way of pretending to be an older version of itself for one specific program, and it is the last surviving tool from the era when new operating systems broke old software. It can still be the answer for a genuinely old application that predates the Windows version you are running — an installer or a utility from a decade ago that fails in a way that smells like "this OS is too new". It is worth a five-minute try because it is completely reversible. It is not a general fix for modern software, and it will not paper over a missing dependency or a damaged install.
To use it, right-click the program's shortcut or executable, choose Properties, open the Compatibility tab, and select "Run this program in compatibility mode for" an older version of Windows — start with the version the software was designed for, not the oldest one available. A few related options on the same tab are worth knowing: "Run this program as an administrator" (a targeted version of topic 20), and options for colour depth or fullscreen behaviour that occasionally save an old game. Judge the result honestly: if the app now installs or runs, good — the setting sticks to that one shortcut, so nothing else is affected. If it does not help, turn it off again (a compatibility setting that does nothing but add a layer of emulation is worth removing) and move on to the dependency and repair topics, which are where the real fix usually is.
Software that fails after a Windows update
Operating-system updates are the most common "it was fine yesterday" trigger, and they break apps in a few specific ways rather than at random: a driver is updated alongside the OS and the app depends on it, a security behaviour changes and now touches the app, a system component the app leans on is altered, or the update simply contains a bug that a later update fixes. The important distinction to make early is whether the app fails because of the OS change, or because the update also pushed new versions of the app or its drivers — those have different owners and different fixes.
Work the three layers in order. First, the app layer: check whether the vendor has published a note about the Windows update (they usually do, quickly, for common software), and update the app — a vendor fix is the cleanest resolution by far. Second, the driver layer: if the failing app is graphics- or device-related, update the relevant driver from the hardware manufacturer (40 for graphics). Third, the OS layer itself: make sure you are on the latest Windows build, because update regressions are frequently fixed by the very next update. If the breakage is severe and recent, Windows keeps restore points around major updates, and rolling back to the one before the update is a legitimate, reversible option — but it is a big move, so back up first and understand that it reverses the OS, not just the app. If none of that resolves it, the vendor needs the Windows build number and the crash details (46).
Permissions and security
This group covers the layer where the operating system and your security tools decide what an application is allowed to touch. It is also the layer where the tempting fixes ("just disable the antivirus", "just run everything as admin") do the most damage if applied casually, so each topic here includes the safe version of the workaround and the line you should not cross.
Access denied and permission problems
"Access is denied" is the system's way of saying an operation is being blocked by its permission rules, and in software problems it shows up in three main places: an installer that cannot write where it needs to, a program that cannot save its settings, and a program that cannot read or write a file it used to own. The underlying reason is usually one of a small set: the action needs administrator rights and was not given them, a security product is intercepting it, the file is in use, or a folder's ownership got tangled up by an earlier failed install.
The first moves are the safe ones. Run the operation as an administrator (topic 20 explains when that is appropriate), close any program that might be holding the file, and check the security product's block history — a silent permission block is exactly the kind of thing it records. For settings that will not save, the cause is often that the application's data folder ended up owned by a different account or marked read-only; the targeted fix is to correct permissions on that one folder, not to change permissions across a whole drive. Two things to avoid: do not take ownership of system folders as a general fix (it untangles nothing and risks breaking other programs), and do not permanently lower your system's permission settings to make one app happy — that trades a software problem for a security hole. If permission errors persist on one specific path, the app vendor or a technician is the better next step than deeper permission surgery.
When (and when not) to run software as administrator
"Run as administrator" is the fix that works often enough to become a reflex, and like most reflexes it is sometimes right. It is the correct tool when a program genuinely needs to install things, write to a protected location, or talk to a system component — which is true of most installers and of a handful of older utilities written before Windows enforced permissions the way it does now. It is the wrong tool as a standing solution: an everyday application that needs elevation to do its normal job is either misbehaving, misinstalled, or trying to do something it should not.
Use it in three situations: when running an installer (most system-wide installs expect it), when an application's documentation says it requires it, and as a short-term test to confirm that permissions are the problem — if the app works elevated but not normally, you have diagnosed a permission issue and can now fix it properly (topic 19) instead of living with the elevation. When to stop using it: for daily apps like a browser or office suite, for anything that asks for it but the vendor does not document as needing it, and never as a way to keep a failing app alive while you skip the actual diagnosis. One caution that matters: running a program elevated gives everything it touches elevated reach, so only elevate software you trust and understand — elevation is a tool, and like every tool in this guide it amplifies what the software already is.
Antivirus and security software interfering with apps
Security software is one of the most common causes of software that installs wrong, crashes at launch, or "suddenly" stops working — and it is doing its job when it does. The interference usually takes one of three forms: the installer is blocked or modified mid-flight (which produces a damaged install that then misbehaves), a legitimate file is quarantined as a false positive (which produces a missing-file error, topic 24), or real-time scanning slows an app down enough to look broken. All three leave a trace in the security product's own history, which is the first place to look before you change anything.
The safe way to work with this is the exclusion, not the switch-off. If you suspect interference, open the security product's history or quarantine, and if it shows the app or its installer, restore or allow the specific item from there — that action is logged, reversible, and scoped to one file. To test whether the security software is the cause of an install failure, create a temporary exclusion for the installer's folder, run the install, and remove the exclusion immediately afterwards, whatever the result. Two firm rules: never permanently disable real-time protection "to make things work" — you can always allow a specific trusted file instead — and be extra careful about what you are allowing, because the same mechanism that blocks malware is how you keep it out, and a "false positive" you allow without checking the source could be a true one. If a reputable security product repeatedly flags the same file from an unknown source, the file is the problem, not the scanner.
Software blocked by Windows security (SmartScreen)
The "Windows protected your PC" screen is not an error — it is a reputation check. Windows compares the program you are trying to run against what it knows about, and software that is new, unsigned, or downloaded from a less-trusted place gets stopped at the door with a warning instead of a silent start. It fires most often on the first run of a newly downloaded program, on installers from small vendors, and on files that arrived by email or from a file-sharing site. Understanding what it is keeps you from treating a protection as a malfunction.
The right response depends on where the file came from, so decide that first. If you deliberately downloaded it from the vendor's official site and you recognise the publisher, the warning page has a "More info" link that reveals a "Run anyway" option — that is the legitimate path, and using it is a conscious, logged decision. If you do not confidently recognise the publisher, or the file arrived unsolicited, do not run it: move it aside, scan it, and get a copy from the official source instead. Two patterns are worth knowing. First, a program that was always fine suddenly getting flagged can mean a security update changed its reputation status — the vendor usually knows, and an updated, properly signed build clears it. Second, if many different new programs are all getting flagged at once, check that your system clock and Windows updates are current, because reputation checks depend on both.
Firewall-related application problems
Firewall problems have a distinctive signature: the software works, but it cannot reach what it needs — a cloud app that signs you in and then spins, a game that will not find servers, a printer app that sees the device on one computer and not another, a sync client that shows "offline" while the rest of the machine is online. The local part of the app is healthy; the path between it and the network is blocked. That signature is what separates a firewall problem from every other kind of software failure in this guide.
The first check is scope: does the rest of the machine have network access? If everything else works and only this app does not, the block is specific to the app, and the firewall's per-app list is the place to look. On Windows that is the "Allow an app through the firewall" setting, where each application has inbound and outbound entries — a missing or unchecked entry is the usual culprit, and adding or re-enabling the app's entry (after confirming it really is the app you think it is) resolves most cases. If the app needs to be reached from other machines on your network — a shared printer, a local server, a game host — the inbound direction is the one that matters, and it is also the one to be deliberate about, because opening inbound access is a real exposure decision. If the block appeared right after a Windows update or a security change, check the firewall's history for what changed; and if the app is blocked on every network you try, the vendor's documentation will name the ports it needs (topic 46 is a good place to ask).
Dependencies and components
A large share of "this software won't run" is not a problem with the software at all — it is a problem with the pieces the software expects to find already on the machine: runtimes, shared libraries, and supporting components. These are the quiet dependencies that a working installation assumes, and when one is missing or the wrong version, the app fails in a way that can look mysterious. This group covers the errors that point here, and the safe way to fill the gaps.
| Message you might see | What it usually means | Where to look |
|---|---|---|
| "[file].dll is missing" | The app's files are incomplete, or a component that provided it was removed | 24 — reinstall or install the real component |
| "Visual C++ Runtime is missing" | The C++ redistributable the app was built against is absent | 26 — install it from the official source |
| ".NET Framework [version] required" | A specific .NET runtime version is missing | 25 — install the named version |
| "Access is denied" (for example, error 0x80070005) | A permission or security block | 19, 21 |
| "Windows protected your PC" | SmartScreen reputation block, not a failure | 22 — verify the publisher first |
Exact wording varies between Windows versions and between applications; the pattern matters more than the phrasing.
Missing DLL errors
A dialog naming a missing .dll file is one of the most searched software errors there is, and it means exactly what it says: the application tried to load a library file and could not find it. The file can be missing for a few reasons — the application's own installation is incomplete, a component that used to provide it was removed or updated, a security product quarantined it, or (less often) something on the machine is genuinely damaged. The file name in the error is the most important fact on the screen: it tells you which component to look for.
The safe order of fixes starts with the application itself: a repair or clean reinstall (topics 15 and 05) restores the app's own files, which is the source of the missing DLL in the most common case. Check the security product's quarantine next — a quarantined DLL restored from there is a legitimate fix. Where people go wrong is the next step, so read this carefully: do not download the missing DLL from a random "DLL download" website and drop it into a system folder. Those sites are a well-known channel for malware, and a DLL of unknown origin that you place where every program can load it is a security decision, not a technical one. If the missing file belongs to a known component — a runtime, a vendor's shared library — install that component properly from its maker (topics 25 to 28). If the missing DLL is a core Windows system file, the operating system's own repair tools are the correct response (see the system-file section of the slow-PC guide), not a downloaded copy.
Missing .NET and other runtime dependencies
Many Windows applications are not self-contained: they are built on top of a runtime — a supporting layer like the .NET Framework or the .NET Desktop Runtime — that has to be present on the machine for the app to start. When it is missing, the app fails with a message to the effect that a required component is not installed, or it simply will not launch. This is a benign, completely fixable problem, and the reason it persists is that the required version matters: an application that needs a specific runtime version will not run on an older one, even if some .NET is installed.
The fix is to find out which runtime the application needs and install it from the maker's official distribution. The application's requirements page, or the error message itself, usually names the version; install that one. The reassuring part of runtimes is that versions coexist — installing a newer runtime does not remove or break an older one, which is why machines accumulate several over the years, each serving the apps that need it. Install only from the official source for the runtime, because a runtime is a deep, trusted component of the system and a fake one is a serious problem. If an app still will not start after the correct runtime is installed, the missing piece may be a different dependency — check the app's full requirements list, and look at the crash log (43) for what it is now trying to load.
Visual C++ runtime problems
The Visual C++ Redistributable is the workhorse dependency of a huge amount of Windows software — games, editors, utilities, installers — and its absence is a classic cause of an application failing at launch with a message about a missing C++ component or a specific runtime library. The reason the problem is so common is historical: the redistributable has existed in many versions over the years, and software built with one expects that version (or a compatible one) to be present, while a fresh operating-system install ships with none of them.
The fix is straightforward and official: install the Visual C++ Redistributable packages from the compiler vendor's support site. Two details save time. First, install the package that matches your application's architecture — a 32-bit application needs the x86 package even on a 64-bit system, and many machines need both, because they run a mix of 32- and 64-bit software. Second, the modern redistributables are cumulative: the current package covers a range of earlier versions, so installing the latest one usually satisfies several older requirements at once. After installing, restart the app (and the machine if you installed several at once). If an application still reports a C++ component missing after the correct redistributable is installed, the redistributable installation itself may be damaged — a repair of it from the same page is the fix — and if it is a core system file rather than a redistributable file that is reported missing, step back to topic 24 and the system-repair route.
Java and other runtimes
Java is the representative of a broader category: software that runs on a runtime you have to install separately, and that many modern operating systems no longer include by default. If an app built on Java (or on a similar runtime) will not start and the message mentions the runtime, the cause is usually simply that it is not there, or that the version present is not the one the application wants. The same pattern applies to other runtimes you may meet — script engines, media frameworks, language runtimes — and the handling is the same: identify, install from the official source, verify the version.
The practical steps: find out from the application which runtime and version it needs (its documentation or the error message), install that version from the runtime's official site, and confirm the installation — most runtimes have a simple "what version am I running" check. Unlike some components, multiple Java (and most runtime) versions can coexist, so installing what an app needs will not displace what something else uses. Two cautions specific to this category. First, keep runtimes updated through their own official channels, because runtimes receive security fixes — an old runtime is a known vulnerability, not just an old component. Second, be wary of "update Java" prompts that appear in browsers and on third-party download pages; install runtimes from the maker's site directly, the same rule that applies to every component in this group.
Software that requires older components
Occasionally the dependency problem runs backwards: the software is old and expects an older version of a component than the one your machine has — an older runtime, an older framework, or a component that a newer install replaced. The failure looks like a missing or incompatible component even though something is installed, and the confusion comes from the fact that "present" and "the right version" are different things. This comes up most with long-lived professional tools, industrial software, and older games, all of which are built against a specific set of components and do not always move forward cleanly.
The good news is that most runtimes and frameworks are designed to coexist, which means the fix is usually "install the older version alongside the newer one" rather than "downgrade the machine". Confirm from the software's documentation exactly which component version it needs, install that specific version from the official source (coexistence means you are not removing what your newer apps use), and test. Where coexistence is not possible — where the old component and the new one genuinely conflict — the honest answers are narrower: run the old software on a machine or a virtual environment that matches its era, follow the vendor's compatibility notes if they publish one, or accept that the software has reached the end of its supported life on your current system. In that last case this is a decision point rather than a fix, and the vendor (topic 46) is the right person to tell you whether a supported path exists.
Configuration and user profiles
Settings, caches, profiles, and associations are the soft layer of a software problem: none of it is the program's code, but all of it changes how the program behaves, and all of it can go bad. The advantage of this layer is that it is also the safest to work on, because the fixes — resetting a setting, clearing a cache, testing a fresh profile — are reversible and scoped to the app. Learn where each piece lives and you can fix a surprising number of "it works for my colleague but not for me" problems.
Corrupted configuration files
Every application that remembers anything — your window size, your last folder, your preferences — stores that memory in configuration files, and like any file they can become corrupted: truncated by a crash, tangled by a failed update, or left half-written after a power loss. The symptoms are characteristically odd rather than catastrophic: a setting that will not stick, an app that opens to the wrong state, a feature that behaves as if it has amnesia. The application's code is fine; its memory is not.
The safe diagnostic is the rename test. Find the application's configuration folder (the box below shows the usual locations), and rather than deleting anything, rename the folder — add ".old" to its name. Then start the app: with its old settings unreachable, it will recreate a fresh, default configuration. If the app now behaves, you have confirmed a corrupt settings file, and you can compare the old folder against the new one to rescue individual settings you care about. If the app still misbehaves with brand-new settings, the cause is not its configuration — rename the folder back and move on, having gained real information. Deleting is never the first move here: renaming costs nothing and loses nothing.
Where application settings usually live
Windows — typically a folder named after the app or its vendor under %APPDATA% (roaming settings) or %LOCALAPPDATA% (per-machine settings). Type either variable into the File Explorer address bar to jump there.
macOS — under the user's Library folder, usually ~/Library/Application Support or ~/Library/Preferences. It is hidden by default; in Finder, use Go → Go to Folder.
Linux — most desktop applications use ~/.config (XDG convention), though the exact folder varies by application and sometimes by distribution packaging.
Resetting application settings safely
A settings reset is the middle path between "live with the broken behaviour" and "wipe the app's data" — it returns the application's preferences to defaults while (in most apps) leaving your documents and core data alone. It is the right tool when a feature stopped working after a setting changed, when an update reset some things and not others, or when the app's behaviour has drifted into a state none of your settings seem to control. Before you reset, note what you are resetting: in some applications "reset" means preferences only, and in others it means everything the app owns.
Use the app's own reset first — most serious applications have one, usually under Settings or Help, and it knows exactly which files are safe to touch. If the app has no reset, the rename test from topic 29 achieves the same result reversibly. For Store-style apps on Windows, the system provides a Reset action in the app's Advanced options that does this cleanly. Two precautions: if the application manages anything you cannot recreate — a mail store, a project database, saved game state — confirm that a settings reset will not touch it before you run one, and read what the reset button actually says rather than assuming. And after a successful reset, take a moment to note the settings that fixed the problem, because "I changed something and it worked" is not a setting you can reproduce next time.
Clearing application cache safely
An application cache is a pile of temporary working files — thumbnails, downloaded fragments, session data — that the app builds to work faster and is supposed to be able to discard. Caches are meant to be throwaway, and in a healthy app clearing one is harmless: the app rebuilds what it needs, at the cost of being slower for a while. Caches become a problem when they grow without bound (a performance drag, topic 37) or when a cached item goes stale or corrupt and the app keeps trusting it (a behaviour bug that survives restarts).
The safe approach is to clear the cache the app provides for, not to go hunting through its folders. Most applications with a meaningful cache expose a "Clear cache" action in their settings — use that first, because it knows which folders are genuinely disposable. If the app offers no such control, the rename test (29) applied to the app's cache or data folder achieves the same result reversibly. The one category to treat carefully: some applications keep things in their data folder that are not caches at all — message stores, offline files, databases of your content — and clearing those is not "clearing a cache", it is deleting data. If you are not certain what a folder contains, its size and its growth pattern are clues (a cache grows and shrinks; an archive only grows), but when in doubt, move the folder aside rather than delete it, and only remove it once the app has proven it rebuilds what it needs.
Problems limited to one user account
If a program works for one person on the machine and not another — or worked for you before and now only fails in your account — you have already done half the diagnosis. The conclusion is that the problem is not in the program's shared files (those are the same for every account) but in something that is per-user: the account's copy of the app's settings, its caches, its credentials, or the profile itself. That narrows a vague "the app is broken" down to a specific, fixable location.
The cleanest test is a fresh local user account: create one, sign in, and run the application. If it works in the new account, the damage is confirmed to be in the old account's data, and the fix is the rename test (29) or a settings reset (30) aimed at that app's per-user folders. If it fails in the new account too, the problem is system-wide after all — an installation, a driver, a dependency — and you should work the crash and dependency sections instead. Two notes on the per-user case. First, check what the failing account has that the working one does not: a different security policy, a redirected folder, a sync client that only runs for one user — per-user software is a common hidden variable. Second, if the new account works but you cannot bring your settings across, that is the point to be surgical: copy individual settings files from the old app folder to the new one, testing after each, rather than restoring the whole folder and importing the corruption with it.
File association and default application problems
File associations are the operating system's answer to "what program opens this file?", and they are a small, fragile piece of state: change one association and a file type that always opened in the right place now opens nowhere, or in the wrong app, or with a prompt you never asked for. The problem usually arrives after an update — an app update that re-claims the file types it handles, a new app that grabs types it should not, or a system update that resets associations to a default you did not choose.
The fix lives in the operating system's default-applications settings, not in the applications themselves. On Windows that is Settings → Apps → Default applications, where you can set the default program for an app or, more precisely, for an individual file type; the "Open with" choice on the file itself does the same for one type at a time. Set the association to the program you actually want, and verify by double-clicking a file of that type. If the association keeps getting stolen back — the wrong app re-claims it after its updates — that is the app behaving badly, and the durable fixes are to update that app (a fixed version may stop re-claiming), to disable its "manage file types" behaviour if it offers one, or to report the behaviour to the vendor (topic 46). One related check: if the file opens in the right program but the program misbehaves with that file, the association is fine and the file or the program's handling of it is the problem — test the same file opened directly inside the program, and the same program with a different file, to split the two.
Broken shortcuts
A shortcut is a pointer, not a program: it stores a path to the real executable, and when software moves, updates into a new folder, or is reinstalled to a different location, the shortcut keeps pointing at the old address. The result is the classic "the program is installed but the icon does nothing", or an error naming a file you are quite sure you have. The app may be perfectly healthy — you are just knocking on the wrong door.
Confirm the diagnosis by finding the real executable. Open the program from its start-menu entry (which installers usually rebuild correctly even when the desktop shortcut is not), or browse to the program's install folder and run the executable from there. If it runs fine from the real location, the shortcut is the whole problem. Fix it by creating a fresh shortcut to the current executable — right-click the executable and choose to create a shortcut, then move the new one wherever the old one lived — and delete the broken one. Two variations worth knowing. If the shortcut opens the wrong program entirely, its target was repointed (by an update or another app), and the same fresh-shortcut fix applies. And if no shortcut works but the executable runs when launched directly from its folder, look at the shortcut's "Start in" folder setting — a missing working directory is a quieter cause of "it launches and immediately dies" than people expect.
Performance and resource problems
When a program's problem is that it is slow, hungry, or noisy in the background, the cause is usually a matter of resources: too much CPU, too much memory, a startup load that never settles, a service it depends on that is misbehaving, or a graphics path that is unstable. These problems are the most measurable of all — you can watch the numbers while the problem happens — which makes them some of the most solvable, if you watch at the right moment.
Software that fails to start with Windows
Some applications are set to start when the computer boots or when you sign in, and when they fail at that moment the failure is easy to miss — no window, no error, just a program that is not there when you expect it. Startup failures have causes that are specific to the boot moment: the program needs the network and the network is not up yet, it needs a service that has not started, it is waiting on a user action that never comes at boot, or it simply crashes during the crowded, resource-strapped first minutes after sign-in.
Start by confirming the startup entry exists and is enabled — on Windows that is the Startup apps view in Task Manager, and the app may have been disabled by an update, or by you, long ago, without anyone noticing. Then find out what it is doing at boot: if it is a background tool, check whether its process actually appears in the process list after sign-in (if it does not, it is crashing at start, and the event log will say why — topic 43). If it is a network-dependent app, the fix is often as simple as a delay or a retry, which some apps have as a setting. If the app works perfectly when you start it manually but fails at boot, that timing difference is the diagnosis: it is an ordering or readiness problem, and the options are a startup delay, starting it from a scheduled task after a short wait, or simply starting it manually — which, for many background utilities, is the honest best answer.
Software using excessive CPU
An application that pins the CPU — the fan spins up, the machine feels hot and slow, and the task manager shows one process at 80, 90, 100 percent — is either doing a lot of work it was asked to do, working far harder than it needs to, or stuck. The three look identical in the task manager and have different fixes, so the first job is to tell them apart: is the activity tied to something you are doing (a render, a search index, a large file operation), does it happen at idle, and does it ever stop on its own?
Work the three cases in order. If the CPU use is tied to real work, the fix is patience or a lighter workload — but check that the "work" is what you expect, because a background sync or indexer that has gone into a loop can masquerade as legitimate activity. If the app is hot at idle, update it first (a CPU bug is one of the things updates most often fix), then look at its settings for a background feature you can disable, and then test with its hardware acceleration off if it is a graphical app (topic 40) — a misbehaving software rendering fallback is a classic idle-CPU cause. If the high CPU is constant, total, and tied to a specific action that always triggers it, that is a reproducible bug and belongs with the vendor, with the trigger and a screenshot of the task manager as your evidence (topic 46). A machine-wide view helps here too: if everything is slow when the app is hot, the resource section of the slow-PC guide is the right companion read.
Software consuming excessive memory
Memory problems in a single application have a signature: the app's memory figure climbs over time and does not come back down. A little growth is normal — programs load what they need and keep it — but a number that rises steadily for the life of the session, past what the app's work justifies, is the classic memory leak, and it explains the "fine for an hour, then everything crawls" experience, because the operating system eventually has to make room by slowing everything down.
Confirm the pattern before you act: watch the app's memory over a normal session and note whether it settles at a level or keeps climbing. If it settles, the "excessive" memory is just the app's working set, and the answer is workload management (close what you are not using) or, for a genuinely memory-hungry line of work, more RAM. If it climbs without bound, the practical controls are in order: restart the app on a schedule (the boring, effective fix for a leak you cannot patch), update the app (leak fixes ship all the time), reduce what the app is holding (documents, tabs, projects open at once), and check that a companion process is not the real consumer — some applications run a second background process that owns the memory. If the climb is fast enough to be disruptive on current hardware, that is also a legitimate argument to the vendor (topic 46) and, in extreme professional cases, for the hardware upgrade that the slow-PC guide covers.
An app becoming slow after an update
When a specific application gets slow after its own update — while the rest of the machine is fine — the cause is inside the new version: a feature that now runs in the background, a setting that changed its default, a new dependency that is struggling on your hardware, or simply a regression the vendor has not fixed yet. The useful distinction from a machine-wide slowdown is that this one is bounded: it is this app, this version, and the fixes stay within the app's world.
Try the app-level levers in this order. First, its settings: new versions frequently add background activity (sync, indexing, previews) with a switch somewhere in the preferences — find and turn off whatever is new. Second, hardware acceleration, if it is a graphical app: a new version sometimes enables or changes acceleration in a way that is slow or unstable on particular graphics (topic 40), and toggling it is a two-minute test with a clear answer. Third, its cache and data: a new version meeting old cached data is a classic slow combination, and clearing the cache (31) or resetting settings (30) tests it. Fourth, the rollback (14), if the vendor offers the previous build and the slowness is a deal-breaker. If none of that helps, you are looking at a performance regression in the software itself — report it with the version number and what is slow, because the fix is the vendor's to ship (topic 46).
Background services that software depends on
A surprising number of applications are not self-contained programs: they are front ends for a background service — a separate process that does the real work and has to be running, started, and healthy for the app to function. Printers, virtualization, some security products, some database and development tools, and various vendor utilities all use them. When the service is stopped, disabled, or failing, the symptom on the surface is an app that opens and then refuses to do anything, often with an error about a "component" or "service" — and the application's own files are perfectly intact.
The way to see the layer is the system's service manager (on Windows, the services console, opened with the command below). Find the service that belongs to the application — it is usually named after the vendor or the product — and check its status and its startup type. The common states and their meanings: stopped (start it, and set its startup type to automatic if it is supposed to run with the system), disabled (something or someone turned it off — re-enable it, then find out what disabled it), or running but the app still fails (the service is crashing or stuck, and restarting the service — or the machine — is the test). One rule of caution that matters in this area: services are system-level, and stopping or reconfiguring one you do not recognize can affect other software or the operating system itself. Work only on the service that belongs to the app you are fixing, and if the service keeps crashing on its own, the event log (43) will show why, and the vendor is the right next stop.
services.mscGraphics driver crashes and hardware acceleration
Graphics drivers sit underneath a huge amount of software — browsers, video players, design tools, games — and when the driver has a bad day, the failures land on the applications above it: a browser tab that crashes during video, a design app that dies when a filter is applied, a game that ends with a driver-timeout message. The clue that points here is that the crashes are tied to visual work and to specific moments of heavy drawing, while less graphical software is fine.
The fix path has two branches. The real fix is the driver: update the graphics driver from the hardware maker's site (not from a generic updater, and not from a random download page), and if the crashes started after a driver update, try the previous driver version, which the maker's sites usually offer. The diagnostic — and often the temporary fix — is the application's hardware acceleration setting: turning it off makes the app draw with the CPU instead of the GPU, which is slower but bypasses the driver entirely. If the crashes stop with it off, you have confirmed the graphics path as the cause, and you can live with the fallback while the driver is sorted, or report the driver/app combination to the vendor with that evidence. One pattern to recognize: if the whole screen resets under heavy graphics load — a black flash, a driver-restart message — that is the operating system recovering a hung graphics driver, and it is a strong signal that the driver (or, less often, the graphics hardware itself) is the problem. Persistent driver-level crashes on specific hardware are worth raising with both the driver maker and the app vendor (topic 46).
Advanced troubleshooting and vendor support
The last group is for the problems that survive the obvious fixes: software that fights other software, failures that only a reboot clears, the logs that tell you what actually happened, the clean reinstall done properly, and the judgment call about when the problem is the software itself and the right move is to send it back to the people who wrote it.
Software that conflicts with another application
Two programs can break each other in ways that neither one reports: a pair of security products stepping on each other, a screen-recording tool and a game fighting over the display, an input manager and a typing-heavy app deadlocking, two apps that both try to own the same file, port, or system hook. The signature of a conflict is that the failure involves two names — it happens when both are present, and (if you have tested it) goes away when one is removed. Conflicts are among the most annoying software problems because the fault is in the relationship, not in either program alone.
The method is isolation, and it is the same one-change-at-a-time discipline as everywhere else in this guide. Identify the candidate pair (what else on the machine touches the same thing — the same files, the same display, the same input, the same network port?), then disable or uninstall one of them at a time and test. Start with the less essential of the two, and prefer disabling over uninstalling while you are testing, because the whole point is to be able to put it back. A few conflict pairs are common enough to check first: multiple antivirus products (run one, full stop), a virtual-drive or disk-imaging tool with a security product, and any combination of screen-capture, overlay, or input-injection tools with a game or a secured application. When you find the pair, the durable answers are to pick one of the two, to check whether either vendor documents the incompatibility (often one has a setting to coexist), or to run the conflicting one only when needed. Reporting the pair to both vendors is worth doing — conflict fixes do get shipped.
Software that only works after a restart
There is a specific frustration of software that refuses to start until the computer has been rebooted — the icon does nothing in the morning, a reboot, and it works fine. Behind that pattern are a few legitimate mechanisms: the software (or a driver it depends on) was updated and the new version is not active until a restart, a component it needs only finishes installing at boot, a service it depends on only starts cleanly on a fresh system, or a setting it made only takes effect on the next session. In every case the reboot is not fixing the software — it is completing a change the software or the system made.
The first question is whether the restart is one-time or ongoing. A one-time "restart to finish the update" message is normal — let it complete, and if the software still needs a reboot after that, the update or install did not finish cleanly and a repair (topic 15) is the fix. Ongoing "only works after reboot" behaviour is the real problem, and the usual causes are a dependency service that fails to start at boot (topic 39 — check its status and startup type), a driver that loads out of order (a driver update is the fix), or a startup item that runs the software before its prerequisites are ready (a startup delay, topic 35). The diagnostic shortcut: after a reboot, when the app works, compare the service list and the event log against a non-rebooted session where it fails (topic 43). If the pattern is a driver or an ordering problem, the fix belongs to the driver vendor or the app vendor — but you will know exactly what to tell them, because you will have caught the change the reboot is making.
Reading application logs and the Windows event log
Every significant software failure leaves a record, and learning to read the two main ones turns "it crashed" into "it crashed because component X failed at this time". The first is the operating system's event log: on Windows, the Event Viewer keeps an Application log that records application errors and crashes, each entry naming the faulting application, the faulting module (often the specific component that failed), and a timestamp. The second is the application's own log, if it writes one — many serious applications do, usually in a Logs folder inside their data folder or at a path their documentation names.
The workflow is short. Reproduce the failure (or note the time it happened), open the event log (the command below opens it on Windows), and find the Application-log entry at that time — a red "Error" entry for the application is the one you want. Read the three fields that matter: the name of the faulting module (a specific library name is a direct pointer to the component — cross-reference it with topics 24 to 28), the exception code (useful to the vendor, less so to you), and the time (which lets you correlate with what you were doing). Then check whether the application wrote its own log around the same moment — vendor logs are often far more specific than the system's, because the application knows what it was doing. Two cautions: logs contain details about your machine and your files, so be careful about pasting them into public places (a vendor's private support channel is fine; a public forum less so), and a log full of errors is not a diagnosis by itself — the entry that matches the exact moment of failure is the one that counts.
eventvwr.mscA clean reinstall, done properly
By the time a clean reinstall is on the table, the application has usually failed a repair, a settings reset, and an update — which makes the reinstall worth doing properly, because a sloppy one inherits the very damage you are trying to remove. A clean reinstall means: remove the application completely, remove what it left behind, restart so pending operations finish, and install a fresh copy from a known-good source — in that order. Done right, it is the strongest software-level fix short of a new machine, and it doubles as a diagnosis: if the problem survives a genuinely clean reinstall, the cause is provably not in the application's files.
The sequence, with the cautions that matter. Before you start, create a restore point (this is the one step in this guide where I would insist on it — everything before it was reversible without one), and locate anything the app holds that you cannot recreate: documents, licenses, saved work. Then uninstall through the normal flow, reboot, and remove the leftovers deliberately — the program folder and the application's data folders in the user profile (topic 06 covers finding them; move sensitive contents aside rather than deleting). Download a fresh installer from the official site, install it, and test the specific behaviour that was failing before you do anything else. If the behaviour is fixed, you are done, and you now know the damage was in the installation. If it is not, you have eliminated an entire layer of possible causes, and the remaining suspects are the operating system, a driver, a dependency, or the software itself — which is exactly the information the next step, and the vendor, need (topic 46).
When the problem is with the software itself
There is a point in every software troubleshooting session where the evidence stops pointing at the machine and starts pointing at the program: a fresh install fails the same way, a fresh user account fails the same way, the event log names the application's own module as the faulting one, and the behaviour is reproducible enough to describe precisely. Reaching that conclusion is not a failure of the troubleshooting — it is the troubleshooting working. It means the defect is in the software, and the productive next moves are different from the ones that get a machine fixed.
The moves are three. First, confirm you are on the current version and check the vendor's known-issues list and release notes — the bug you have found may be known, fixed in a newer build, or documented with a workaround, and that check takes five minutes. Second, gather the evidence properly: the exact steps that reproduce the problem, the versions (application and operating system, and the build number on Windows), the error text, and — for crashes — the event-log entry or a crash dump if the app produces one (topic 43 shows where to look). A crash dump in particular is worth asking about, because for a vendor it is the difference between "it crashes sometimes" and a fixable defect. Third, accept the timescale honestly: a genuine software defect is fixed by the vendor, on the vendor's schedule, and the interim options are a rollback (topic 14), a workaround from the vendor's notes, or a different tool for the task. Knowing which side of the machine/software line a problem sits on is what separates a solved case from a week of chasing ghosts.
When to contact the software vendor
Vendor support gets a bad reputation, but it is the right channel for a specific set of problems, and using it well is a skill: go with the right problem and the right evidence, and a support team can be fast; go with "it doesn't work" and a machine full of changes, and you will burn everyone's time. The problems that belong with the vendor are the ones this guide has been narrowing toward all along — a defect in the software itself (topic 45), a conflict the vendor can fix or document (topic 41), a regression from the vendor's own update (topic 13), a dependency the vendor must supply or name (topics 25 to 28), and any case where you have done a clean reinstall and the failure follows the software to a known-good machine.
Before you write, assemble the short list that turns a ticket into a diagnosis: the exact error or behaviour, the steps that reproduce it, the versions (application and operating system, plus the Windows build number), when it started (a date is gold — it often identifies the update that caused it), what you have already tried (a repair, a reset, a clean reinstall — each one rules a layer out for the engineer), and the event-log entry or crash dump for any crash (topic 43). Use the vendor's official support channel — their support site, their documented contact, or the contact in the application — rather than unofficial patches from forums, for the same reason this guide keeps steering you away from random downloads: the vendor's build is the only one you can trust to be what it says it is. And one last calibration: if the response is that the software is unsupported on your current operating system or hardware, that is an answer, not a brush-off — it is the vendor telling you the problem is a compatibility boundary, and the honest next step is the decision one (topic 28, or the hardware section of the slow-PC guide), not a third troubleshooting attempt.
When to stop
Most software problems stop being worth pushing when one of these is true — knowing the line is part of the method.
- The fix would mean permanently weakening security. If the only "solution" is a disabled antivirus, an always-on admin session, or a downloaded file of unknown origin, the problem is not solved — it is relocated. Choose a supported app or a supported OS instead (21, 22, 24).
- A clean reinstall did not change anything. That has ruled out the app's files, its settings, and the installation itself. The remaining causes — a driver, a system component, or the software's own defect — are above the level of casual fixes (44, 45).
- The vendor says the software does not support your system. That is a compatibility boundary, not a puzzle. The honest options are an older supported environment, a different tool, or waiting for support (28, 46).
- Business or professional data is at stake. When the application holds money, client data, or irreplaceable work, the cost of a wrong guess is not a wasted evening. Back up first, and involve the vendor or a technician before aggressive steps (31, 44).