crashpad_handler.exe: What It Is and How to Fix Errors

crashpad_handler.exe is normally a crash-reporting helper bundled with an application, including Chromium- and Electron-based apps, not a Windows system process. Chrome, desktop apps, game launchers, and games can each ship their own copy, so seeing several handlers is not automatically suspicious. The safe decision comes from the file location, parent application, command line, signature, and behavior. Repair the application that owns a broken copy; do not download a replacement EXE from a file library.

What is Crashpad Handler in Task Manager?

Crashpad is a crash-reporting system. When a supported application fails, its handler can collect exception details, loaded modules, and stack information into a small crash report so the developer can diagnose the failure. Chromium documents Crashpad as Chrome’s crash-reporting system, while Electron documents that its desktop-app crash reporter also uses Crashpad.[1][2]

The filename is shared because developers integrate the same crash-reporting component into many unrelated products. It is common to encounter it beside Chrome or another Chromium build, an Electron desktop app such as a chat client, Google Drive or another desktop utility, and some Steam games or launchers. Those products do not all use one central Windows copy. Each package may carry a different build in its own directory.

That is why a single path, file size, hash, or signer copied from a process database cannot prove that every other copy is safe. The useful question is not merely “Is this filename legitimate?” but “Which installed application launched this particular file?”

Why are multiple crashpad_handler.exe processes running?

Several copies can be expected when several applications use Crashpad at the same time. One browser, one desktop chat app, and one game can each launch a handler. An application may also relaunch its handler after an update or crash. The count alone is therefore a weak malware signal.

A similar pattern appears with other Chromium-based helpers. For example, multiple Adobe CEF Helper processes can represent separate app components rather than separate infections. With Crashpad, compare every instance instead of assuming all same-name entries belong to the same parent.

Investigate when the count grows continuously, old handlers remain after every related app is closed, CPU or disk activity stays high, or a copy runs from a directory that has no matching application files. A growing count is a reason to investigate the owning app for repeated launches or incomplete shutdown; the number alone does not establish the cause.

How to identify which app owns the process

1. Open Task Manager and select Details. Right-click the column header and enable Command line when available. The arguments often name a crash database, product, or user-data directory.
2. Open the file location. Right-click each instance and choose Open file location. Do this for more than one copy; their folders may differ.
3. Read the neighboring files and parent folder. A handler beside a recognizable app executable, resources, DLLs, and version folder is more credible than an isolated file in a random directory.
4. Check the parent process. Microsoft Process Explorer can show process relationships, loaded DLLs, and handles when Task Manager does not provide enough context.[3] The parent should make sense for the installed application. If the launching process has already exited, combine the file path and command line with a fresh, controlled launch of that app rather than treating a missing parent as a malware verdict.
5. Check Properties → Digital Signatures. A valid signature from the application vendor adds confidence. A missing signature is not automatic proof of malware because some legitimate app builds are unsigned, but it increases the need to verify the source and parent.
6. Compare behavior. A handler that appears only with its app and exits after the app closes is different from one launched at sign-in by an unknown task, script, service, or updater.

For a broader checklist, use our guide to checking whether an EXE file is safe. It explains how path, signature, hash, source, and behavior work together rather than treating one signal as a verdict.

Which paths are normal or suspicious?

There is no universal safe path. A legitimate copy normally lives inside the application that installed it, often under C:\Program Files\Vendor\App\, C:\Program Files (x86)\, or a clearly named application folder under %LOCALAPPDATA%. Version-number subfolders are common because applications update the handler with the rest of the package.

• A known app folder with matching files and parent: expected context. Verify the signer; repair the app only if it has errors or resource problems.
• Several different known app folders: can be separate legitimate bundled copies. Their hashes need not match.
• %LOCALAPPDATA%\Vendor\App\: can be a legitimate per-user install. Confirm the vendor, updater and signature.
• %TEMP%, Downloads, Startup or an unrelated directory: establish what launched the file. A verified installer or portable app may explain the location; an unexplained launcher or recurring alert warrants a scan.
• A file named crashpad_handler.exe inside C:\Windows\System32\: investigate its origin. Crashpad is not a core Windows component.

Do not whitelist an entire folder or disable antivirus protection just to stop an error. If the parent application is legitimate but security software blocks one file, verify the installer and signature first, then use the vendor’s repair flow or submit the exact file for review.

Is crashpad_handler.exe malware?

The legitimate component is not malware, but attackers can rename another executable to match a familiar process. The filename alone cannot distinguish the two. Treat the following combination as stronger evidence than any single sign:

• the file is outside a recognizable application directory;
• the parent is a script host, unknown updater, random executable, or unexplained scheduled task;
• the signature is absent, invalid, or belongs to an unrelated publisher;
• the command line points to Temp, Downloads, a random user folder, or an unexpected network location;
• the process returns after deletion because a service, task, startup entry, or bundled app recreates it;
• it produces unrelated browser changes, blocked connections, account alerts, or sustained resource use.

A clean result for one known hash does not automatically clear a different copy. If you need a sample-specific check, use the Gridinsoft Online Virus Scanner and compare the exact file you found. Do not upload private crash dumps or documents; the executable is the relevant object.

Crashpad not connected to handler: what to do

Crashpad_NotConnectedToHandler means the affected process could not connect to its crash-reporting handler. Microsoft documents this error in its Teams crash-code reference as a failure to connect and log crash data.[4] Seeing the code in Chrome or an embedded browser does not tell you which component caused the original failure, and the wording alone does not establish an Internet connection problem or malware infection.

Start with the app or page that failed, then use the result of each check to choose the next step:

1. Restart and update the affected app. Save work, exit it completely and reopen it. If it will not close, restart Windows. Install updates through the app’s official updater or store. If the error returns, note whether it affects one page or every page.
2. If only one browser page fails, compare a private window or a fresh browser profile. Keep the original profile and its data. If the page works in that test, investigate that profile’s extensions or site data one change at a time; the test narrows the problem but does not identify a particular extension. If the error affects every page or a desktop app, continue with the app-level checks below.
3. Check for an actual security-tool alert at the same time. Record the detection name and blocked path. Leave an unexplained file quarantined while you verify its source. Without a matching alert, do not assume antivirus caused the error or create a folder-wide exclusion.
4. Repair the application that displays the error. Use its repair or file-verification option, then an official reinstall if needed, preserving profiles and saves. An app with an embedded browser needs that app’s update; reinstalling your separate Chrome browser may not replace its bundled components. Our CefSharp subprocess guide explains how to identify that owner.
5. If it persists, give the app vendor a reproducible report. Include the app version, exact error text, time, affected page or action, file path, and whether the private-profile test changed the result. Add the matching Event Viewer faulting application/module if available. Share logs or crash dumps only through the vendor’s appropriate support channel because they may contain private data.

Do not rename chrome.exe, delete the Crashpad folder, download a replacement handler, or disable security protection as a generic fix. Those actions can hide a symptom or remove diagnostic evidence without explaining the failure.

How to fix crashpad_handler.exe Application Error

An Application Error can involve the handler itself or the app that launched it. The dialog alone does not distinguish damaged files, an app bug, a compatibility problem or a security block. Repair the owner, not Windows as a whole:

1. Identify the owning app first. Record the file path, command line, parent process, and the app that was opening when the message appeared.
2. Close the app cleanly. Save work, exit the parent application, then end only an orphaned handler that remains. Reboot if the app cannot shut down.
3. Install the app’s current update. Use its built-in updater, official store, game launcher, or vendor site. An older handler beside newer app DLLs can fail after a partial update.
4. Repair or verify the installation. Use Windows Installed apps → Modify/Repair when offered. For a game, use the launcher’s file-verification feature. For Chrome or another browser, use its official reinstall path if normal updates do not fix the crash.
5. Check Event Viewer. In Windows Logs → Application, match the error time and read the faulting application and faulting module. The faulting module is a diagnostic clue, not proof of the root cause; compare the same failure after an app update or a controlled test without a nonessential overlay.
6. Reinstall only the owning app if repair fails. Preserve profiles, saves, or synced data first, uninstall the app normally, reboot, and install a fresh official package.

Do not download a loose crashpad_handler.exe from an executable library. The replacement may be the wrong architecture or version, may lack the app’s matching DLLs, and may be unsafe. Reinstalling the parent package restores the component that belongs with that exact build.

Fix high CPU, many copies, or a process that will not close

1. Close the suspected parent apps one at a time and watch which handler exits.
2. If one app keeps relaunching handlers, reboot and test it before starting other apps.
3. Disable only that app’s optional launch-at-login setting for one test. Do not disable Windows services or apply a system-wide block.
4. Update or repair the app. For a game, verify files and temporarily disable nonessential overlays to isolate a conflict.
5. If handlers remain with no parent, end the orphaned instances and inspect the next launch with Process Explorer.
6. If the process returns from an unknown task or service, switch from performance troubleshooting to security triage.

Ending the handler is a temporary diagnostic, not a permanent fix. The app can create it again because crash reporting is part of its normal startup. Deleting the file may simply break the app’s next launch or update.

Can you disable or remove crashpad_handler.exe?

You should not remove a verified copy by itself. Some applications can operate without uploading crash reports, but the handler is managed by the application and may return after every update. Privacy controls for crash reporting belong in that app’s settings when available. Turning off report uploads does not necessarily stop local crash collection or remove the handler; Chromium documents these as separate behaviors.

If you no longer need the parent application, uninstall the application normally. If you still need it, use its repair or reinstall option. Renaming the handler, blocking it with permissions, or creating broad antivirus exclusions can turn a recoverable app problem into a broken installation.

What to do if crashpad_handler.exe looks suspicious

1. If an unknown copy already ran and you see account or network symptoms, stop sensitive work on that PC. Record the alert, file path and source without opening the file again.
2. Download Gridinsoft Anti-Malware from its official site using the scan button below, install it, update its detection database and run a Full Scan. Review the detections and apply the recommended cleanup for confirmed threats; leave verified app copies alone.
3. Restart and check the original alert or unwanted behavior again. If it returns, scan again and use the detection log to guide follow-up. Manually inspecting the launcher, tasks or services is an optional targeted investigation, not a prerequisite for the scan.
4. If account credentials or sessions may have been exposed after an unknown installer ran, change credentials from a clean device and sign out active sessions. A malware scan does not undo account access.

Deleting the visible file does not remove an unknown loader, scheduled task, service, browser change, or bundled module that can restore it. Gridinsoft Anti-Malware can check detected files, hidden components, startup entries, tasks, services, bundled apps, and other persistence associated with a suspicious process copy.

For another example of why the parent process matters, see our dllhost.exe high-CPU and malware-lookalike guide.

FAQ

References

1. The Chromium Projects. “Crash Reports.” Chromium, accessed November 8, 2026. Chromium Crashpad documentation.
2. OpenJS Foundation and Electron contributors. “crashReporter.” Electron documentation, accessed November 8, 2026. Electron crashReporter documentation.
3. Mark Russinovich. “Process Explorer.” Microsoft Sysinternals, updated November 5, 2026; accessed November 8, 2026. Microsoft Process Explorer documentation.
4. Microsoft. “Resolve Teams client crash issues,” sandbox and Crashpad error codes. Microsoft Learn, accessed November 8, 2026. Crashpad connection error reference.