AMD LoadLibrary failed with error 87 after switching from NVIDIA

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

No. This guide applies only when the stale registry entry, missing DLL, SetupAPI component failure, and missing AMD API registration evidence agree.

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

No. The automated repair refuses when a present NVIDIA display adapter is detected.

Q: Why did the AMD installer report success?

The base display driver can finish while related software-component matching and final OpenGL or Vulkan registration fail.

Languages: English · Español

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:

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:

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.

The AMD display INF contains AddComponent directives for the AMD OpenGL, Vulkan, OpenCL, and Windows support components.
Windows invokes display-class co-installers while processing the device installation.
The global display-class value still names nvdispco6445671.dll,NvDspFixCoInstall.
Windows tries the absolute %SystemRoot%\System32 path, but the DLL is absent. SetupAPI records error 126.
The base AMD driver still reaches a success state, while the component INFs report that they cannot find matching software-component devices.
The expected AMD software-component device nodes are absent.
The component registration command does not run, so OpenGLVendorName, OpenGLVendorNameWow, and the Vulkan ICD values are absent even though their files were copied.
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:

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 and 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.

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:

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 before running it. Start with preview mode:

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.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:

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:

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:

Confirm the AMD adapter is present and no NVIDIA adapter is present.
Export the complete CoDeviceInstallers key, active AMD display-class key, and both Vulkan Drivers keys.
Confirm the co-installer list contains an exact match for nvdispco6445671.dll,NvDspFixCoInstall.
Confirm %SystemRoot%\System32\nvdispco6445671.dll is absent.
Remove only that list entry; preserve all others.
Resolve the installed AMD OpenGL libraries and current paired Vulkan manifests on that machine.
Restore both architectures of the OpenGL and Vulkan registrations.
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 in preview mode:

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.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:

Run the diagnostic script again. It should exit 0.
Create a fresh OpenGL context and confirm the vendor and renderer are AMD rather than Microsoft’s software renderer.
Run vulkaninfo --summary and confirm it exits 0 and lists an AMD physical device.
Reboot once and repeat the checks before judging the repair durable.
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
Microsoft Learn: Using a Component INF File
Microsoft Learn: INF DDInstall.CoInstallers Section

License and contribution

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