Classify the symptom first
| Observation | Likely direction |
|---|---|
| Windows reports a missing module before any UI | Native DLL or runtime dependency; inspect loader evidence. |
| Runtime error 429 or 339 | COM/ActiveX identity, registration, version or licensing. |
| Splash appears, then process exits | Startup code, configuration, database/provider or suppressed error. |
| Works for another user | Permissions, per-user registry, profile paths or mapped resources. |
| Works only on the old PC | Undocumented runtime, DSN, locale, file or device dependency. |
Diagnostic sequence
- Capture exact error text, process lifetime and event-log entries.
- Confirm application files and configuration came from one known release.
- Inspect loaded and failed modules; do not register every nearby DLL.
- Check 32-bit registry and ODBC views on 64-bit Windows.
- Test database, share and device availability outside the application.
- Compare with a working machine and change one variable at a time.
Corrupt data can trigger startup code even when the executable is healthy. Likewise, a valid OCX file may be registered under the wrong architecture or replaced with an incompatible build.
When the problem is larger
Use missing OCX diagnostics for an identified control. If installer, application files or the entire environment are incomplete, follow application recovery. Database errors may require database recovery; a working source tree should be examined through source analysis.
Useful evidence
Exact error and screenshot, Windows/build architecture, installation source, event logs, file/version inventory, database type and whether any machine still works.