Missing, unregistered or incompatible?
| Condition | Evidence |
|---|---|
| File genuinely absent | Installer/source references identify the control, but no trusted copy exists on the target. |
| Registration absent or wrong | File exists, but the required CLSID/ProgID is missing in the correct 32-bit registry view. |
| Wrong version | Class exists, yet interfaces, dependencies or binary compatibility differ. |
| Control cannot load | The OCX itself depends on another DLL/runtime, or Windows blocks access. |
| Design-time versus runtime licensing | A development component was deployed or reconstructed incorrectly. |
Safe repair process
- Identify the required control from the original installer, VBP reference or known-good machine.
- Preserve file version, hash, architecture and vendor information.
- Inspect dependent modules before registration.
- Use the correct 32-bit registration tool for VB6 controls on 64-bit Windows.
- Verify CLSID and ProgID resolution, then test the specific workflow.
- Package the control through a reproducible installer rather than leaving a manual fix.
Avoid third-party “DLL download” sites. A malicious or interface-incompatible control can register successfully and still corrupt behavior or expose the machine.
Escalation boundaries
If errors move from one control to another, the deployment package is probably incomplete; use VB6 recovery. If no specific component is named, begin with the wider startup diagnostic. Source-based dependency inventory belongs in source analysis, while database providers and DSNs are separate from OCX registration.
Provide
The exact error number/text, OCX filename, trusted installer or working machine, file properties/hashes, Windows architecture and any available VBP source.