# AMD LoadLibrary failed with error 87 after switching from NVIDIA

**Languages:** English · [Español](es/README.md)

This guide documents a confirmed Windows driver-installation failure in which an orphaned NVIDIA display-class co-installer prevented AMD software components from being registered. The base AMD display driver appeared to install successfully, but OpenGL and Vulkan were left unusable.

The exact application error was:

```text
LoadLibrary failed with error 87: The parameter is incorrect.
```

Related searches and symptoms include **OpenGL ChoosePixelFormat error 87 AMD**, **Vulkan Found no drivers AMD**, **missing OpenGLVendorName**, **nvdispco DLL missing after NVIDIA uninstall**, and **AMD regamdcomp.exe did not register OpenGL Vulkan**.

> [!CAUTION]
> Do not remove an NVIDIA display-class co-installer on a system that still has a present NVIDIA display adapter. The repair script in this repository refuses to continue in that configuration. Always create registry backups before changing driver registration.

## Short answer

In the confirmed case, Windows retained this display-class co-installer entry after the NVIDIA GPU and its driver file were gone:

```text
HKLM\SYSTEM\CurrentControlSet\Control\CoDeviceInstallers
  {4D36E968-E325-11CE-BFC1-08002BE10318}
    nvdispco6445671.dll,NvDspFixCoInstall
```

The referenced file, `%SystemRoot%\System32\nvdispco6445671.dll`, no longer existed. A later AMD installation tried to load it, recorded Win32 error 126 (`ERROR_MOD_NOT_FOUND`), and then failed to create the AMD OpenGL, Vulkan, OpenCL, and Windows support software-component devices. Because those components never matched a device, AMD's final `regamdcomp.exe` registration did not run. The AMD files were present in DriverStore, but their OpenGL and Vulkan registry links were missing.

Restoring the AMD OpenGL/Vulkan registrations fixed the immediate error. Removing only the exact orphaned NVIDIA co-installer fixed the confirmed root condition that could break later AMD installations again.

This is one evidence-backed cause of error 87, not a universal explanation for every occurrence.

## Who this guide applies to

Use this guide when all or most of the following are true:

- A Windows PC was changed from an NVIDIA GPU to an AMD GPU.
- The AMD display driver installs, but OpenGL applications fail at startup with error 87.
- `vulkaninfo --summary` reports that it found no drivers.
- The AMD OpenGL and Vulkan files exist, but their registry registrations are missing.
- SetupAPI records a failed load of a missing `nvdispco...dll` from `%SystemRoot%\System32`.
- The machine no longer has a present NVIDIA display adapter.

This guide does not diagnose GPU black screens, timeout-detection-and-recovery events, unstable overclocks, power-delivery faults, game-specific crashes, or a driver version that is independently defective.

## Quick diagnostic map

| Symptom or evidence | What it suggests | Confirm with |
| --- | --- | --- |
| `LoadLibrary failed with error 87` during OpenGL startup | Windows cannot complete AMD OpenGL ICD loading | Check `OpenGLVendorName` and run a fresh WGL context test |
| `vulkaninfo` says it found no drivers | No usable AMD Vulkan ICD is registered | Check both Khronos Vulkan `Drivers` registry branches |
| Missing `OpenGLVendorName` and `OpenGLVendorNameWow` | The AMD OpenGL component did not complete registration | Inspect the active AMD display-class key |
| Missing NVIDIA co-installer DLL but retained class entry | A global stale co-installer can interfere with later display installs | Inspect `CoDeviceInstallers` and SetupAPI |
| AMD component INFs report no matching devices | AMD virtual software-component devices were not created | Correlate the base display INF's `AddComponent` directives with SetupAPI |
| AMD files exist in DriverStore but APIs fail | File copy completed, final registration did not | Look for the missing `regamdcomp.exe` registration stage |

## Evidence chain

The important distinction is between a successful base display-driver install and successful installation of every related software component.

1. The AMD display INF contains `AddComponent` directives for the AMD OpenGL, Vulkan, OpenCL, and Windows support components.
2. Windows invokes display-class co-installers while processing the device installation.
3. The global display-class value still names `nvdispco6445671.dll,NvDspFixCoInstall`.
4. Windows tries the absolute `%SystemRoot%\System32` path, but the DLL is absent. SetupAPI records error 126.
5. The base AMD driver still reaches a success state, while the component INFs report that they cannot find matching software-component devices.
6. The expected AMD software-component device nodes are absent.
7. The component registration command does not run, so `OpenGLVendorName`, `OpenGLVendorNameWow`, and the Vulkan ICD values are absent even though their files were copied.
8. OpenGL surfaces error 87 when `ChoosePixelFormat` triggers ICD loading; Vulkan reports no drivers because it has no usable registered manifest.

A minimal reconstructed log pattern looks like this:

```text
Display-class co-installer: %SystemRoot%\System32\nvdispco6445671.dll
Load failed: ERROR_MOD_NOT_FOUND (126)
AMD software-component INF: Unable to find any matching devices
Base display device installation: completed
```

The example is intentionally reconstructed and sanitized. Do not publish raw SetupAPI logs: they can contain device instance IDs and other machine-specific data.

## Why the AMD components matter

Windows componentized drivers can create child software components through an INF `AddComponent` directive. Each child component is then matched to its own component INF and installation section. Microsoft documents this flow in [INF AddComponent Directive](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-addcomponent-directive) and [Using a Component INF File](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/using-a-component-inf-file).

Co-installers are separate DLL callbacks registered for device setup. Microsoft now recommends modern package-based approaches instead of co-installers, but Windows still processes registered co-installers for applicable installations. See [INF DDInstall.CoInstallers Section](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-ddinstall-coinstallers-section).

In this failure, the files being present was not enough. The missing software-component device nodes meant the AMD registration stage did not connect those files to the OpenGL and Vulkan loaders.

## Read-only diagnosis

Download or clone this repository, open Windows PowerShell, and run the [read-only diagnostic script](scripts/diagnose-amd-registration.ps1):

```powershell
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\diagnose-amd-registration.ps1
```

It reports only booleans and generic system paths. DriverStore package names, hardware instance IDs, and user paths are not printed.

Exit codes:

| Code | Meaning |
| ---: | --- |
| `0` | AMD OpenGL/Vulkan registration is healthy and the exact stale co-installer is absent |
| `2` | A repairable broken or stale registration was detected |
| `3` | The adapter state is unsupported or unsafe for automatic repair |

The diagnosis performs no registry writes.

## Guarded automated repair

Review the [repair script](scripts/repair-amd-registration.ps1) before running it. Start with preview mode:

```powershell
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\repair-amd-registration.ps1
```

If every safety check passes, run it from an elevated Windows PowerShell session:

```powershell
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\repair-amd-registration.ps1 -Apply
```

The script:

- requires a present AMD display adapter and active AMD display-class key;
- refuses to proceed when a present NVIDIA display adapter is detected;
- removes only the exact `nvdispco6445671.dll,NvDspFixCoInstall` entry, and only when its DLL is absent;
- preserves every unrelated class co-installer entry;
- dynamically resolves the installed AMD OpenGL libraries and a complete current Vulkan manifest pair;
- exports the co-installer, AMD display-class, and both Vulkan registry branches before mutation;
- writes backups below `C:\tmp\amd-registration-backup-<timestamp>`;
- ensures the 64-bit and 32-bit AMD OpenGL and Vulkan registrations;
- requests a non-destructive Plug and Play scan; and
- runs post-change registration checks.

It does not uninstall, force-delete, downgrade, or reinstall any display-driver package.

## What the repair changes

The exact class co-installer value is either removed when it contains only the orphaned NVIDIA entry, or rewritten as `REG_MULTI_SZ` with every nonmatching entry preserved.

On the active AMD display-class key, the script ensures:

```text
OpenGLVendorName     -> installed 64-bit AMD OpenGL library
OpenGLVendorNameWow  -> installed 32-bit AMD OpenGL library
```

It also ensures an enabled AMD manifest value (`DWORD 0`) under both loader branches:

```text
HKLM\SOFTWARE\Khronos\Vulkan\Drivers
HKLM\SOFTWARE\WOW6432Node\Khronos\Vulkan\Drivers
```

The script discovers the actual display subkey and DriverStore package dynamically. Do not copy a `0000` subkey number or DriverStore package directory from another PC.

## Manual repair reference

For advanced troubleshooting, the safe order is:

1. Confirm the AMD adapter is present and no NVIDIA adapter is present.
2. Export the complete `CoDeviceInstallers` key, active AMD display-class key, and both Vulkan `Drivers` keys.
3. Confirm the co-installer list contains an exact match for `nvdispco6445671.dll,NvDspFixCoInstall`.
4. Confirm `%SystemRoot%\System32\nvdispco6445671.dll` is absent.
5. Remove only that list entry; preserve all others.
6. Resolve the installed AMD OpenGL libraries and current paired Vulkan manifests on that machine.
7. Restore both architectures of the OpenGL and Vulkan registrations.
8. Rescan devices and verify both APIs.

The automated script encodes these checks and is safer than copying registry commands with machine-specific paths.

## Rollback

Every applied repair prints its backup directory. Validate a backup with the [rollback script](scripts/rollback-amd-registration.ps1) in preview mode:

```powershell
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\rollback-amd-registration.ps1 -BackupDirectory 'C:\tmp\amd-registration-backup-<timestamp>'
```

Only if rollback is actually required, run the same command elevated with `-Apply`:

```powershell
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\rollback-amd-registration.ps1 -BackupDirectory 'C:\tmp\amd-registration-backup-<timestamp>' -Apply
```

The rollback validates the directory, manifest, filenames, display-class key, and AMD manifest paths before importing anything.

## Verification

After repair:

1. Run the diagnostic script again. It should exit `0`.
2. Create a fresh OpenGL context and confirm the vendor and renderer are AMD rather than Microsoft's software renderer.
3. Run `vulkaninfo --summary` and confirm it exits `0` and lists an AMD physical device.
4. Reboot once and repeat the checks before judging the repair durable.
5. On a later AMD driver update, review SetupAPI to confirm the old NVIDIA DLL is no longer invoked.

The final item is the strongest end-to-end confirmation that future component installation is no longer taking the broken path. Removing the verified stale entry corrects the root condition, but this repository does not claim that a future vendor installer has already been tested on every machine.

## Why cleanup utilities may not be enough

DDU and AMD Cleanup Utility are useful for removing vendor packages and device-specific leftovers. This case involved a global display-class co-installer value under `CoDeviceInstallers`. A cleanup can remove the DLL or package while leaving that shared class registration behind. That creates the especially confusing state where the old vendor file is gone but Windows continues trying to call it during another vendor's installation.

The decisive test is not whether an NVIDIA folder still exists. It is whether the exact class co-installer value remains and whether SetupAPI attempts to load its missing DLL.

## Other causes of error 87

Do not apply this repair merely because the number `87` appears. Other causes include:

- an application passing an invalid parameter to an unrelated Windows API;
- damaged or mismatched graphics binaries;
- an incorrect 32-bit/64-bit loader path;
- third-party overlays or injected DLLs;
- corrupted system files;
- a partially installed driver for reasons unrelated to a co-installer; or
- hardware instability that happens before API initialization completes.

If the exact stale NVIDIA entry is absent, SetupAPI does not show the missing DLL, and AMD registration is healthy, this guide's confirmed root cause does not match the machine.

## Frequently asked questions

### Is error 87 always caused by an old NVIDIA co-installer?

No. Error 87 is a general Windows error. This guide applies only when the registry, missing DLL, SetupAPI, component-device, and AMD registration evidence line up.

### Can I run the repair on a mixed AMD and NVIDIA system?

No. The automated repair intentionally refuses when a present NVIDIA display adapter is detected. A legitimate NVIDIA installation may still require its co-installer.

### Why did the AMD installer report success?

The base display device and its related software components are separate installation work. The base driver can finish while child component matching or final API registration fails.

### Why were the AMD DLL and JSON files already on disk?

DriverStore staging and file copy can complete before component-device creation and final registration. Files on disk do not prove that OpenGL or Vulkan loader registry values exist.

### Is changing PATH, TEMP, or another environment variable the fix?

Not for this confirmed case. SetupAPI tried an explicit `%SystemRoot%\System32` DLL path. The missing global class co-installer and skipped AMD registration explained the failure without an environment-variable error.

### Should I reinstall or downgrade the AMD driver first?

Not automatically. Repeating the installer while the stale co-installer remains can repeat the same broken component path. Diagnose and back up the root condition first. Driver-version regressions are a separate troubleshooting branch.

## References

- Microsoft Learn: [INF AddComponent Directive](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-addcomponent-directive)
- Microsoft Learn: [Using a Component INF File](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/using-a-component-inf-file)
- Microsoft Learn: [INF DDInstall.CoInstallers Section](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-ddinstall-coinstallers-section)

## License and contribution

The guide and scripts are released under the [MIT License](LICENSE). Reports are welcome, but remove usernames, device instance IDs, DriverStore hashes, raw logs, and other machine-specific identifiers before opening an issue.