# System-wide application conflicts: when one app causes another to crash

System-wide application conflicts occur when installing or updating one application unintentionally disrupts the functionality of other applications on the same system. These disruptions can include crashes, missing features, or a complete failure to launch. Unlike typical app-specific crashes, these issues stem from shared system resources being altered by another application.

Common causes include the following:

- Shared DLL overwrites: A new installer replaces system DLLs with incompatible versions, breaking other apps that rely on those DLLs.
- Architecture mismatches: In some cases, installing x64 components on ARM64 systems can cause emulation failures or mixed-architecture conflicts.

    - Example: Installing Adobe Acrobat 64-bit on Windows ARM64 replaced ARM64 VC++ redistributable DLLs with x64 versions, causing unrelated apps like Wireshark and winget to fail with error 0xc000007b.
- Registry corruption or redistributable conflicts: Incorrect VC++ runtime versions registered globally.

Traditional debugging focuses on the crashing application itself. However, in these scenarios, the root cause lies elsewhere - often in a recently installed or updated application that modified some system-level components. Recognizing this pattern prevents wasted effort and accelerates resolution.

## How to recognize system-wide conflicts

Look for the following indicators to help recognize system-wide conflicts:

- Multiple apps start crashing after a recent install/update.
- Common error codes across different apps. For example,  `0xc000007b (STATUS_INVALID_IMAGE_FORMAT)`.
- Event Viewer logs show missing or incompatible DLLs.
- Failures occur immediately after installing/updating a major app.
- Uninstalling the crashing app does not resolve the issue.

## Troubleshooting steps

1. Start Event Viewer and look for faulting module names and error codes.

    1. In Event Viewer, click **Windows Logs** → **Application**.
    2. In the Application window look for faulting module names and error codes. For example, Faulting module: `MSVCP140.dll`.
2. Use `Get-WmiObject` in PowerShell to identify apps installed or updated before the crashes began.

Get-WmiObject Win32_Product | Sort-Object InstallDate -Descending | Select-Object Name, Version, InstallDate
        Copy to clipboard
3. Use [dumpbin](https://learn.microsoft.com/en-us/cpp/build/reference/dumpbin-reference?view=msvc-170) ![devhw](data:image/png;base64,UklGRt4AAABXRUJQVlA4TNIAAAAvD8ADED/BoG0jSe5SXP5I7gkNRG3byLnX4Tn+2K4I2raNw5/iqPxlEwBAGlwuj8BNBPpnsblrANx3P36s+DHQIcQ0dmEfEGPc8WEcCCcO/M2hXv3rDJTcHCTB1es7l9P2UoywA2a3jSW/pp77EhxGkq1E8zjH3R3e/fxjREOI6P8EcH+lqu/oTK/6kS+YwlHVAMjkP0ErP1UNIZZmnsB32Y2lZjNPO7HUUA1HkVWz73lAIiWM6WaegFcHzNOJ3bv89WhdNu1TDx/txhT2np2bzWU=) to check DLL versions and architecture.

dumpbin /headers "C:\\Path\\To\\DLL\\example.dll"
        Copy to clipboard

    Look for:

    - machine (x64) → 8664
    - machine (ARM64) → AA64
    - machine (x86) → 14C

    Use /IMPORTS and /EXPORTS to list DLLs imported and exported to an executable file or DLL as in the following examples:

dumpbin /IMPORTS "C:\\Path\\To\\DLL\\example.dll"
        
        dumpbin /EXPORTS "C:\\Path\\To\\DLL\\example.dll"
        Copy to clipboard
4. Run a PE header check in PowerShell on the failing process or selected module as in the following example:

$bytes = Get-Content "C:\\Path\\To\\DLL\\example.dll" -Encoding Byte -TotalCount 64
        
        $arch = [System.BitConverter]::ToUInt16($bytes, 4)
        
        switch ($arch) {
        
            0x14C { "x86" }
        
            0x8664 { "x64" }
        
            0xAA64 { "ARM64" }
        
            default { "Unknown" } }
        Copy to clipboard

## Recommended tools and usage

### Resource Monitor

Use Resource Monitor to check which modules (DLLs) are loaded by the crashing app.

- How to use:

    - Open Resource Monitor (resmon.exe).
    - Go to CPU tab → Associated Handles.
    - Search for the process name (for example, Wireshark.exe).
    - Verify DLL paths and look for unexpected architecture. For example, x64 DLL in an ARM64 app.

### dumpbin (Visual Studio Developer Tools)

Use dumpbin to validate DLL architecture and headers.

- How to use:

    - Open ARM64 Developer Command Prompt.
    - Run: dumpbin /headers `C:\Path\To\DLL\example.dll`
    - Check machine field:

        - x64 → 8664
        - ARM64 → AA64
        - x86 → 14C
    - Use /imports and /exports to verify dependencies.

### Process Monitor (ProcMon)

Use ProcMon to capture registry and file I/O during app launch to detect conflicts.

- How to use:

    - Download [Process Monitor](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) ![devhw](data:image/png;base64,UklGRt4AAABXRUJQVlA4TNIAAAAvD8ADED/BoG0jSe5SXP5I7gkNRG3byLnX4Tn+2K4I2raNw5/iqPxlEwBAGlwuj8BNBPpnsblrANx3P36s+DHQIcQ0dmEfEGPc8WEcCCcO/M2hXv3rDJTcHCTB1es7l9P2UoywA2a3jSW/pp77EhxGkq1E8zjH3R3e/fxjREOI6P8EcH+lqu/oTK/6kS+YwlHVAMjkP0ErP1UNIZZmnsB32Y2lZjNPO7HUUA1HkVWz73lAIiWM6WaegFcHzNOJ3bv89WhdNu1TDx/txhT2np2bzWU=) from Microsoft Sysinternals.
    - Launch ProcMon and set filters:

        - Filter → Process Name → is → [AppName].exe → Include
    - Start capture and reproduce the crash.
    - Look for operations failing with ACCESS DENIED or missing DLL paths.
    - Export logs for deeper analysis.

### Dependency Walker

Dependency Walker is an open-source utility that you can use to detect missing DLLs and architecture mismatches.

- How to use:

    - Download [Dependency Walker](https://www.dependencywalker.com/).
    - Open the crashing EXE (e.g., Wireshark.exe).
    - Red icons indicate missing DLLs; warnings show architecture mismatch.
    - Use Profile mode to capture runtime DLL loads.

## Case study: Adobe Acrobat 64-bit issue

Installing or updating Adobe Acrobat 64-bit on Windows ARM64 devices introduced a system-wide conflict. The installer overwrote ARM64 VC++ redistributable DLLs in `C:\Windows\System32`` with x64 versions. As a result, ARM64 applications like Wireshark and system tools like winget failed to launch. In addition, error code `0xc000007b (STATUS_INVALID_IMAGE_FORMAT)` was observed.

### Diagnosis

- Event Viewer: Event Viewer may show Faulting module identified as MSVCP140.dll.
- Dependency Walker: Architecture mismatch detected - x64 DLL loaded into ARM64 process.
- dumpbin analysis: Confirmed DLL headers showed machine (x64) instead of AA64.
- Registry & MSI checks: Redistributable registration failed under ARM64 emulation.

### Resolution

- Repaired VC++ redistributables (partial fix).
- Manually replaced corrupted DLLs with correct ARM64 versions.
- Ran sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth to restore system integrity.
- Installed 32-bit version of Adobe Acrobat as a workaround.

### Case study summary

The following is a summary of actions taken during a real-world troubleshooting session for Wireshark ARM64 crash after Adobe Acrobat update:

1. Root cause identification:

    - Confirmed DLL overwrite by Acrobat installer.
    - Verified architecture mismatch using dumpbin.
2. System recovery steps:

    - Replaced corrupted DLLs with ARM64 versions.
    - Reinstalled all VC++ redistributables (ARM64, x64, x86).
    - Ran sfc and DISM for system file repair.
3. Wireshark debugging:

    - Reinstalled Wireshark and Npcap.
    - Verified dependencies with Dependency Walker.
    - Checked Event Viewer for hidden faulting modules.
4. Additional attempts:

    - Registry cleanup.
    - Reinstall sequence for redistributables.

Last Published: Jun 16, 2026

[Previous Topic
Symbol loading](https://docs.qualcomm.com/bundle/publicresource/80-62010-1/topics/debug-symbol-loading.md) [Next Topic
Debugging common issues](https://docs.qualcomm.com/bundle/publicresource/80-62010-1/topics/debugging.md)